[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