Difference between revisions of "V4L Test Suite"

From LinuxTVWiki
Jump to: navigation, search
(removed end user report of vivi & capture compatibility problems to the article's talk page; minor formating)
m (fixed the note)
Line 24: Line 24:
  
 
There are many small test apps that seem to have been written to help isolate an existing problem, as opposed to actively looking for problems.  This means the tests make assumptions about what is/isn't supported, which can cause [[Wikipedia:Type_I_and_type_II_errors|false positives]] when someone else uses them in a different environment.  For instance, a specific feature test should not be run unless the device driver advertises support for the feature.  Ideally, this means that all tests should first xioctl(fd, VIDIOC_QUERYCAP, &cap) and test  cap.capabilities to see if the rest of the test is applicable.  However, this does not mean you shouldn't post your test code it it does not comply with such ideal qualifications - as something is better than nothing.
 
There are many small test apps that seem to have been written to help isolate an existing problem, as opposed to actively looking for problems.  This means the tests make assumptions about what is/isn't supported, which can cause [[Wikipedia:Type_I_and_type_II_errors|false positives]] when someone else uses them in a different environment.  For instance, a specific feature test should not be run unless the device driver advertises support for the feature.  Ideally, this means that all tests should first xioctl(fd, VIDIOC_QUERYCAP, &cap) and test  cap.capabilities to see if the rest of the test is applicable.  However, this does not mean you shouldn't post your test code it it does not comply with such ideal qualifications - as something is better than nothing.
 +
 +
{{Note|It has been suggested that the vivi.c driver and the V4L2 capture.c example do not "play well" together.  See the [[Talk:V4L Test Suite|article's discussion page]] for more details}}
  
 
* [http://git.linuxtv.org/v4l-utils.git/tree/HEAD:/contrib/test v4l-utils/contrib/test]
 
* [http://git.linuxtv.org/v4l-utils.git/tree/HEAD:/contrib/test v4l-utils/contrib/test]
Line 41: Line 43:
 
* [http://v4l-test.sourceforge.net/ v4l-test] - a V4L2 test environment based directly on the V4L2 API Specification
 
* [http://v4l-test.sourceforge.net/ v4l-test] - a V4L2 test environment based directly on the V4L2 API Specification
  
{Note|It has been suggested that the vivi.c driver and the V4L2 capture.c example do not "play well" together.  See the discussion page for more details
+
 
  
  
  
 
[[Category:Development]] [[Category:Software]]
 
[[Category:Development]] [[Category:Software]]

Revision as of 00:43, 6 October 2011

Code to test other code.

If you need a test, look here.

If you create a new test, add it here.

If you know of a test that is not listed, please add it.

Test Driver

VIVI - Virtual Video Driver

A real v4l2 device driver with no physical hardware. This means anyone can use it (it is part of the Linux kernel: modprobe vivi).

If your application has problems with a specific device driver, try using vivi instead. If you still have a problem, it is much more likely to be a problem with the application than with the driver. Knowing where to look is a big help in fixing problems.

However, vivi is not

  • perfect. Not surprising given it doesn't get the amount of real world use that real drivers do.
  • feature complete. It does not implement every interface of the v4l2 spec.

But it is something anyone can run, so it makes reproducing some problems possible that would otherwise be impossible without the specific hardware.

Test applications

Simple programs that test various functionality of a V4L2 driver.

There are many small test apps that seem to have been written to help isolate an existing problem, as opposed to actively looking for problems. This means the tests make assumptions about what is/isn't supported, which can cause false positives when someone else uses them in a different environment. For instance, a specific feature test should not be run unless the device driver advertises support for the feature. Ideally, this means that all tests should first xioctl(fd, VIDIOC_QUERYCAP, &cap) and test cap.capabilities to see if the rest of the test is applicable. However, this does not mean you shouldn't post your test code it it does not comply with such ideal qualifications - as something is better than nothing.

Note: It has been suggested that the vivi.c driver and the V4L2 capture.c example do not "play well" together. See the article's discussion page for more details
  • v4l-test - a V4L2 test environment based directly on the V4L2 API Specification