[FFmpeg-devel] Tee improvement - discussion
george at nsup.org
Thu May 26 12:09:14 CEST 2016
Le duodi 2 prairial, an CCXXIV, Marton Balint a écrit :
> What caused these complications? Do you have some references?
I do not remember exactly. There is the problem quoted by Michael. There is
also a more global issue that options will be inconsistent: one
implementation of non-blocking would have some set of options to control the
queue size and overflow behaviour and such, and another implementation will
have a different set of options. All very confusing for the user.
Guideline: if at some point it makes sense for the users to run the tee
muxer with a single output, just to get extra features it brings, then there
is something deeply wrong with the design.
> 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.
My advice would be to try and focus on enhancements other than non-blocking
output. If that is not possible, and the "stick everything in threads"
approach is chosen, then IMHO it must not go in the tee muxer itself.
But the "stick everything in threads" approach is flawed. Just think about
what will happen if the actual muxer is blocking on a write while the
application, seeing non-blocking behaviour, wants to close it: how do you
kill the blocked write?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: Digital signature
More information about the ffmpeg-devel