[FFmpeg-devel] [RFC] using ByteIOContext with buffer without reading function

[Baptiste Coudurier]

On Mon, Apr 13, 2009 at 02:47:48AM +0200, Michael Niedermayer wrote:
> On Sat, Apr 11, 2009 at 03:52:44PM -0700, Baptiste Coudurier wrote:
> > Hi Michael,
> > 
> > On Fri, Mar 20, 2009 at 04:36:04AM +0100, Michael Niedermayer wrote:
> > > On Sun, Mar 15, 2009 at 03:53:07PM -0700, Baptiste Coudurier wrote:
> > > > Hi,
> > > > 
> > > > I notice something strange when using ByteIOContext with a supplied
> > > > buffer without read function, reading only.
> > > > 
> > > > aviobuf.c
> > > > init:
> > > >     if(!read_packet && !write_flag){
> > > >         s->pos = buffer_size;
> > > >         s->buf_end = s->buffer + buffer_size;
> > > >     }
> > > > 
> > > > seek:
> > > >     if (!s->must_flush &&
> > > >         offset1 >= 0 && offset1 < (s->buf_end - s->buffer)) {
> > > >         /* can do the seek inside the buffer */
> > > >         s->buf_ptr = s->buffer + offset1;
> > > > 
> > > > mov.c:
> > > >     if(init_put_byte(&ctx, moov_data, moov_len, 0, NULL, NULL, NULL,
> > > > NULL) != 0)
> > > >         goto free_and_return;
> > > > 
> > > > Problem is:
> > > > when you use url_fskip on the ByteIOContext, for example to skip
> > > > everything not read (size is 51, url_fskip(51)), you will end up seeking
> > > > at s->buf_end.
> > > > 
> > > > However the condition in "seek" won't allow this since offset1 ==
> > > > s->buf_end - s->buffer.
> > > > 
> > > > Would it be better to change init to set buf_end to s->buffer +
> > > > buffer_size + 1 or check for <= in seek ?
> > > 
> > > i would guess to <= in seek but this should be carefully tested, iam
> > > not sure if this might have some unexpeted sideeffects
> > > 
> >  
> > Any confidence in the <= case ?
> > 
> > I've checked the buf_end tests in aviobuf.c and they seem ok.
> > 
> > It would be nice to move on on the multiple stsd feature. This should be a
> > good step in exporting the struct to decoders needing it.
> 
> if you belive its ok, commit
> 

I think it's ok, applied.

-- 
Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA    
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
checking for life_signs in -lkenny... no
FFmpeg maintainer                                  http://www.ffmpeg.org