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?
If you want to work on that (in order to bring these enhancements to the tee
muxer, fitting the topic of the GSoC project), you probably can. But I
expect this to be very hard. It has been rejected as a proposal for a GSoC
project in the past on the basis that it is probably too hard for a random
student. Also, I am not sure that Marton, your official mentor, would want
such a huge shift in the project's goals.
The only way this can work if someone steps up and helps both designing
the generic API and co-mentoring Jan.
If that not happens, I would like to stick to the original plan. We can
only hope that we will learn something valuable which can be used
later when somebody takes the time and effort to actually redesign the
API.
Regards,
Marton
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
