Streaming delay PVR 250/350 compressors

[Rafa Chao]

Hi everybody,

There is a three seconds delay when i stream MPEG2 with VLC and hauppauge PVR 250/350. The tests have been made with:

--------1---------
Hauppauge 250
VLC 0.7.2
Pentium IV
Red Hat 9
kernel 2.4.20-8
------------------

--------2---------
Hauppauge 350
VLC 0.7.2
Pentium III
Fedora Core 2
kernel 2.6.9-1
-------------------

The instruction is:

/usr/local/bin/vlc -vvv pvr:/dev/video0:norm=pal:size=720x576:frequency=576250:bitrate=3000000:maxbitrate=4000000 --sout-udp-caching=30 --sout udp:239.10.10.239:1239 --ttl 12 --cr-average 1000

How can i reduce the 3 seconds delay to, at least, one second?
Using PVR, there´s no effect using
--sout-udp-caching in the server
--udp-caching in the clients

The client used are VLC 0.8.0 with Windows


Can anybody help me?

Thanks,

[markfm]

There should be some variability when you use --sout-udp-caching=30, but it's overwhelmed, most likely, by the latency with the Hauppage card itself. I use cards that output raw video/audio. In your case you have a card that's doing its own compression, with its own internal buffers.

[Rafa Chao]

So, the answer to this problem is that using hauppauge compressors, there´s a 3 second driver delay, because of the compression.

The advantage using this kind of hardware is no CPU overloading, the disadvantage, 3 seconds delay and the cost of the card

The advantage of capturers are the price and there´s no delay, but the disadvantage is that compression must be done by CPU.

Is that the answer to the question?

[markfm]

Correct. A classic cost/performance trade.

The odds are that you can find a card that doesn't do the onboard compression for a decent amount less, and you could apply that towards the cost of a better PC to do on-PC compression.

Doing SW compression, a decent PC, you'll definitely be in that < 1 sec zone, quite easy to do. I don't get much less than around 700 ms latency, though, because of the underlying VLC architecture -- need to work with the devs to see if there are a few places that can be optimized a bit more, maybe something where a user switch can be enabled for a shortcut path internally. (Beats me)

[wentzel_2m]

Hi!

You don't mention anything about os. If you are using Linux - then go check the ivtv drivers for the hauppauge card.
There will be some delay from this card as it will wait "for some time" until sending data through as it will have to construct a valid frame starting point (well something like that - check the mpeg specs).
Bottomline you can tweak/instruct the driver with respect to how often these frames should be constructed and thus lower the delay...
Hope this helps

[Rafa Chao]

Hi wentzel_2m,

The server system is based on linux, using ivtv. In Redhat 9, the driver is compiled by me (no changes on code, just make install)

In Fedora Core 2, the driver is already compiled by third persons.

The doubt is that using VLS, there´s no delay, which means that the pvr module from VLC "makes" something that delays the data.

Using FFmpeg and FFserver, the delay is due to the feed.ffm file, variables delays between 0,5 and two seconds

In the other hand, i´m going to study the ivtv driver to see if there´s any way of changing timings....

thanks a lot for your suggestion wentzel_2m