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