On Thu, 26 Nov 2015 20:46:25 +0100 Nicolas George <geo...@nsup.org> wrote:
> Le sextidi 6 frimaire, an CCXXIV, wm4 a écrit : > > Better do the looping internal in flvdec.c (if there's no huge number > > of other demuxers which need this), instead of adding a new error code > > that is also part of the public API. > > There are a few, but not many. This was my first intent, but looping in the > framework is way more elegant and much cleaner design. I fail to see how letting such a workaround (required for flv) leak to common code is more elegant. It's better to keep such exceptions to the rule inside the demuxers which violate the normal API. Or you will eventually end up with dozens of special cases in utils.c. > Nothing would prevent us from defining the error code in > libavformat/internal.h if we make sure it does not leaks to the application, > but as Michael mentioned earlier and I did in the comments for patch 2/3 in > this series, having a public code allows to give the application > fine-grained control over the looping, for example to maintain basic user > interaction while a demuxer tries to find a sync word in a big corrupted > file on a slow local medium. Such an application will have to run the demuxer in a thread. Not returning from the demuxer for a while because data is read is perfectly ok because the API is inherently blocking. What are you going to do if reading even a single packet takes milliseconds because the data is e.g. shuffled over a slow HTTP link? I don't foresee that more demuxers will make use of AVERROR_REDO when no new packet data is immediately available, only to appease to applications with broken or less than ideal IO code. > Therefore, I maintain the proposed patch as is. Disagree. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel