The VIDIOC_REQBUFS ioctl requires a v4l2_requestbuffers struct with the members
count, type, and memory. In the past only count was set as the uvideo(4) kernel
driver, via uvideo_reqbufs(), is ignoring both struct members type and memory
(pointed out by mpi@).
However, using video(1) with libv4l
(LD_PRELOAD=/usr/local/lib/v4l2convert.so video)
yields "mmap: Invalid argument" as libv4l inspects the type and memory
struct members and fails if memory != V4L2_MEMORY_MMAP.
Full initialization fixes libv4l usage which allows us to view video encodings
not directly supported by video(1), e.g., MJPEG, as libv4l can convert
encodings on the fly.
OK mglocker@
* video -q needs 'stdio rpath wpath video' (needs O_RDWR on the device)
* video -i needs 'stdio rpath' (rpath for X11 error/locale access)
* other modes (ie display frames via X11, or output frames to file with
-o/-O) need 'stdio rpath video' since we open output file/video device
before calling pledge(2).
with help from semarie@, nits from matthieu@
ok deraadt@
So that your statistics remain correct if the system wall clock is
changed during playback.
Use CLOCK_UPTIME instead of CLOCK_MONOTONIC so that statistics remain
correct across suspend/resume.
Testing by tobias@, sthen@,
and Benjamin Baier <programmer AT netzbasis DOT de>.
ok sthen@
Just stop when reaching the end of property list instead of reading
forever past its end.
Issue was introduced in my previous commit and reported by deraadt@
video(1) uses mmap and ioctls by default, those ioctls only work on
video(4) devices. If -i is passed, use read(2) instead of the mmap(2)
routines, instead of requiring the user to pass also pass the -g flag.
and display the frame rates if at least on -v is used.
* set/get the video(4) device's frame rate using VIDIOC_{S,G}_PARM.
* add new option -R which dsables frame rate adjustment. only really
useful for video(4) devices, to see the difference between the frame
rate the device generates and what it says it's configured for ...
many devices don't generate the rate they are configured if they
aren't getting enough light ...
* poll(2) input with INFTIM instead of 0 timeout, and handle the poll(2)
call being interrupted by the frame timer.
* only use usleep(3) to wait for frames if the input is a file, and
in that case, sleep for a full frame interval or until interrupted
by the frame timer.
* update the manual to describe the new -R option, that -r now sets
video(4) frame rate, and that at least one -v will display supported
properties of the hardware.
