Hi,
I've been writing a few mails about the implementation of the streaming
functions in pwc.
I am talking about the ioctls
VIDIOC_DQBUF
VIDIOC_QBUF
VIDIOC_STREAMON
VIDIOC_STREAMOFF
I think those are related to the fact that mplayer hangs at the end of a video
played from pwc with
v4l2.
I have not received any feedback so far, so I might say something not exact.
Please correct me.
Usually an application should queue all buffers (QBUF) and then in a loop
dequeue a buffer (DQBUF),
use it, and requeue it.
A driver should only dequeue buffers that have been queued.
When STREAMOFF is called all queued buffer should be destroyed, and following
calls to DQBUF should
fail.
As a source of that I've read
http://lwn.net/Articles/240667/
http://www.linuxtv.org/downloads/video4linux/API/V4L2_API/spec/r8849.htm
and the example code
capture-example.c at linuxtv mercurial under v4l2-apps/test/capture-example.c
I think the implementation of those function in pwc has the following issues
1) it does not keep track of which buffers have been queued and behave as they
are always queued and
available to the driver
2) STREAMOFF does not destroy any buffer (since there is no list of them)
3) after STREAMOFF, since the list should be empty, DQBUF should return
-EINVAL. pwc does not know
about that and waits forever.
4) DQBUF should not block if a buffer is not ready and the device has been
opened with O_NONBLOCK.
The hangs is due to the fact that mplayer calls
1) STREAMOFF
2) DQBUF in a loop (this should return -EINVAL, but pwc never returns, since it
is waiting for a
buffer that never arrives (STREAMOFF stops the reception from the camera))
I think mplayer could get rid of the redundant calls to DQBUF after STREAMOFF,
but I don't think it
qualifies as a bug.
I would like to have a second opinion about that before changing those
functions in pwc.
Cheers
Andrea
_______________________________________________
pwc mailing list
http://lists.saillard.org/mailman/listinfo/pwc
|