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 ([EMAIL PROTECTED] 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).
