774154 - HTML5 video duration changes after the video finishes

Status: NEW

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

Description

[Isaac]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_4) AppleWebKit/536.11 (KHTML, like Gecko) Chrome/20.0.1132.57 Safari/536.11

Steps to reproduce:

Played this video:  http://video.webmfiles.org/big-buck-bunny_trailer.webm

And then typed these two commands into Firebug console while the video was playing, and then again after it had gotten to the end of the timeline and stopped:

$$("video")[0].duration
$$("video")[0].buffered.end(0)


Actual results:

The duration returned for the video changes after the video has finished.

Firefox 13.0.1
While playing:
 $$("video")[0].duration = 32.48
 $$("video")[0].buffered.end(0) = 32.48

After it gets to the end of the video:
 $$("video")[0].duration = 32.512018
 $$("video")[0].buffered.end(0) = 32.48

Firefox Nightly 16.0a1 (2012-07-15)
While playing:
 $$("video")[0].duration = 32.48
 $$("video")[0].buffered.end(0) = 32.48

After it gets to the end of the video:
 $$("video")[0].duration = 32.501632
 $$("video")[0].buffered.end(0) = 32.48

Chrome 20.0.1132.57 (for reference)
While playing:
 $$("video")[0].duration = 32.47999954223633
 $$("video")[0].buffered.end(0) = 32.47999954223633

After it gets to the end of the video:
 $$("video")[0].duration = 32.47999954223633
 $$("video")[0].buffered.end(0) = 32.47999954223633


Expected results:

The duration should not have changed after the video finished, or if there was a good reason for it to have changed (we have a more accurate number after the video finishes), then the buffered.end(0) value should be updated as well.  Otherwise calculating what percentage of the video has been buffered is incorrect.

Comment 1

[Matthew Gregan [:kinetik]]

I can't reproduce this in a nightly build or Firefox 15 on Linux.  It'd be a strange bug to be OS X-only, but it's possible.  There are certainly bugs to fix here, anyway.

From mkvinfo:
| + Duration: 32.480s (00:00:32.480)

Last frame of each track (#1 video, #2 audio):
| + SimpleBlock (track number 1, 1 frame(s), timecode 32.440s = 00:00:32.440)
...
| + SimpleBlock (track number 2, 1 frame(s), timecode 32.478s = 00:00:32.478)

Frame duration is 40ms for entire video, so end of last video frame would be 32.48.

The decoded Vorbis has a duration of 32.491, but as muxed (with gaps), it's slightly longer.  The last audio block has a timestamp of 32.478 and a duration of 0.023219, resulting in an audio end time of 32.501219.  That's close to the time you're seeing in Firefox 16, and the differences may be attributable to rounding.

nsWebMReader::GetBuffered always uses the duration read directly from the WebM metadata, but it should try to use any computed duration if we have one.  That'd fix the buffered end range time.