On 5/20/16, 9:32 PM, "ffmpeg-devel on behalf of Michael Niedermayer" <ffmpeg-devel-boun...@ffmpeg.org on behalf of mich...@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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
