[FFmpeg-devel] [GSoC] Tee muxer improvement project (fifo muxer)

Jan Sebechlebsky sebechlebskyjan at gmail.com
Tue Aug 23 02:21:43 EEST 2016


Hello,

GSoC 2016 is almost over, so I am sending brief summary of the project 
(links to my work are at the end of this e-mail).

Original plan was to improve tee muxer so that:

1. outputs will not block each other (occasional long I/O operation on 
single output will not delay processing of other outputs)

2. failure of single output will not necessarily cause failure of whole 
process

3. recovery can be transparently attempted on failed output(s)

After initial discussion where Nicolas pointed out that proposed changes 
are too specific to be part of tee muxer, Marton (my mentor) suggested 
to implement new "fifo" pseudo-muxer which would allow to run actual 
muxer in separate thread (satisfying 1. requirement) and would be 
cabable of transparently restarting output in case of error (satisfying 
3. requirement).

I've implemented on_fail per-slave option (dealing with 2. requirement) 
to tee as qualification task. Currently patches implementing 
functionality mentioned above are already part of the codebase (changes 
in tee muxer and new fifo pseudo-muxer).

See documentation http://ffmpeg.org/ffmpeg-formats.html#tee
and http://ffmpeg.org/ffmpeg-formats.html#fifo for usage info.

        After initial version of fifo muxer was implemented, Nicolas 
insisted on implementation of nonblocking mode support 
(AVFMT_FLAG_NONBLOCK), which would allow developers to use this muxer to 
get nonblocking write_header/write_packet/write_trailer calls with 
muxers not naturally supporting nonblocking mode. This required some 
small changes in API and internal functions (av_write_packet, 
write_packet, av_write_trailer) and addition of av_write_abort() 
function which can be used to force-stop nonblocking muxer operation. 
Patches implementing these changes and adding AVFMT_FLAG_NONBLOCK 
support for fifo muxer are already being reviewed in mailing list.

Tee muxer was using deprecated bitstream filtering API, and there was no 
support for processing list of bitstream filters in new BSF API. 	I've 
decided to implement this as a side project based on Nicolases and 
Martons suggestions. Patches implementing this new API are already 
accepted, patch switching tee to this new API is currently reviewed in 
mailing list.

Probably the only drawback of implementing "fifo" features in separate 
muxer is that setting up tee with fifo for slaves is uncomfortable - it 
includes 3 muxers on top of each other which means trouble with lots of 
escaping of arguments for "inner" muxers (fifo and actual muxer).
To eliminate this I've decided to add options and per-slave options to 
the tee muxer which will allow to turn on/off and configure fifo 
functionality for the slaves (globaly for all slaves or override global 
behaviour for individual slaves). This way usage of fifo does not add 
another "muxer level" from the user point of view. This patch depends on 
patch changing bsfs API in tee, so I will send it to mailing list as 
soon as that patch is applied.

Apart from what is mentioned above, I've also fixed several bugs I've 
encountered, done some minor refactoring and implemented FATE tests for 
the newly added code (and tee).

You can find all my accepted patches in FFmpeg codebase:

https://github.com/FFmpeg/FFmpeg/commits/master?author=jsebechlebsky

all my patches which are currently being reviewed can be viewed on 
patchwork:

https://patchwork.ffmpeg.org/project/ffmpeg/list/?submitter=3

and all my commits, including those which were not yet submitted to the 
mailing list, can be found in my FFmpeg fork on github:

https://github.com/jsebechlebsky/FFmpeg/commits/master?author=jsebechlebsky

I would like to thank everyone who helped me during the GSoC by 
participating in reviews, discussion and making constructive 
suggestions, especially to my project mentor Marton Balint and also to 
Nicolas George who often reviewed my work and noticed what I've missed.

I will try to participate in FFmpeg development also after end of GSoC.

Regards,

Jan



More information about the ffmpeg-devel mailing list