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?
Thanks,
Luca
--
_____________________________________________________________________________
Copy this in your signature, if you think it is important:
N O W A R ! ! !
