[FFmpeg-devel] Tee improvement - discussion

Jan Sebechlebsky sebechlebskyjan at gmail.com
Thu May 19 14:55:39 CEST 2016


Hello Nicolas,

On 05/19/2016 12:44 PM, 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.
Does this objection apply to the non-blocking full queue handling stated 
above or the whole project (using threads in tee)?
> 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.
>
> 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.
     I must accept that for now I may lack the complete overview over 
the project to see the potential problems which this could introduce.
However in the proposed project there is enough time to do proper 
testing and eliminate the found issues and the solution described in 
proposal could still be a benefit (if the ideal solution is too hard). 
Also I thing the proposed changes will not bring too much complexity to 
the project regarding thread handling.
     I don't mind changing the plans and implementing it in other way if 
it is better and achievable - but you might be right this may be too hard.
Anyway if you give me some directions, (what are the requirements for 
the more general solution, what are the particular problems in the 
proposed one) I can at least try to dive more into it (getting more 
familiar with the project will be only a benefit).
     I don't know how such changes are handled in GSoC (since I probably 
wouldn't be able meet milestone if the solution would require the 
complex global changes first).

> Regards,
>
>
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Thanks,

Regards,
Jan S.


More information about the ffmpeg-devel mailing list