[vlc-devel] Pause streaming from the source and buffering to compensate
LANGLOIS Olivier PIS -EXT
olivier.pis.langlois at transport.alstom.com
Tue Sep 25 21:46:40 CEST 2012
Thank you for your reply. I just want to clarify a small detail. I am not seeking a zero latency solution.
My application is the streaming of a long sequence of mp4 files (playlist).
Playback is smooth as long as you let streamer alone (vlc also). As soon as you pause/unpause the stream on the streamer side, you will get a 4-5 seconds playback freeze at the beginning of every video clip. This is the problem. If you reread my original post, what it is, it is my analysis of why this is happening. It should be very easy to reproduce with 2.0.3
It occurs in src/input/es_out.c in the switch case for
It is fixed in my app as I have commented most of that block (of course this has led to other problems which had made me butcher some more vlc making my solution not friendly to the vlc general audience).
To me having video playback freezing for more then 15% of the time is unacceptable. Feel free to disagree. I wanted to attract your attention to the issue. I am glad to see that feedback user is appreciated.
From: Rémi Denis-Courmont [mailto:remi at remlab.net]
Sent: Tuesday, September 25, 2012 3:02 PM
To: vlc-devel at videolan.org
Cc: LANGLOIS Olivier PIS -EXT
Subject: Re: [vlc-devel] Pause streaming from the source and buffering to compensate
Le lundi 24 septembre 2012 18:28:37, LANGLOIS Olivier PIS -EXT a écrit :
> , "--clock-synchro=0" , "--network-caching=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.
CONFIDENTIALITY : This e-mail and any attachments are confidential and may be privileged. If you are not a named recipient, please notify the sender immediately and do not disclose the contents to another person, use it for any purpose or store or copy the information in any medium.
More information about the vlc-devel