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

[Ronald S. Bultje]

Hi Michael,

On Thu, 2006-12-21, Michael Niedermayer wrote:
> 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

Yes, that's true (for each of them), so that can indeed safely be
removed.

> 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

Right, this is indeed a problem. In ByteIOContext, you may be able to
get around it by (instead of the file_size value) providing an
additional get_length() function pointer, which is only implemented by
URLContext and calls url_filesize().

Of course, that would increase the patchsize. :-).

> 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 ...

I don't mind doing this, I'm just not a huge fan of this asynchronous
programming... I kind of consider this hacky. Let me know if the above
change to ByteIOContext would be OK also, if not I'll do what you
suggested here.

Thanks,
Ronald