[FFmpeg-devel] Tee improvement - discussion

[Michael Niedermayer]

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


[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Everything should be made as simple as possible, but not simpler.
-- Albert Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20160521/347a7011/attachment.sig>