[FFmpeg-devel] Tee improvement - discussion

Jan Sebechlebsky sebechlebskyjan at gmail.com
Wed May 11 17:16:23 CEST 2016


Hi,
I'll be working on tee muxer improvement during GSoC 2016 and I thought 
maybe it is a good idea to ask about ideas which any of you might have 
regarding what could be done in avformat/tee.

Currently, the tee muxer works in a simple way, incoming packets are 
just iteratively fed to several output muxers (each muxer blocking the 
next). Also there is no possibility to reset muxer on error.

My current idea is to create queue for each output (as Marton suggested) 
and process each output in separate thread. I was also considering using 
just single queue, but since the AVPackets are referenced counted, the 
memory overhead is negligible and using multiple queues will simplify 
the code. Apart from getting advantage of non-blocking processing with 
multiple slave muxers, error handling will also be improved.

The option allowing to ignore failure on certain outputs is already 
implemented (this allows for example network streaming to continue even 
after disk fills up, or recording to file to continue when network error 
occurs). In the final solution the tee muxer will also support 
restarting failed output. There is a question how to deal with restart, 
there are several options what to do and this could be also configurable 
for the user (with reasonable default set):
(Does these options make sense to you? Do you have ideas for more? )
     - Attempt restart immediately after failure, if it doesn't succeed 
attempt with the
next packet (keyframe). Repeat  <k>(argument) times before giving up on 
that output.
     - Attempt restart after certain time <t>(argument).
     - Combination of two options above. Attempt to recover with next 
keyframes, after several failures wait for some amount of time and 
attempt again.

Another question is what to do when some of the queues becomes full, 
discussed options were so far:
     - Block write_packet call until the queue frees - this might be 
useful when producer is faster than consumer, and we don't want to drop 
any packets when recording to file.
     - Drop some yet unprocessed packets (until next keyframe, or free 
some portion of queue) to free the queue - this might be useful for 
network outputs.

I'm thinking of implementing this queue by wrapping up AVFifoBuffer 
(similarily than AVThreadMessageQueue does but with the configurable 
behaviour as described above).

If you have any ideas or notes regarding what would be good to do in 
libavformat/tee and want to join discussion, I'll be glad to take them 
into account and improve the proposed project.

Regards,
Jan S.


More information about the ffmpeg-devel mailing list