[Ffmpeg-devel] Re: Re: [PATCH] file length handling

[Michael Niedermayer]

Hi

On Wed, Dec 20, 2006 at 08:43:23AM -0500, Ronald S. Bultje wrote:
> Hi Michael,
> 
> On Tue, 2006-12-19, Michael Niedermayer wrote:
> > On Mon, Dec 18, 2006 at 09:11:55PM -0500, Ronald S. Bultje wrote:
> > > On Mon, 2006-12-18, Michael Niedermayer wrote:
> > > > On Mon, Dec 18, 2006 at 08:55:43PM +0100, Ronald S. Bultje wrote:
> > > > > On Mon, 18 Dec 2006, Michael Niedermayer wrote:
> > > > > > On Mon, Dec 18, 2006 at 09:20:49AM -0500, Ronald S. Bultje wrote:
> > > > > > > -#define LIBAVFORMAT_VERSION_INT ((51<<16)+(6<<8)+0)
> > > > > > > -#define LIBAVFORMAT_VERSION     51.6.0
> > > > > > > +#define LIBAVFORMAT_VERSION_INT ((52<<16)+(0<<8)+0)
> > > > > > > +#define LIBAVFORMAT_VERSION     52.0.0
> > > > > > >  #define LIBAVFORMAT_BUILD       LIBAVFORMAT_VERSION_INT
> > > [..]
> > > > external or not how does adding a field to the end break anyting?
> > > > no external code should depend on any struct size if it does its
> > > > broken IMHO
> > > 
> > > I don't add it to the end. URLContext has a char filename[1] at the end,
> > > which is used for dynamic sizing of the struct.
> > 
> > you are right :(
> > i (and i belive many of our users too) would prefer if compatibility wouldnt
> > be broken, its broken often enough anyway
> > 
> > so either we put the addition of filesize under 
> > #if LIBAVFORMAT_VERSION_INT > ...
> 
> This sounds relatively easy to me, so let's do this. I've attached new
> patches for both file length handling and http seeking that use this.
> I'll send in a cleanup to remove the #ifs after the AVFrac patch is in.

somehow i dont like the filesize patch, its 6 pages of changes for something
which IMHO can be done in <10 lines

first many protocols set filesize to -1 as they have no filesize but this
can be done more generically, a simple

pos= url_seek()
if(pos < 0)
    return -1;
should do as all? of these filesize less protocols are also non-seekable

and still i dont like that the filesize variable is duplicated between
ByteIOContext and URLContext its bad design IMHO, a function of
URLProtocol has no access to ByteIOContext so cannot update it, and filesize
is not a fundamentally constant thing, its rather that it cannot change in
http so the duplication doesnt cause problems but for protocols where it
could change and where finding it through seek() would be expensive it
might get tricky with the duplicated filesize variable

i think the simplest solution would be to handle seeking in http like

seek(){
    find new position
    c->req_off= position
    return positon
}

read(){
    if(c->req_off != c->off){
        perform actual seek
        c->off= c->req_off;
    }
    ...
}

this would also not break compatibility though that is only a minor
advantage due to AVFrac ...

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I do not agree with what you have to say, but I'll defend to the death your
right to say it. -- Voltaire
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20061221/8c047034/attachment.pgp>