[FFmpeg-devel] [PATCH 3/3] lavf/flvdec: use AVERROR_REDO instead of AVERROR(EAGAIN).
Nicolas George
george at nsup.org
Fri Nov 27 13:32:30 CET 2015
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20151127/ac79c7c1/attachment.sig>
More information about the ffmpeg-devel
mailing list