Le septidi 7 frimaire, an CCXXIV, wm4 a écrit : > Not really. EARGUMENTNOTFOUND.
> Well, unlike with peace in middle-east, everyone already figured out > that threads are a good solution to I/O. Argumentum ad numerum fallacy. Experienced people figured out that threads are a BAD solution to I/O. I explained why. > Especially for an API that is blocking anyway. We have a non-blocking API. It works only for a few demuxers, but we have it. I will oppose any change that would make threads mandatory. Basic sanity check: I hope you realize that a library can provide several kinds of API. Or, in terms of logic: A mandatory, B forbidden A forbidden, B mandatory -> there is also: A authorized but not mandatory, B authorized but not mandatory You like threads. Do threads. Nothing I propose prevents you from doing threads. But please refrain from hindering efforts for people who do not want to use threads. > 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? This was not a personal attack, "make your life easier" is just an idiomatic turn of speech. Did you not know it? > also the libavformat API is already this way. Untrue. It allows it, but it does not make it mandatory, at least theoretically. > 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 many other demuxers could then be simplified using that infrastructure. > I really don't understand your thinking here anyway. Didn't you say > yourself that polling is bad? This is not polling. > 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.) This is indeed not currently possible, but having a working non-blocking API is a goal for many of us. If you do not share that goal, fine, but once again: PLEASE REFRAIN FROM HINDERING OUR WORK. > Also, I'm not blocking your patch. I'm just suggesting that flvdec.c > should handle this internally. And I am saying that it is better design to share common code. You may notice that it is already done when discarding is done by the framework rather than the demuxer. > This is not about "slippery slopes", it's about consistency. I.e. > avoiding unnecessary special-cases, which is always good for an API. My proposal does not add a special case in the API. Regards, -- Nicolas George
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel