[vlc-devel] What *-caching should we use? (was: LIVE (low latency))

David Glaude david.glaude at gmail.com
Sat Apr 17 13:01:51 CEST 2010


We are still trying to get the most stable VLC with low latency. Nowdays we
try with VLC 1.0.5 waiting for 1.1.0.
However we fail to see wich *-caching parameter we need to use.

Our stream is multicast UDP+RTP packet described by an SDP file wich is
downloaded via http and we are on WIN32 with VLC player (and next come the
IE pluggin).

On IRC I was suggested --udp-caching or --rtp-caching but once it was clear
that LIVE555 was involved we got the advice to go for --rtsp-caching

In order to find out wich *-caching to use... we tried all of them... and we
decided to use very high value (10s) to see if we could get high latency.

"C:/Program Files/VideoLAN/VLC/VLC.exe" --rtsp-caching 10000 --udp-caching
10000 --realrtsp-caching 10000 --rtp-caching 10000 MCAST.sdp
"C:/Program Files/VideoLAN/VLC/VLC.exe" --rtsp-caching 40 --udp-caching 40
--realrtsp-caching 40 --rtp-caching 40 MCAST.sdp
"C:/Program Files/VideoLAN/VLC/VLC.exe" --rtsp-caching 10000 --udp-caching
10000 --realrtsp-caching=10000 --rtp-caching=10000 MCAST.sdp
"C:/Program Files/VideoLAN/VLC/VLC.exe" --rtsp-caching 40 --udp-caching 40
--realrtsp-caching=40 --rtp-caching=40 MCAST.sdp

But whatever we try we always get a rather good latency were we expect (but
we don't know why on on wich parameter we are suppose to be able to play).
We also tested with various syntax such as :rtsp-caching=10000 and
:rtsp-caching 10000.

Does anybody has a clue on what we did wrong or wich *-caching we should try
next. We would like to stop doing random guess.

Here is the content of our SDP file (MP4 part 2 video only)... if it help:
o=- 13006724340976744 13006724340976745 IN IP4
c=IN IP4
t=0 0
m=video 1500 RTP/AVP 96
a=rtpmap:96 MP4V-ES/90000
a=fmtp:96 profile-level-id=3;


David Glaude

PS: Next step is to text started from msys with -vvv to have more debug.

2010/3/9 David Glaude <david.glaude at gmail.com>

> I have some bad from my test of VLC 1.0.2...
> This morning both the stand-alone player and the IE Plugin where freezed
> (video freeze) after a bit more than 7H of assumed continuous playing (I was
> not there overnight to monitor it). There may have been some network event
> (packet lost or such) but at least they were not user generated in order to
> test VLC robustness. Unfortunately there was no other player (QT/GPAX) to
> see if they had the same trouble and were also freezed. "F5" did fix it for
> the plugin and STOP/START did fix it for the player (so the encoder was
> still running).
> Unfortunately the debug message do not have a time stamp, so I can only
> assume that the problem is related to this new (to me) message: "avcodec
> error: more than 5 seconds of late video -> dropping frame (computer too
> slow ?)".
> main warning: late picture skipped (2603 > 0)
> main warning: late picture skipped (3603 > 0)
> avcodec error: more than 5 seconds of late video -> dropping frame
> (computer too slow ?)
> main warning: late picture skipped (40621 > 0)
> main warning: late picture skipped (5621 > 0)
> Right now I do not know exactly what I am going to test next... and were I
> need to dig in the code between 1.0.2 and 1.0.3 for possible change that
> affect the behaviour.
> I have also seen in trac some low latency related parameter, but I don't
> know if they are still current.
> I know that refresh "F5" of the page every hour can help so I will try that
> path either with VLC 1.0.2 or with VLC 1.1.0-git.
> ...
> Any other place within VLC code where 10, 20 or 30s of video can be stored?
> What is the best way to document the problem so that it can be reproduced?
> (network trace? how to enable more debuging or timestamping of the debug
> message?)
> David Glaude
> Le 8 mars 2010 21:51, Rémi Denis-Courmont <remi at remlab.net> a écrit :
> Le lundi 8 mars 2010 22:38:09 David Glaude, vous avez écrit :
>> > VLC-1.0.2-win32.exe (E) give us the best result for the low latency and
>> for
>> > maintaining that low latency over time and despite packet loss.
>> > Some change occured between 1.0.2 and 1.0.5 that change the behaviour
>> and
>> > introduce additionnal latency.
>> > The problem is not fully solved with "--clock-jitter=0" in 1.1.0-git and
>> > there must be other buffer involved that were not triggered before.
>> > Presentation buffer? Decoding buffer? RTP Buffer?
>> The RTP reorder buffer code has been pretty much unchanged since... 1.0.2.
>> The
>> RTP plugin only buffers when reordering occurs. De-jittering really is
>> done
>> downstream in the input clock synchronization code.
>> There's been quite a bunch of changes to that piece between 1.0.2 and
>> 1.0.3 as
>> $(gitk src/input/) shows, but I am not very familiar with it.
>> --
>> Rémi Denis-Courmont
>> http://www.remlab.net/
>> http://fi.linkedin.com/in/remidenis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20100417/57b6edcd/attachment.html>

More information about the vlc-devel mailing list