[Ffmpeg-devel] Re: [PATCH] file length handling
Ronald S. Bultje
Tue Dec 26 17:25:01 CET 2006
Sorry for the slow reply, needed a small xmas break.
On Sat, 2006-12-23, Michael Niedermayer wrote:
> On Fri, Dec 22, 2006 at 09:38:31AM -0500, Ronald S. Bultje wrote:
> > I don't know if there's any always-right way to detect whether the
> > server supports range requests. It's part of HTTP 1.1, but not required.
> > Servers could stream live content. I currently use the HTTP header to
> > see if the range request worked (Content-Range: bytes %from-%to/%total),
> > and if I seek asynchronously, I wouldn't be able to do this anymore. I
> > can of course seek during the first open() and see if it works, but
> > that's more of a hack than anything else.
> maybe but independant of the filesize thing, if is_streamed is set incorrectly
> then this could have quite negative effects, if is_streamed didnt matter then
> we could remove it ... one variable less ...
So what is the purpose of is_streamed? Some demuxers use it to see if we
can seek _at all_, whereas it seems more logical to use it as an
indication of whether a seek is going to be expensive or not. there's
some cases where this matters. Imagine, for example, binary seeks in ogg
streams, if you want to seek to an exact location. On files, this will
take some coding, but for the user experience, it'll be virtually
instant. However, over a network connection, regardless of whether you
have a pentium-166 or a quad xeon opteron gigeron 10-terahertz, it will
still be noticeably slow, depending of course on the expected exactness
of your binary seek. So depending on is_seek, you may want to adapt the
behaviour of the demuxer at least a bit, although the effect on the user
experience will be small.
I don't think is_stream is useless, it may just need some defining. Of
course, if you'd rather keep things simple (i.e. simple seek API, no
complex options, etc.) then is_streamed can indeed be removed.
> so besides being hackish, is there another disadvantage of a dummy seek?
> how much time does it cost on a slow network connection?
Basically, the reason for doing this is to not need file_size, right?
One problem I see (I mentioned this in my first email also, but just to
reiterate, sorry for repeating myself) is that not all HTTP servers can
seek, but the filesize is always known. How will I then know the
file_size? Should the seek succeed even though the protocol can not
seek? Or should we not let the demuxer know the filesize even though
Besides that, it's indeed just performance (for sync seeking) and/or
hackiness (async seeking).
In the end, to me it seems seeking and file_size can somehow relate to
each other, but they are definitely not the same, and the current API is
very much based on the idea of them being very closely related. I agree
we (I :-) ) should keep the file_size patch as small as possible, but I
think in all fairness, it'll be cleaner and easier to add file_size than
to continue to work around it.
As for implementation, I sent the variable-in-AVFormatContext thingy
because it was easier (quicker) to implement. If you're worried about
this (b/c filesize can change), I wouldn't mind making them function
pointers in AVInputFormat, but then again, the patch would grow because
More information about the ffmpeg-devel