On Thu, 26 Nov 2015 21:21:08 +0100 Nicolas George <geo...@nsup.org> wrote:
> 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. > Not really. > > 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. Well, unlike with peace in middle-east, everyone already figured out that threads are a good solution to I/O. Especially for an API that is blocking anyway. > 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. Sorry, but this doesn't have to do with anything, especially not with my life. What's it with personal attacks on my life anyway? (I also haven't heard yet whose life is supposed to get easier by letting the user handle EREDO.) As I've already said, using threads for I/O is commonly accepted, and also the libavformat API is already this way. Why do you treat my suggestion to use a thread with so much scorn? What you suggest is adding a special-case for a single demuxer (and maybe 1 or 2 others? you didn't make it clear). And this special-case looks pretty unwarranted. All other demuxers follow the rule to read data until a packet is found, and then return that packet. And if I/O is slow or if a lot of data has to be read to find a packet, every single demuxer blocks. I really don't understand your thinking here anyway. Didn't you say yourself that polling is bad? I'd also like to hear from you how an application is supposed not to block its GUI without running the demuxer in a separate thread? (Please answer with a solution that does _not_ require rewriting every single demuxer and AVIO protocol.) And what exactly warrants handling flv differently, but not, say, Matroska or AVI? Also, I'm not blocking your patch. I'm just suggesting that flvdec.c should handle this internally. > > 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. This is not about "slippery slopes", it's about consistency. I.e. avoiding unnecessary special-cases, which is always good for an API. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel