bugzilla.mozilla.org will be intermittently unavailable on Saturday, March 24th, from 16:00 until 20:00 UTC.

Use BlockDuration (when available) rather than estimating frame duration




Audio/Video: Playback
2 years ago
2 years ago


(Reporter: kinetik, Assigned: kinetik)



Firefox Tracking Flags

(firefox47 affected)




2 years ago
Right now, WebMDemuxer calculates the duration of a frame by subtracting the frame's start time from the next frame's start time.

Whenever the next frame is not available (at the end of the file or buffer for MSE), we fall back to using the duration we calculated for the previous frame.  Being a guess, this can be incorrect.

Existing code here:  https://dxr.mozilla.org/mozilla-central/source/dom/media/webm/WebMDemuxer.cpp#504

WebM has two additional ways to signal the duration of frames which we should use in preference to estimating.  These are BlockDuration (nestegg_packet_duration) and DefaultDuration (nestegg_track_default_duration), both of which are optional.

The frame duration logic should be (according to the WebM spec):
1. Use BlockDuration if present.
2. Use DefaultDuration if present.
3. Use (next_frame - current_frame) to calculate duration.

It's not clear from the spec how to handle cases that aren't addressed by the above, so I propose:

4. Use previous frame's duration as an estimate.
  1. If the media has a duration present, clamp the final frame's duration to the media's duration.

Comment 1

2 years ago
Note that using nestegg_packet_duration relies on the following upstream fix: https://github.com/kinetiknz/nestegg/commit/6439d944761e5526e1dd637cf2cc56c110c13db8


2 years ago
Assignee: nobody → bvandyk
Priority: -- → P2
This may impact external media tests also: http://pf-jenkins.qa.mtv2.mozilla.com:8080/job/mn-mse-youtube-basic-y-aurora-win7_32_64/904/artifact/logs/media_tests.html

In the above case it looks like the duration of the video has changed from the expected value due to re-evaluation of the duration. I don't think this caused the fail in the test, but wanted to make sure the issue is referenced for the future.

Comment 3

2 years ago
Bug 1261900 is going to introduce these changes as part of a larger patchset, so we can probably dupe this to that.
Mass change P2 -> P3
Priority: P2 → P3

Comment 5

2 years ago
Done in bug 1261900
Assignee: bvandyk → kinetik
Last Resolved: 2 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.