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? Regards, -- Nicolas George
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel