Le sextidi 6 frimaire, an CCXXIV, wm4 a écrit : > I fail to see how letting such a workaround (required for flv) leak to
... and a few other demuxers... > common code is more elegant. You fail to see, but I do, and I am not alone: http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2015-October/180681.html > eventually end up with dozens of special cases in utils.c. "Slippery slope" fallacy. > Such an application will have to run the demuxer in a thread. Can we use threads to get peace in the Middle East too? Threads seem to be your solution to almost everything, but you fail to realize they bring a whole lot of problems of their own, ranging from portability to trickiness and memory consumption. If you want to use threads everywhere, fine, by all means do so. Bu please have the decency not to bikeshed proposals that make it easier NOT to use them when they do not make your life easier. > 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? Unrelated. > 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. This block is fairly unclear, but the way I understand it, it is another "slippery slope" fallacy. Regards, -- Nicolas George
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel