575140 - Optimize WebM seeking in already downloaded byte ranges

Status: NEW

(Core :: Audio/Video: Playback, defect, P3)

Description

[Matthew Gregan [:kinetik]]

At the moment, we require the WebM index to seek.  This means that seeking into an already downloaded byte range may require a new HTTP connection to fetch the index (if it's at the end of the file, as is very common).  This slows down seeking into cached ranges much more than the user might expect.

We've already got most of the information necessary to seek to the correct place in a cached range, and we can find the rest of the information using a scan/skip forward based on the cluster sizes.

Doing this would allow a simple optimization of this use case without having to implement the complete machinery required for bisection search seeking.  Having this optimization would also lay the foundations for implementing a bisection search later if it becomes necessary.

Comment 1

[Matthew Gregan [:kinetik]]

Investigation of bug 696519 revealed that Chrome can seek in already downloaded regions without Cues present.  Given that, and the fact that Youtube is continuing to serve WebM with the Cues located at the end of the file (despite what the WebM container spec recommends), this bug becomes more than a "nice to have", since our seeking on Youtube will see much slower than Chrome's.

Comment 2

[cajbir (:cajbir)]

Bug 1000608 implements this optimization.

Comment 3

[cajbir (:cajbir)]

Is the landing of bug 1000608 enough to consider this fixed?

Comment 4

[Matthew Gregan [:kinetik]]

I think so.  The only thing left would be to prefetch the index (if it's located at the end of the steam) to speed up seeking into non-buffered ranges, but that's fairly minor.  Shall we morph this bug to cover that case?

Comment 5

[cajbir (:cajbir)]

(In reply to Matthew Gregan [:kinetik] from comment #4)
> Shall we morph this bug to cover that case?

Sure, sounds good to me.

Comment 6

[adifran]

Hi there. Is this fixed or not? From the discussion above it seems so...almost..:) 
As this is also stated as blocking bug 	657791 it would be great to know.
Thanks.