[mpeg2] Re: buffering in the MPEX driver

[Andrew de Quincey <adq_dvb@lidskialf.net>]

On Monday 10 May 2004 13:46, Luca Abeni wrote:
> Hi all,
>
> this morning, I finally got an MPEX board, and I am beginning to
> experiment with it... After installing v4l2 (saa7134 driver version
> 0.2.9), everything seems to work fine, and "cat /dev/video1 > test.mpg"
> produces a valid TS file (I still have to check A/V synch, because I
> cannot plug any audio connector in the board's audio input, but the
> video seems to be ok).
>
> Now, the problem: I need to stream the TS generated by the board, hence
> it is _very important_ to read the packets containing the PCR "at the
> correct time". I wrote a simple test program that reads TS packets from
> /dev/video1 (reading 188 bytes per time), checks if a packets contains
> the PCR, and computes some statistics.
> It happens that the difference between two consecutive PCR values is
> about 40ms (it goes from about 40.4ms to about 41.4ms), while the
> difference between the times when such packets are read is a sequence
> 80ms / 400us / 80ms / 400us /...
> Hence, I guess the driver is buffering about 40ms of TS before sending
> it to user space... And buffering packets containing the PCR is not a
> good idea, I think.
> I don't know anything about v4l2, hence I might be reading the stream in
> the wrong way (in this case, how should I use the v4l2 interface to read
> the TS?).
>
> Anyway, I had a quick look at the driver, and I tried to modify the
> value of TS_NR_PACKETS in drivers/media/video/saa7134-ts.c. Reducing it
> to 4 reduced the jitter in the PCR generation times, and my application
> seems to be quite happy with it (there still is a 2ms jitter, but this
> is much better than the default 40ms ;-).
> I am wondering if I did the right thing, or if there is a simpler (and
> more correct way) to reduce the jitter on the PCR...
>
> Also, it seems to me that the current behaviour of read() on /dev/video1
> is: "block until the driver's internal buffer (that seems to be 188 *
> TS_NR_PACKETS bytes large) is full". I think that a more appropriate
> behaviour would be: "block until the driver's internal buffer is full,
> or until a packet containing the PCR enters the buffer". Is it possible
> to implement such behaviour? If yes, where in the driver should I look?

Hmm, I only wrote the saa6752hs part of that driver. I'd suggest contacting 
Gerd Knorr (kraxel@bytesex.org linux.bytesex.org) about changing that sort of 
thing.

However, I'm under the impression that the read() interface is only one way of 
reading data from a v4l2 device - I think theres an IOCTL interface as well, 
which might give you more control over buffering etc (I might be wrong 
though).