Le sextidi 6 prairial, an CCXXV, Daniel Kučera a écrit : > If we return 0, then it is considered as EOF by calling functions > (e.g. avio_read). So returning 0 means: "this is end of stream" and > not: "we received zero length packet, but more data may be coming" and > thus the stream processing ends. I need to fix this behavior, example > errors are described here: > https://blog.danman.eu/new-version-of-lenkeng-hdmi-over-ip-extender-lkv373a/#comment-478
Sorry for the delay, I was busy. FFmpeg inherits the inconsistency of the Unix API it imitates: 0 sometimes means EOF, but not always. But unlike Unix, FFmpeg has a code for explicit EOF, so it does not have to be inconsistent. But the correct way of making it consistent is to use AVERROR_EOF always, and never give a special role to 0. Your patch is going the opposite direction, and as such wrong. The right way is to find the places that use 0 as EOF and fix them. As is, this patch would make something that is currently possible with the API (implementing protocols that rely on empty packets) impossible, and that cannot be accepted. Regards, -- Nicolas George
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
