[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