[vlc-devel] LIVE (low latency) decoding with various VLC version.
david.glaude at gmail.com
Tue Mar 9 13:09:47 CET 2010
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
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
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
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
> > 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.
> 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
> $(gitk src/input/) shows, but I am not very familiar with it.
> Rémi Denis-Courmont
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the vlc-devel