Re: [v4l-utils RFC 0/3] mediatext library and test program

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Sakari,

First a practical matter: you should consider using the v4l-helpers.h: it will
shield you and probably the end-user as well from lots of complexities, esp. the
single vs multiplanar differences.

I really need to spend some time documenting it, but it isn't all that difficult.


On 07/21/2016 05:15 PM, Sakari Ailus wrote:
> Hi everyone,
> 
> We've got a number of V4L2 (and MC) test programs for about as many reasons.
> The existing programs are concentrated to work on a single device node at a
> time, and with a single interface, be that Media controller or V4L2.
> 
> The test programs are also command line controlled, working their way with
> the device at hand based on the information passed to the test programs on
> the command line. This has made perfect sense for the past 15 years, as long
> as we've had such test programs: they have covered, for large part, needs to
> perform testing in various cases without leaving significant gaps.
> 
> With the upcoming request API, however, this has become insufficient. The
> very nature of the request API requires that requests can contain resources
> (e.g. memory buffers) that is associated to a number of video device nodes.
> The requests may well be different from each other, including the types of
> resources that are used for each request.
> 
> So I decided we need a new test program. The scope for the original
> mediatext library and test program were slightly different from what is in
> this (very RFC) patchset. I deemed mediatext as the best starting point for
> writing a new test program.

Is this utility meant to testing different scenarios, or as a way to test drivers
(compliance tests)? I think the first, right?

> mediatext acts as an interface between an end user or a script and the
> kernel interfaces, with an ability to work with multiple devices at a time,
> including multiple video nodes:
> 
>                        shell script
>                            |
>                            |
>                            |  <- two-way pipe
>                            |
>                            |
>                        mediatext
>                      /     |     \
>                     /      |      \
>              /dev/video*   |     /dev/v4l-subdev*
>                            |
>                          /dev/mediaX
> 
> The shell script (which could be any other program as well but shell scripts
> are convenient for the purpose) is always in the control of the main loop of
> the test. Events are delivered to the script by mediatext based on file
> handle state changes, so the script has a possibility to react to each of
> them (e.g. buffer becoming dequeueable on one of the video nodes).
> 
> A simple example script for a UVC compliant Logitech webcam is below. It
> opens the device based on the name of the entity, and sets up the device for
> streaming with a specified format with three MMAP buffers. The first 50
> frames are written to a file, and capturing is stopped once about 100 frames
> have been captured. Dequeued buffers are immediately requeued, and this is
> explicitly done by the shell script.
> 
> ---------------------8<---------------------
> #!/bin/bash
> 
> eval_line() {
>     while [ $# -ne 0 ]; do
> 	local name=${1%=*}
> 	local value=${1#*=}
> 	p[$name]="$value"
> 	shift
>     done
> }
> 
> coproc mediatext -d /dev/media0 2>&1
> 
> cat <<EOF >&${COPROC[1]}
> v4l open entity="UVC Camera (046d:0825)" name=uvc
> v4l fmt vdev=uvc type=CAPTURE width=320 height=240 \
>         pixelformat=YUYV bytesperline=0
> v4l reqbufs vdev=uvc type=CAPTURE count=3 memory=MMAP
> v4l qbuf vdev=uvc
> v4l qbuf vdev=uvc
> v4l qbuf vdev=uvc
>                                   
> v4l streamon vdev=uvc type=CAPTURE
> EOF
> 
> while IFS= read -ru ${COPROC[0]} line; do
> 	unset p; declare -A p
> 	eval eval_line $line
> 	echo $line
> 	case ${p[event]} in
> 	dqbuf)
> 		if ((${p[seq]} < 50)); then
> 			echo v4l write vdev=uvc \
> 				sequence=${p[seq]} >&${COPROC[1]}
> 		fi
> 		if ((${p[seq]} > 100)); then
> 			echo quit >&${COPROC[1]}
> 		fi
> 		cat <<EOF >&${COPROC[1]}
> 			v4l qbuf vdev=uvc
> EOF
> 	;;
> 	esac;
> done
> ---------------------8<---------------------
> 
> Requests are naturally supported as well, right now only for buffer-related
> IOCTLs but support for other IOCTLs can be added as well. The library has
> been designed to be modular and easily extensible. There are no drivers
> implementing them yet, and the kernel patches are still in development.
> 
> The kernel patches from which the headers have been generated from are
> available here:
> 
> <URL:http://git.retiisi.org.uk/?p=~sailus/linux.git;a=shortlog;h=refs/heads/request>
> 
> As noted, the test program is still in development phase. I thought this
> still would be useful for others working on the request API so I decided to
> share it already.

Can you show a test script/shell example of the use of the request API?

> 
> Current todo list:
> 
> - The scope of the current media-ctl functionality command format does not
>   match with the rest of the program. To be fixed.
> 
> - Support requests for non-buffer related IOCTLs. This is pending on
>   relevant kernel patches.
> 
> - Clean up command parameters and event messages to make them more
>   consistent.
> 

I'd split off the parser code into its own source as well.

Is there a reason you use C instead of C++? C++ would make life a bit easier: STL
of course, but the cv4l-helpers.h (the C++ variant of v4l-helpers.h) is quite nice
as well.

Regards,

	Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux