On Fri, 27 Nov 2015, Nicolas George wrote:
Le sextidi 6 frimaire, an CCXXIV, Marton Balint a écrit :
Maybe I am missing something, but the existing error AVERROR(EINTR) cannot
be used for this?
It would be less broken than EAGAIN, since it is almost always treated like
that by Unix code.
But without the loop in utils.c (patch 2/3 in this series), the result is as
bad or worse than EAGAIN, since the application sees it as an error code.
And this is this loop that wm4 and Ronald are bikeshedding.
I agree that a loop is necessary if a demuxer can return an error with
such semantics to maintain compatibility.
But in principle, I am quite against reusing codes like that. The error
message for EINTR is "Interrupted function" or more frequently "Interrupted
system call", and nothing was interrupted, especially not a system call.
The only reaseon for considering this if we return AVERROR(errno) directly
from some syscalls to factorize code... probably not likely to happen, so
ok.
The
bug in the FLV demuxer at the origin of this threads was precisely caused
because EAGAIN was reused for a slightly different semantic.
(As a side note, it seems that EINTR is already abused in a completely
different way by the MPEG-TS demuxer; so much for the fabled review
process.)
Yes, it should be fixed...
On the other hand, I can see a point for making this error code MORE
specific, for example AVERROR_DATA_DISCARDED "Data was discarded".
Okay, there are two different kind of semantics here:
1) Packets were discarded becuase the user did not want them, or they were
empty packets (stuffing). This "error" does not indicate any problem with
the stream.
2) Data was discarded becuase it was garbage. (sync byte lost case)
This should simply be an AVERROR_INVALIDDATA? Or we should add a new error
code and pass it simply to the user?
Anyway, IMHO the important thing is to define/document that the error code
you introduce is only used for the first case.
Because EAGAIN is used for both at the moment I guess and neither of these
is EAGAIN...
Regards,
Marton
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
