[FFmpeg-devel] Tee improvement - discussion

[Michael Niedermayer]

On Thu, May 26, 2016 at 12:09:14PM +0200, 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.

Isnt that just a matter of making options consistent or using a option
in  AVStream / AVFormatContext which would be the same for all muxers


> 
> 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.

can you elaborate what is deeply wrong in that case ?


> 
> > 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?

How does a thread make it worse here ?

If a muxer blocks without threads the application blocks (till the
user kills it or the condition on which it blocks changes)

If a muxer blocks in its own thread the application wont block the
same moment but might block when trying to write more than the fifo
can hold or on closing, thats just blocking the same way a single
threaded design would block just a tiny bit later

maybe iam missing something but it seems the problem is the blocking
write and threads do not really add more problems to it


[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

He who knows, does not speak. He who speaks, does not know. -- Lao Tsu
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20160526/036ca90e/attachment.sig>