[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