On Thu, 26 May 2016, Nicolas George wrote:
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.
What if we decouple the non-blocking queue and the retry on failure logic
to a separate "buffer" or "fifo" muxer?
This seems like what you are trying to do, and by using the exisiting
muxer interface, we don't have to design new API around it.
Although I don't yet see if using three levels of muxing (E.g. the tee
muxer invokes the fifo muxer, which will invoke the underlying real muxer)
can cause any unseen problems or not.
Regards,
Marton
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
