519069 - Step backwards exponentially in oggz_get_prev_start_page

Status: RESOLVED FIXED

(Core :: Audio/Video, defect)

Description

[Matthew Gregan [:kinetik]]

Greg Maxwell reports that the file in the bug URL takes 31 HTTP seek requests before it can start playing.  He suggested that this may be caused by the seek algorithm having trouble locating the last granulepos due to the high bitrate.

Comment 1

[Chris Pearce [:cpearce (Not reading bugmail)]]

The theora stream has very big packets - the average difference between the start of any two consecutive video packets' first page is almost 91KB. For the record this file is poorly muxed as well, the average distance between vorbis pages is about 1.3MB. Unsurprisingly we don't even play the file smoothly when loading from disk (let alone over a network!).

Regardless the problem here is caused by the granulepos of the pages at the end of the file. The theora pages at the EOF are laid out like so:

...
[T] page @38259865 length=4314 granulepos=28296 time=15000ms
[T] page @38264179 length=4379 granulepos=-1
[T] page @38268558 length=4379 granulepos=-1
[T] page @38272937 length=4379 granulepos=-1
[T] page @38277316 length=4379 granulepos=-1
[T] page @38281695 length=4379 granulepos=-1
[T] page @38286074 length=4379 granulepos=-1
[T] page @38290453 length=4379 granulepos=-1
[T] page @38294832 length=4379 granulepos=-1
[T] page @38299211 length=4379 granulepos=-1
[T] page @38303590 length=4379 granulepos=-1
[T] page @38307969 length=4379 granulepos=-1
[T] page @38312348 length=4379 granulepos=-1
[T] page @38316727 length=4379 granulepos=-1
[T] page @38321106 length=4379 granulepos=-1
[T] page @38325485 length=4379 granulepos=-1
[T] page @38329864 length=4379 granulepos=-1
[T] page @38334243 length=4379 granulepos=-1
[T] page @38338622 length=4379 granulepos=-1
[T] page @38343001 length=4379 granulepos=-1
[T] page @38347380 length=4379 granulepos=-1
[T] page @38351759 length=4379 granulepos=-1
[T] page @38356138 length=4379 granulepos=-1
[T] page @38360517 length=4379 granulepos=-1
[T] page @38364896 length=4379 granulepos=-1
[T] page @38369275 length=4379 granulepos=-1
[T] page @38373654 length=4379 granulepos=-1
[EOF]

In order to calculate the duration, oggz seeks to the end, and then reads backwards to find the preceding page until it finds a page with a non -1 granulepos from which it can determine the stream time. In this case, that's 26 pages from the end. When doing this over the web, each non-sequential read requires a new HTTP request, hence the high number of HTTP requests.

This is an encoding failure - the video requires too many pages per packet, it's too poorly compressed, for us to perform well when playing this over the web. You could serve an X-Content-Duration header, which will prevent the seeks-before-playback, but as long as the video packets are about 90KB long, this is never going to playback smoothly anyway, especially when served over the internet.

The video is an interesting testcase for performance analysis, but we can't realistically prevent the large number of seeks required to get the duration on our side. For improved performance in this case, the encoder needs to compress the video frames more. You could also serve X-Content-Duration, or index the Ogg file! :)

WONTFIX.

Comment 2

[Chris Pearce [:cpearce (Not reading bugmail)]]

A better approach would be to rely on our media cache to cache bits we've already downloaded, and to change oggz_get_prev_start_page() to step backwards exponentially rather than in page-sized amounts. We'd then reduce the number of HTTP requests required, and handle poorly encoded files more gracefully.

Comment 3

[Chris Pearce [:cpearce (Not reading bugmail)]]

The new ogg decoder backend now steps back exponentially, so this is effectively fixed on trunk.