[FFmpeg-devel] [PATCH] mpegts: Return AVERROR(EAGAIN) instead of -1 if there isn't enough data

Martin Storsjö martin
Wed Oct 13 21:43:55 CEST 2010


On Wed, 13 Oct 2010, Baptiste Coudurier wrote:

> On 10/13/2010 12:32 PM, Martin Storsj? wrote:
> > On Wed, 13 Oct 2010, Baptiste Coudurier wrote:
> > 
> > > On 10/13/2010 01:52 AM, Martin Storsjo wrote:
> > > > This makes the rtpdec queue code able to process packets more
> > > > efficiently,
> > > > keeping the queue shorter, by parsing the next packet instead of
> > > > returning
> > > > the unidentified error code -1 as an error.
> > > > ---
> > > >    libavformat/mpegts.c |    2 +-
> > > >    1 files changed, 1 insertions(+), 1 deletions(-)
> > > > 
> > > > diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
> > > > index d2f9f1e..13a9908 100644
> > > > --- a/libavformat/mpegts.c
> > > > +++ b/libavformat/mpegts.c
> > > > @@ -1742,7 +1742,7 @@ int ff_mpegts_parse_packet(MpegTSContext *ts,
> > > > AVPacket
> > > > *pkt,
> > > >            if (ts->stop_parse>0)
> > > >                break;
> > > >            if (len<   TS_PACKET_SIZE)
> > > > -            return -1;
> > > > +            return AVERROR(EAGAIN);
> > > >            if (buf[0] != 0x47) {
> > > >                buf++;
> > > >                len--;
> > > 
> > > Nope, if we couldn't read TS_PACKET_SIZE, it is an error, there is no need
> > > to
> > > retry.
> > 
> > Well then, could this piece of code return some other specific error code,
> > not just the generic -1, so that the caller knows that the actual error is
> > "not enough data provided"?
> 
> That's the only "error" (<0) reported by this function. I don't understand
> your problem.

The problem is that in the rtpdec code, Luca B wanted to distinguish 
between errors in parsing the packets that are other parsing errors 
(invalid data etc) that should be passed up to the caller immediately, and 
the particular error case that there's no more data to return from the 
packet given, so that we can go on directly to parsing the next queued 
packet.

That requires that the parser routines return some certain error code for 
this situation. As Reimar pointed out, EAGAIN might not be exactly the 
right code for this, and I'm open for suggestions on other error codes 
that would be more correct.

We can of course also hardcode that all errors from this particular 
function should be treated as "nothing more to return from the given 
data", since the mpegts parsing in rtp is a big special case anyway.

// Martin



More information about the ffmpeg-devel mailing list