Anton Khirnov (12022-11-09):
> I have no idea what you mean by this. What is being broken and how?
EAGAIN and REDO are different. If you make them the same, you break one
of them. Or possibly both if you are being really stupid, but at least
one.
> Maybe more context will clarify the motivation
Quoting Nicolas George (2022-11-09 11:41:32)
> Anton Khirnov (12022-11-09):
> > If your concern with busy-waiting is pointless energy consumption, then
> > the correct thing to do is change all busy-waiting devices to sleep
> > internally if AVFMT_FLAG_NONBLOCK is not specified. I just checked,
Anton Khirnov (12022-11-09):
> If your concern with busy-waiting is pointless energy consumption, then
> the correct thing to do is change all busy-waiting devices to sleep
> internally if AVFMT_FLAG_NONBLOCK is not specified. I just checked, and
> almost all of them actually do exactly this, the
Quoting Nicolas George (2022-11-09 10:38:06)
> Anton Khirnov (12022-11-09):
> > > Well, it has actionable consequences: if you treat EAGAIN like REDO you
> > > introduce a busy wait,
> > In most devices it's a sleep rather than a busy wait. And in those where
> > it isn't, it should be.
>
> I do
Anton Khirnov (12022-11-09):
> > Well, it has actionable consequences: if you treat EAGAIN like REDO you
> > introduce a busy wait,
> In most devices it's a sleep rather than a busy wait. And in those where
> it isn't, it should be.
I do not know how your sentence connects to mine.
>
Quoting Nicolas George (2022-11-09 09:21:34)
> Anton Khirnov (12022-11-08):
> > Sure, and that's about it. And as I said before - there is no way to
> > tell when a device will be ready, so this is of very limited usefulness.
>
> This is not true for many devices. Sorry to contradict you once
Paul B Mahol (12022-11-09):
> The bug is found by Jan IIRC, and fixed by not using EAGAIN return
> values in demuxer IIRC.
Then I do not know what bug you are referring to. Maybe try honing your
communication skills.
--
Nicolas George
___
On 11/9/22, Nicolas George wrote:
> Paul B Mahol (12022-11-09):
>> I'm not interested in REDO / EAGAIN differences.
>
> They delete this thread.
>
>> Can this bug be fixed at all?
>
> This bug has been fixed for seven years. I would rather we do not unfix
> it.
The bug is found by Jan IIRC, and
Paul B Mahol (12022-11-09):
> I'm not interested in REDO / EAGAIN differences.
They delete this thread.
> Can this bug be fixed at all?
This bug has been fixed for seven years. I would rather we do not unfix
it.
--
Nicolas George
___
ffmpeg-devel
On 11/9/22, Nicolas George wrote:
> Anton Khirnov (12022-11-08):
>> Sure, and that's about it. And as I said before - there is no way to
>> tell when a device will be ready, so this is of very limited usefulness.
>
> This is not true for many devices. Sorry to contradict you once again,
> but you
Anton Khirnov (12022-11-08):
> Sure, and that's about it. And as I said before - there is no way to
> tell when a device will be ready, so this is of very limited usefulness.
This is not true for many devices. Sorry to contradict you once again,
but you would know it if you had any experience
Quoting Nicolas George (2022-11-08 15:15:39)
> Anton Khirnov (12022-11-08):
> > This is false - there are zero demuxers returning EAGAIN due to network
> > blocking.
>
> There are devices who return EAGAIN due to device blocking.
Sure, and that's about it. And as I said before - there is no way
Anton Khirnov (12022-11-08):
> This is false - there are zero demuxers returning EAGAIN due to network
> blocking.
There are devices who return EAGAIN due to device blocking.
> So there really is no meaningful difference between REDO and EAGAIN.
There is a difference: REDO is internal, EAGAIN
Quoting Nicolas George (2022-11-08 13:54:53)
> Anton Khirnov (12022-11-08):
> > There is no meaningful distinction between them, both mean "the demuxer
> > did some work, but did not produce a packet - should be called again".
>
> NAK, there a difference in semantics: AVEROR(EAGAIN) is for when
Anton Khirnov (12022-11-08):
> There is no meaningful distinction between them, both mean "the demuxer
> did some work, but did not produce a packet - should be called again".
NAK, there a difference in semantics: AVEROR(EAGAIN) is for when data is
not available for external reasons, typically
There is no meaningful distinction between them, both mean "the demuxer
did some work, but did not produce a packet - should be called again".
---
libavformat/demux.c | 12
libavformat/demux.h | 6 --
libavformat/flvdec.c | 14 +++---
libavformat/lxfdec.c | 2 +-
16 matches
Mail list logo
