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 [email protected] http://lists.saillard.org/mailman/listinfo/pwc
