[FFmpeg-devel] [PATCH] tty: return av_get_packet() error codes instead of converting them to EIO

[Reimar Döffinger]

On Wed, Sep 05, 2012 at 12:05:48AM +1000, Peter Ross wrote:
> On Tue, Sep 04, 2012 at 07:25:15AM +0200, Reimar Döffinger wrote:
> > On 4 Sep 2012, at 01:44, Peter Ross <pross at xvid.org> wrote:
> > > ---
> > > Updated.
> > > 
> > > libavformat/tty.c |    4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/libavformat/tty.c b/libavformat/tty.c
> > > index a71c6b1..39380e2 100644
> > > --- a/libavformat/tty.c
> > > +++ b/libavformat/tty.c
> > > @@ -135,8 +135,8 @@ static int read_packet(AVFormatContext *avctx, AVPacket *pkt)
> > >     }
> > > 
> > >     pkt->size = av_get_packet(avctx->pb, pkt, n);
> > > -    if (pkt->size <= 0)
> > > -        return AVERROR(EIO);
> > > +    if (pkt->size < 0)
> > > +        return pkt->size;
> > 
> > Is that change in behaviour (0 sized packets no longer considered an error) intended/correct?
> > Particularly since I guess that case can happen both due to n being 0 or due the the file being cut at exactly the start of a packet.
> > (not that it is likely to matter much in practice, but making code less correct to save a single ?: seems like a bad trade-off to me).
> 
> The number of requested bytes ('n') is always > 0, and av_get_packet() is a blocking call, 
> so the '== 0' case should never happen. Correct me if iam wrong here!

It would happen if the file ends precisely at the start of the packet.
And it will end up returning a packet that has been freed (though that
is not as bad as it sounds, and possibly not an issue at all).

> Grepping all the uses of av_get_packet shows several different ways its being used. e.g.
> Return error code <0, return error code <=0, return EIO always, etc. I am not sure which
> is most appropriate.

< 0 should be returned unchanged.
I am undecided whether a 0 return value should return a 0-size packet
with AV_PKT_FLAG_CORRUPT, return some AVERROR and/or whether
av_get_packet should be changed to handle that case differently.