so other muxers like flv shouldn't hit this performance bottleneck? I'll check it out with flv, thanks!
btw, on the servers I'm using, it takes 6 seconds to mux 1mb of media into an mp4, that's quite slow ... On Mon, Sep 2, 2013 at 3:38 PM, Martin Storsjö <[email protected]> wrote: > On Mon, 2 Sep 2013, Vladimir Pantelic wrote: > > On 08/29/2013 11:51 PM, Martin Storsjö wrote: >> >>> Hi, >>> >>> On Thu, 29 Aug 2013, aviad rozenhek wrote: >>> >>> the question is, why is libav using unbuffered I/O, and does moving to >>>> fopen make sense? >>>> >>> >>> Because libav already has got a buffering layer of its own, AVIOContext, >>> which provides buffering on top of whichever unbuffered API is used >>> below (file descriptors, sockets, etc). If this buffering doesn't work >>> properly for your case, you're probably hitting some corner case in it >>> where the buffering doesn't help as much as it should (or the input file >>> is structured in a way that forces the IO layer to seek a lot). >>> >>> Instead of adding buffering at yet another layer it would make more >>> sense to try to figure out why the existing buffering doesn't help in >>> your particular case, and if there's something that can be done about it. >>> >> >> as he said: >> >> I'm seeing slow I/O performance in libav while muxing mp4 files. >>> >> >> is there any buffering layer in case of muxing MP4? I'd guess there is >> none, no? >> > > Yes, the AVIOContext buffering layer is most certainly used here as well. > However it does seem that every single packet that is written is flushed > immediately. This line can be traced back to the commit where the mov muxer > was added, in 1cb5f7fd. > > I would guess that this line can be removed without any issues, but I'd > have to double check a few setups to make sure it doesn't silently break > any of the existing setups. > > // Martin > _______________________________________________ > libav-devel mailing list > [email protected] > https://lists.libav.org/mailman/listinfo/libav-devel > -- Aviad Rozenhek _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
