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

[Michael Niedermayer]

Hi

On Tue, Dec 26, 2006 at 11:25:01AM -0500, Ronald S. Bultje wrote:
> Hi Michael,
> 
> 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

is_streamd == you cannot seek back unless its within the buffer


[...]
> > 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?

no, a URLProtocol cannot claim it can seek (is_streamed=0 after open) and
then when a demuxer tries to seek it fails and is_streamed is changed to 1
if you want to do this you would have to look at all demuxers and
1. figure out if they can fail fataly if is_streamed is wrongly set (true for
   avi at least but likey many more demuxers are affected)
2. ensure with a dummy seek that is_streamed is set correctly for the
   demuxers which depend on it

adding a filesize variable does not help here


> 
> 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
> it's known?
> 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
> of this.

s/AVInputFormat/ByteIOContext/ and yes i prefer a function pointer over a
duplicated filesize variable with one practically inaccessable from
URL*

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Good people do not need laws to tell them to act responsibly, while bad
people will find a way around the laws. -- Plato
-------------- 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/20061226/93ef37d7/attachment.pgp>