On Sun, 31 Aug 2014 10:24:13 +0200
Reimar Döffinger <reimar.doeffin...@gmx.de> wrote:

> On Sun, Aug 31, 2014 at 10:15:56AM +0200, Hendrik Leppkes wrote:
> > On Sun, Aug 31, 2014 at 9:41 AM, Reimar Döffinger
> > <reimar.doeffin...@gmx.de> wrote:
> > > On 30.08.2014, at 15:38, wm4 <nfx...@googlemail.com> wrote:
> > >> +    // The packet-size is stored as part of the packet.
> > >> +    if ((ret = avio_read(s->pb, tmp, 3)) < 0)
> > >> +        return ret;
> > >> +
> > >> +    len = AV_RB16(tmp + 1);
> > >> +
> > >> +    if ((ret = av_new_packet(pkt, len + 3)) < 0)
> > >> +        return ret;
> > >> +
> > >> +    memcpy(pkt->data, tmp, 3);
> > >> +
> > >> +    if ((ret = avio_read(s->pb, pkt->data + 3, len)) < 0) {
> > >> +        av_free_packet(pkt);
> > >> +        return ret;
> > >> +    }
> > >
> > > I think this will not handle short reads correctly, retuning 
> > > uninitialised data.
> > > My suggestion would be to read the length, then seek back (buffering 
> > > should ensure this is no issue even if we read from stdin) and then use 
> > > the functions to read the full packet with all the proper error handling.
> > 
> > 
> > I don't see a problem in the code he proposed. It seems to handle
> > every read with an error check, without relying on potential buffering
> > of data to allow a seek backwards.
> > This is assuming avio_read does return an error if it runs against
> > EOF, which I assume it does? I didn't double check that.
> 
> Why would it? That would make it a huge pain to read formats where
> you don't know ahead of time how long they are (e.g. streaming
> TS files via stdin).
> 
> > What exactly do you think is wrong here?
> 
> The code does not handle 0 < ret < len (I think 0 should not be
> possible), plus it is complex and I am not at all confident it's
> the only case it misses.
> There is a reason we have helper functions.
> If you absolutely do not want to seek back, there is also the
> option of reading a 3-byte packet (but then like now you have
> to add handling getting fewer than that) and then use the function
> to expand the packet to read the rest.
> However there is a good reason why seeking back small amounts is
> _supposed_ to work always, 100% reliable, and it should be fine
> to take advantage of it.

When I looked at avio_read, it seemed like it doesn't allow short
reads, so I simplified the error checks.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Reply via email to