[FFmpeg-devel] [PATCH] libavformat: Add FIFO pseudo-muxer

[Nicolas George]

Le primidi 11 messidor, an CCXXIV, Jan Sebechlebsky a écrit :
> I don't understand this note - the fifo_format option is used (and seems to
> work)?

My bad, I did not notice the field had a different name.

> Unfortunately :( Do you think cmd muxer initialization could be easily
> modified in a way that muxer would also get access to option dictionary?

Alas, I do not think so.

>			Can you specify what could be the problem when the
> application does not see the time base of real muxer?

I can imagine an application that detects the muxer supports only low frame
rates like that an takes measures. But that is rather minor.

> I'll add the comment. I've tried to do this without the extra lock at first
> by setting error to the thread message queue and adding threadmessage queue
> flag which allows the error to be returned immediately, but I think using
> this single extra lock is really cleaner solution, I would prefer that.

I will see the new code and the comments. Ideally, the thread message queue
API should be enough to handle all cases, but it may be too hard to achieve.
If the code is simple and robust, then it is good.

> This is not yet exposed to the user via cmd options, do you think I should
> add this flag to options in option_table.h (for encoding only)?

Options are meant for cases where it makes sense to let the user choose. If
the user were to enable non-blocking, the application would just treat all
the EAGAIN as fatal errors. Blocking or non-blocking is a choice by the
application, and is set by setting a flag in an integer field.

> Can you please explain little bit more why is this wrong (appart from the
> undocumented requirement for the interrupt callback to be thread-safe)?

If your worker thread is blocked on an I/O operation when the application
tries to close the muxer, it will send the corresponding messages and call
pthread_join(). Since the worker thread is still blocked in the I/O
operation, it will be stuck like that forever. To avoid that, the main
thread needs to arrange for the I/O operation to be cancelled
asynchronously, and that is what the interrupt callbeck is for.

On the other hand, we do not want to cancel writing the trailer if it is
just a little slow, so there must be some kind of timeout.

All this non-blocking business is very hard if you delve into the details.

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20160707/d5c3dfea/attachment.sig>