[vlc-devel] [PATCH] non-blocking filewriter

[Jarmo Torvinen]

vlc-devel-bounces at videolan.org wrote on 28/04/2009 12:34:38:

> Rémi Denis-Courmont <remi at remlab.net> 
> Sent by: vlc-devel-bounces at videolan.org
> 
> 28/04/2009 12:35
> 
> Please respond to
> Mailing list for VLC media player developers <vlc-devel at videolan.org>
> 
> To
> 
> Mailing list for VLC media player developers <vlc-devel at videolan.org>
> 
> cc
> 
> Subject
> 
> Re: [vlc-devel] [PATCH] non-blocking filewriter
> 
> 
> On Tue, 28 Apr 2009 11:46:30 +0300, Jarmo Torvinen
> <jarmo.torvinen at jutel.fi> wrote:
> > The patch adds following parameters to file sout plugin:
> > 
> > "sout-file-non-block"               enables/disable the non-blocking 
mode
> 
> Perhaps this could be autodetected with fstat() instead of adding yet
> another command line option?

Yes, that would be great idea. I could implement that if there is demand 
for non-blocking write in general.


> 
> You mean the kernel FIFO buffer is too small and VLC gets jerky?
> 

Well that is one issue. There are couple of other things to consider:


1) In our application, we are launching instances of vlc wrappers (using 
libvlc) and send the data via the named pipes from one vlc to another. 
If the named pipe is not opened in O_NONBLOCK for writing, the vlc wrapper 
will sit there until the other vlc starts to read from the pipe. 
Now consider situation where the other vlc instance is not properly 
launched or some other issue arises: the initial vlc will sit there 
unresponsive waiting for someone to read from the pipe (as expected).

Just try:

mkfifo /tmp/testfifo
vlc input.ts 
"--sout=#duplicate{dst=std{access=file,mux=ts,dst=/tmp/testfifo}}"

2) The buffering allows us better to skim through high CPU usage 
situations. Consider following setup (for example, four instances of 
these):

vlc-dvb-input -> fifo -> vlc-transcode (x264)

Consider that the dvb-input had opened the fifo in blocking mode. The 
dvb-transmission stream continues despite how loaded the
transcoding reader is. What would happen if the dvb-input writes linux 
fifo buffer full, and the transcoder can't keep up reading the
data as fast as the new data comes in?

If the CPU usage spike is not very long (depending on the nb buffer size), 
the additional buffering added to the non-blocking writer gives some 
time to recover after the spike is over.


Jarmo Torvinen