[FFmpeg-devel] dv_read_seek over 2GB fix

Roman Shaposhnick rvs
Wed Jun 20 04:01:51 CEST 2007


On Wed, 2007-06-20 at 02:48 +0200, Michael Niedermayer wrote:
> Hi
> 
> On Tue, Jun 19, 2007 at 02:02:35PM -0700, Roman Shaposhnik wrote:
> > On Tue, 2007-06-19 at 15:08 +0300, Maksym Veremeyenko wrote:
> > > >> looks ok (minus the trailing whitespace) but iam not dv maintainer,
> > > >> roman is that ...
> > > Trailing spaces removed. cleaned patch version attached.
> > > 
> > > >   Isn't the bigger issue here that AVInputFormat::read_seek() has a
> > > > return type that doesn't make much sense with the lfcompile(5) ?
> 
> No manual entry for lfcompile

  Well, there's one on the OS I use ;-) 
     http://bama.ua.edu/cgi-bin/man-cgi?lfcompile+5

> and changing the return value would need a major version bump

  True. And I'm not even arguing that we need it.

> > > problem is in "truncating" returned value...
> > > 
> > > Is this patch OK? Could you commit this one?
> > 
> >   I still have the same question (I guess Michael should be the one
> > to really answer it): what is the semantics of the
> > AVInputFormat::read_seek() return value (and perhaps we should even
> > include the description of the semantics into the avformat.h).
> 
> <0 is error, ideally a proper error code
> >=0 is no error
> 
> the meaning of the individual >=0 is unspecified currently, that might
> change though
> 
> what does matter is that if no error happens then the return should be
> >= 0

  In that case the patch seems to be ok. I would *really* love to see
you, Michael, commit the one or two lines about the current semantics 
of AVInputFormat::read_seek to the avformat.h. Unless, of course, I'm
the only one who expects the function named *seek to return new
offset on success.

Thanks,
Roman.





More information about the ffmpeg-devel mailing list