[FFmpeg-devel] [PATCH] ffprobe: do not exit in case the demuxer returns AVERROR(EAGAIN)
Michael Niedermayer
michaelni at gmx.at
Thu Nov 19 03:02:34 CET 2015
On Thu, Nov 19, 2015 at 02:36:19AM +0100, Michael Niedermayer wrote:
> On Thu, Nov 19, 2015 at 01:25:53AM +0100, Andreas Cadhalpun wrote:
> > On 18.11.2015 15:07, Michael Niedermayer wrote:
> > > On Tue, Nov 17, 2015 at 05:20:08PM +0100, Stefano Sabatini wrote:
> > >> On date Tuesday 2015-11-17 17:12:46 +0100, wm4 encoded:
> > >>> On Tue, 17 Nov 2015 17:00:29 +0100
> > >>> Stefano Sabatini <stefasab at gmail.com> wrote:
> > >> [...]
> > >>>> No, just in case ret == AVERROR(EAGAIN), in all other failure cases it
> > >>>> will exit the loop immediately.
> > >>>>
> > >>>> BTW, the same problem affects some API usage examples.
> > >>>
> > >>> Yeah, I got that wrong - but even with EAGAIN, is there a guarantee?
> > >>
> > >> I don't know. Note that this is also the same strategy applied by
> > >> ffplay and ffmpeg (in this case it will wait with a usleep). We could
> > >> abort in case a threshold count value is reached, but that would be
> > >> probably overkill.
> > >
> > > iam not aware of any inf loops with EAGAIN
> >
> > Well, I am. I even sent patches fixing that, but you had objections. [1]
>
> FFM is used as a ring buffer between processes
> if you try to read a ffm file that is not connected to any process
> writing into it then that could wait via EAGAIN forever
> that is a problem
>
> A fix would require to extend the ffm format slightly i think
> a simple fix would be for the muxer to write teh current date in the
> file and the demuxer to skip EAGAIN and fail if the read data differs
> by more than a small amout from the current date or something similar
>
> if you dont want to work on this, please say so, then ill look into
> it
> other ideas are of course welcome
another even simpler idea would be to add a user option to switch the
ring buffer behavior off/on that would solve the EAGAIN issue
for randomly fed files into random applications too
it would not help in the ring buffer case when the producer crashes
or fails for other reasons
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Many things microsoft did are stupid, but not doing something just because
microsoft did it is even more stupid. If everything ms did were stupid they
would be bankrupt already.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20151119/dff8ca5e/attachment.sig>
More information about the ffmpeg-devel
mailing list