Le quintidi 25 messidor, an CCXXIV, Marton Balint a écrit : > Please point me to an application which uses ffmpeg non-blocking mode like > it is supposed to be used. I don't see any muxers wich return EAGAIN, only > protocols, and they only return EAGAIN if AVIO_FLAG_NONBLOCK is set. I > wonder how that can work for av_write_trailer, because - as I mentioned > earlier -, av_write_trailer must free private data, so you simply cannot > call it multiple times. > > Prove me wrong, but I have a feeling that the current AVIO_FLAG_NONBLOCK > mode in ffmpeg was mostly tested for input, never for output, it does not > work properly for output, and to be frank I don't want to get into fixing > it, when our goals can be achieved without dealing with this problem.
Yes, it does not work. That is exactly the problem. Non-blocking mode never worked except for the low-level protocols (TCP, UDP) and a few devices. I can therefore not show you any application that use it, they do not exist. But non-blocking mode is important. Except for very simple applications, blocking mode is unusable. The only solution right now is for the application to use threads, and threads are very tricky to use, both because of portability concerns (see all the framework in FFmpeg to handle several threads implementations and all the trouble it has caused in the past) and because of the difficulty of implementing the communication without bugs and race conditions. The FIFO muxer, if implemented correctly, could be a big first step towards providing a working non-blocking mode. Regarding the issue of returning EAGAIN from write_trailer(), you have to realize that the few devices that actually work in non-blocking mode (I can vouch for ALSA, I suspect a few other work too), blocking cannot happen in the close phase, and therefore returning EAGAIN there is not necessary. But since other muxers could block there the case must be handled. Returning EAGAIN and not freeing everything is the only sane way to do it. I grant you that it would require an API for aborting-and-freeing immediately. This is not very hard to do, and is actually useful in its own self. > Therefore I would like to keep the fifo muxer as Jan submitted it, without > EAGAIN support. If there is a use case for non-blockingingness in a sense > you use the phrase, then it can be added later. I am against it. As it is, I consider it is way too specific to be added to the code base. Implementing the FIFO muxer correctly, on the other hand, would by far overshadow anything that could be done on the tee muxer in the foreseeable future. And since the work it requires on top of what Jan already did is rather small, I really do not understand why you are fighting against it. Regards, -- Nicolas George
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
