[FFmpeg-devel] [PATCH 3/3] lavf/flvdec: use AVERROR_REDO instead of AVERROR(EAGAIN).

[Nicolas George]

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
-------------- 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/20151126/37ef01ed/attachment.sig>