[vlc-devel] Pause streaming from the source and buffering to compensate
Rémi Denis-Courmont
remi at remlab.net
Tue Sep 25 21:02:12 CEST 2012
Le lundi 24 septembre 2012 18:28:37, LANGLOIS Olivier PIS -EXT a écrit :
> , "--clock-synchro=0" , "--network-caching=0" ,
> "--clock-jitter=0"
Nothing is ever going to work with zero buffering. That is physically
impossible. Depending on the VLC version, the directive will either be ignored
or playback will utterly fail (or both).
I am _absolutely_ certain that the VLC synchronization code could be improved,
as well as decoding buffer management. I am ever more certain that some plugins
could operate with lower latency (or none at all), notably packetizers and
some muxers. But there is ALWAYS going to be some overall latency.
But some insane command line options are not going to do. This is a very
complex topic, that would require serious and tedious engineering to resolve.
> It is maybe extreme but since my problem seem to be related to buffering
> and tried to be as clear as possible to the library that I didn't want any
> buffering at all. Despite my efforts, it seems that code in
> src/input/es_out.c adds buffering to compensate some problem between PCR
> updates and the input clock state.
Stating that you want no buffering at all, is very much stating that you have
no clue what you are on about. Latency is intrinsic in the digital domain.
Just to be clear: VLC has much longer latency that it could have with
hypothetical optimizations, but zero latency is not possible anyway.
> However, once the es_out module has compensated for detected sync
> problems by having enlarged decoder buffer to 3-4 seconds, this new
> buffer size seems to remain to that size even when the decoder is
> deleted/recreated because of the discontinuity caused by the
> transition when the mp4 clip restart. IMO, this is the major problem.
In normal VLC use cases, if the buffer runs out, a pause until the buffer fills
up is The Right Thing to do. Think of video on demand. The behaviour you
describe is very much intended.
VLC does not know that you are streaming interactive live content (I can only
gues that is what you do, as you did not specify). Only in that type of user
case, does it make sense to discard late buffers and skip forward to keep
latency low at all times.
So far, nobody developped that use case within the VLC core. And I am not
aware of any plans to sponsor that development, so do not hold your breath.
--
Rémi Denis-Courmont
http://www.remlab.net/
More information about the vlc-devel
mailing list