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

[MSE] The infinite search if in the buffer there aren't enough frames.

RESOLVED FIXED in Firefox 51



Audio/Video: Playback
2 years ago
2 years ago


(Reporter: CoolCmd, Assigned: jya)


48 Branch
Windows 7

Firefox Tracking Flags

(firefox51 fixed)



MozReview Requests


Submitter Diff Changes Open Issues Last Updated
Error loading review requests:


(2 attachments)



2 years ago
Created attachment 8779795 [details]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:48.0) Gecko/20100101 Firefox/48.0
Build ID: 20160726073904

Steps to reproduce:

load testcase and open console

Actual results:

after second appendBuffer(), seek started ("seeking" event fired), but never ended ("seeked" event never fired).

as i understand, Firefox needs certain amount of buffered frames to complete seek. after second appendBuffer(), only 1 frame buffered 2 seconds long (first 59 frames not begin with key frame and thus ignored).

after third appendBuffer(), there enough frames to complete seek, but FF not do that. Chrome, for example, resumes and completes seeking.

unfortunately, JS do not know, how many frames contain buffer at any point. so playback just never start... this situation quite often happens during live streaming with variable frame rate (some frames are lost during sending video through network, etc).

Expected results:

Firefox must resume and complete seeking after third appendBuffer().


2 years ago
Component: Untriaged → Audio/Video: Playback
OS: Unspecified → Windows 7
Product: Firefox → Core
Hardware: Unspecified → x86_64


2 years ago
Assignee: nobody → jyavenard
Priority: -- → P3

Comment 1

2 years ago
Firefox doesn't need a certain amount of frames to complete seeking. Just one will do


2 years ago
Flags: needinfo?(jyavenard)

Comment 2

2 years ago
segment 0 is the init segment.
segment 1 contains:
1.m4v: 69 frames, none of them being marked as keyframe. 
followed by 6 frames, first one being a keyframe 844.911000 to 845.119455
As per spec: https://w3c.github.io/media-source/index.html#sourcebuffer-coded-frame-processing, at start need random access point flag is true, so all frames prior a keyframes are dropped.
So the video track buffered range is [844.911000, 845.119455)
1.m4a: 118 audio frames, from 842.024666 to 844.542000, so the audio buffered range is [842.024666,844.542000)

The buffered range is the intersection of the audio and video track is [(844.911, 845.119455)]
The script then seek to 844.911.

Last week, I would have closed this bug as Invalid, as per spec then:
"The media element looks for media segments containing the new playback position in each SourceBuffer object in activeSourceBuffers.
If one or more of the objects in activeSourceBuffers is missing media segments for the new playback position
        If the HTMLMediaElement.readyState attribute is greater than HAVE_METADATA, then set the HTMLMediaElement.readyState attribute to HAVE_METADATA."

there isn't anything to seek to in the audio track. so seeking can't complete.

However, since https://github.com/w3c/media-source/issues/147 got closed last week (bug that we opened against the spec), we now have clarifications that seeking must complete if the target is in the buffered range.
Last Resolved: 2 years ago
Flags: needinfo?(jyavenard)
Resolution: --- → DUPLICATE
Duplicate of bug: 1297036

Comment 3

2 years ago
Jean-Yves Avenard, no, this bug is NOT duplicate of 1297036:
1. testcase 1294154 contain ONLY video.
2. buffer HAVE video data to complete seek.
3. endOfStream() was NEVER called.

Please check testcase again.

>Firefox doesn't need a certain amount of frames to complete seeking. Just one will do
OK, forget about 'amount of frames'. Just check why seek cannot complete.


2 years ago
Flags: needinfo?(jyavenard)

Comment 4

2 years ago
If you followed the bug that has been linked to. Or try with a current Firefox Nightly you would have seen that the issue has been corrected. 

All the explanation on why has been provided in comment 2. There's nothing more to add
Flags: needinfo?(jyavenard)

Comment 5

2 years ago
And btw; your samples contain audio. It is NOT video only

Comment 6

2 years ago
Jean-Yves Avenard, i install Firefox Nightly 51.0a1 20160830030201.
Bug 1297036 fixed, but this bug 1294154 NOT.
Testcase 1294154 have different JavaScript file and different segments. Those segments don't have audio and have different frame timestamps.

Comment 7

2 years ago
My apologies, you named all your zip files the same across various bugs, as a result i used the wrong file..

works for me on linux. will test on windows later...

Comment 8

2 years ago
not working on windows only.. fine on mac and linux
Ever confirmed: true
Resolution: DUPLICATE → ---

Comment 9

2 years ago
The issue is that WMF returns an invalid frame when all the decoder was given is a single frame.
The sample returns always have a pts of 0 and a duration of 1/30.

The coming up patch, detect store the time and duration of the last sample and when draining detects if only one frame was given.

I'm not sure if there's a better way, but this will do for now
Comment hidden (mozreview-request)
Comment hidden (mozreview-request)

Comment 12

2 years ago
Comment on attachment 8787593 [details]
Bug 1294154: Handle case where WMF is unable to determine time and duration.


This ia pretty sad, but I guess it should work fine.
Attachment #8787593 - Flags: review?(matt.woodrow) → review+

Comment 13

2 years ago
Pushed by jyavenard@mozilla.com:
Handle case where WMF is unable to determine time and duration. r=mattwoodrow

Comment 14

2 years ago
Last Resolved: 2 years ago2 years ago
status-firefox51: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla51
You need to log in before you can comment on or make changes to this bug.