[FFmpeg-devel] Tee improvement - discussion

[Felt, Patrick]

On 5/20/16, 9:32 PM, "ffmpeg-devel on behalf of Michael Niedermayer" <ffmpeg-devel-bounces at ffmpeg.org on behalf of michael at niedermayer.cc> wrote:

>On Fri, May 20, 2016 at 12:06:34AM +0200, Marton Balint wrote:
>> 
>> On Thu, 19 May 2016, Nicolas George wrote:
>> 
>> >Le tridi 23 floréal, an CCXXIV, Jan Sebechlebsky a écrit :
>> >>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.
>> ><snip>
>> >>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 must say, I am not very happy with the direction this project takes.
>> >
>> >Non-blocking muxers (and demuxers, and protocols) is a white whale for our
>> >API: we really really want it, but it huge and very hard to catch.
>> >
>> >It is something that needs to be implemented globally with a very careful
>> >design. Definitely not something that can be added in a corner of an obscure
>> >muxer. We already went down that path twice, with the thread for the UDP
>> >protocol and with running demuxer in threads in FFmpeg. Both did lead to
>> >endless complications: bugs, inconsistencies, portability trouble.
>> 
>> What caused these complications? Do you have some references?
>
>i dont know, what i remember as udp problems are things that shouldnt
>affect tee like:
>
>some UDP "users" like RT*P
>bypass the public API and pull the UDP fd out of the demuxer and
>then try to use it polling and stuff (ffurl_get_file_handle)
>this doesnt work so well, as teh fd is on the input side of the que
>and what came out of the udp code is on  the output side and in
>different threads
>
>another issue with udp i remember is timing
>packets should have "transmit times" from the muxer in them so
>they get sent at the correct time, thats not done even though muxers
>like mpeg-ps calculate these times correctly

there was discussion on this just today in the #ffmpeg channel.  Mpeg-ts over udp users using hardware decoders could use this functionality.

>
>
>[...]
>
>-- 
>Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
>Everything should be made as simple as possible, but not simpler.
>-- Albert Einstein