On Fri, 27 Nov 2015 13:53:33 +0100 Nicolas George <geo...@nsup.org> wrote:
> Le septidi 7 frimaire, an CCXXIV, wm4 a écrit : > > I might not be familiar with flvdec in particular. Can you explain me > > how Matroska could be switched to non-blocking? > > It can not, and this has NOTHING to do with the current discussion. > Non-blocking mode requires the demuxer to be able to stop at ANY position in > the octet stream, it is very hard to achieve. > > What was evoked here was a low-latency mode, where the demuxer returns as > soon as CONVENIENTLY possible. Oh, ok. I still do not see how a potential flag to make the API user to be able to use this is better than running the demuxer in a thread. I'm talking about practice, not theory. Such a flag would work _sometimes_, with _some_ demuxers in _some_ very specific situations, and which will only be low latency if the AVIO behind it is also low-latency. On the contrary, I see this (proposed, not even realized) feature, which will be half-broken at the moment of its inception, become yet another feature that nobody uses and that bitrots as time goes. Note that I'm not stopping you. I only questioned that the fix to the flvdec issue was not minimal. > I am not familiar enough with the Matroska demuxer, which seems rather > convoluted, to tell how it could be changed. > > > I'm trying to prevent that people add more complex special cases > > libavformat/utils.c. One special case is not a tragedy, but millions of > > special-cases interacting are an unmaintainable mess. > > I am not trying to add millions of special-cases, just one. Since you > pretend you are not making a "slippery slope" fallacy, explain what these > millions are about. utils.c is full of special conditions that barely anyone knows what they are about. This is not just my opinion. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel