On Sat April 6 2013 14:28:12 Tzu-Jung Lee wrote: > Hi, > > I'm writing device v4l2 driver for our video codec, which can be configured to: > > 1. decode bitstream and output to TV (output device) > 2. capture video input, and generate encoded bitstream. (capture device) > 3. transcode input bitstream to another format output bitstream. > (mem2mem device) > > And I got some questions regarding the GENERIC way to handle the "end > of stream" when doing STREAM I/O. > (Perhaps these questions are only relevant to bitstream data instead of frames?) > > 1. Capture path: how does the device driver notify the user > program the end of captured bitstream? > 2. Output path: how does user program tells the the driver the end > of output bitstream? > > Based on the http://linuxtv.org/downloads/v4l-dvb-apis/capture-example.html, > I wrote a program, which can do the stream I/O with our V4L2 driver. > > For capture path: if the device has stopped, the program will get > a zero-size (bytesused = 0) buffer when it DQBUF. One example is the Samsung MFC driver: drivers/media/platform/s5p-mfc. Basically the application will get an EOS event. It is also possible to command the encoder to stop by calling VIDIOC_ENCODER_CMD. > For output path: If the program has read the EOF of input file, it > QBUF a zero-size buffer to notify the driver. Use VIDIOC_DECODER_CMD with the stop comment and a pts value of 0. > However, this is just the "vendor-specific" way. And I'm wondering > what is the "generic" way to this? > > > > The v4l2-ctl is really handy, and helps me to develop the "control" of > drivers. I'd like to use it for testing STREAM I/O functions as well. > > But I have questions regarding Streaming I/O in v4l2-ctl. > > v4l-utils/utils/v4l2-ctl/v4l2-ctl.cpp: > > 1. For the path of "--stream-out-mmap", isn't it supposed to set > the payload size (buf->bytesused) after filling data read from STDIN > or file? Yes, it should. I'll fix this. Until now I've only used this with uncompressed video and those output drivers just ignore bytesused. I'm not sure whether that's a feature or a bug :-) For compressed data bytesused definitely needs to be set. > 2. For capture path, user programs have to initially QBUF empty > buffers for drivers to fill data. > However, for output path, do we need to QBUF empty buffers > before the filling loop start? > Or we only QBUF filled buffers when the loop starts. You need to queue filled buffers in the output case. > It seems to me drivers can't use the buffer length to distinguish if > the queued buffer are empty or filled ones, right. No, the buffer length is the actual buffer size and that is fixed. 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
