Closed Bug 1187247 Opened 7 years ago Closed 7 years ago

Enable WebM with new MSE

Categories

(Core :: Audio/Video, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla42
Tracking Status
firefox42 --- fixed

People

(Reporter: j, Assigned: j)

References

Details

Attachments

(2 files, 1 obsolete file)

No description provided.
carry review from bug 1184867
Attachment #8638423 - Flags: review+
Assignee: nobody → j
Blocks: 1183977
https://hg.mozilla.org/mozilla-central/rev/b9cc2c3f8bda
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla42
This needs to be backed out, if bug 1184867 isn't in.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Jan, this video https://www.youtube.com/watch?v=XqLTe8h0-jo stalls at 6s when webm is enabled

Very weird, as I tested it only a few days ago and it was all fine 
The first appendBuffer contains 301 opus frames, ending in 6.021 and after than nothing more until it loads (20.001000, 30.001000)

So I don't know if it's a bug with youtube not serving the content but seeing that Chrome doesn't have that stall...
Got a stall here:
https://www.youtube.com/watch?v=jEnd8JIMii4

HTMLMediaElement debug data

https://www.youtube.com/watch?v=jEnd8JIMii4
	mediasource:https://www.youtube.com/68445642-b9eb-2a49-957d-1aecf7665cb9
	currentTime: 920.6712
		SourceBuffer 0
			start=0 end=920.717596
		SourceBuffer 1
			start=355.356 end=915.982
			start=920.92 end=925.992
			start=930.93 end=930.997
			start=935.935 end=936.002
			start=940.94 end=941.007
			start=945.945 end=946.012
			start=950.95 end=956.022
			start=960.96 end=961.027
			start=965.965 end=966.032
			start=970.97 end=971.037
			start=975.975 end=976.042
			start=980.98 end=981.047
			start=985.985 end=986.052
			start=990.99 end=996.062
			start=1001 end=1001.067
			start=1006.005 end=1006.072
			start=1011.01 end=1011.077
			start=1016.015 end=1016.082
			start=1021.02 end=1021.087
			start=1026.025 end=1026.092
			start=1031.03 end=1036.102
			start=1041.04 end=1041.107
			start=1046.045 end=1046.112
			start=1051.05 end=1051.117
			start=1056.055 end=1066.066
	Internal Data:
	Dumping data for demuxer 1466bc000:
		Dumping Audio Track Buffer(audio/mp4a-latm): - mLastAudioTime: 920.717596
			NumSamples:39652 Size:21432904 NextGetSampleIndex:39652 NextInsertionIndex:39652
			Buffered: ranges=[(0.000000, 920.717596)]
		Dumping Video Track Buffer(video/webm; codecs=vp9) - mLastVideoTime: 359.559000
			NumSamples:17748 Size:100425469 NextGetSampleIndex:126 NextInsertionIndex:17748
			Buffered: ranges=[(355.356000, 915.982000), (920.920000, 925.992000), (930.930000, 930.997000), (935.935000, 936.002000), (940.940000, 941.007000), (945.945000, 946.012000), (950.950000, 956.022000), (960.960000, 961.027000), (965.965000, 966.032000), (970.970000, 971.037000), (975.975000, 976.042000), (980.980000, 981.047000), (985.985000, 986.052000), (990.990000, 996.062000), (1001.000000, 1001.067000), (1006.005000, 1006.072000), (1011.010000, 1011.077000), (1016.015000, 1016.082000), (1021.020000, 1021.087000), (1026.025000, 1026.092000), (1031.030000, 1036.102000), (1041.040000, 1041.107000), (1046.045000, 1046.112000), (1051.050000, 1051.117000), (1056.055000, 1066.066000)]
(In reply to Jean-Yves Avenard [:jya] from comment #6)
> Jan, this video https://www.youtube.com/watch?v=XqLTe8h0-jo stalls at 6s
> when webm is enabled

Looking at the data coming from Youtube, this happens since the chunks appended
do not contain a full cluster and MediaSegmentRange is set to all parsed
SimpleBlocks available.
Also checking for SimpleBlocks in IsMediaSegmentPresent demuxing can continue as more data is appended.
Flags: needinfo?(j)
Attachment #8641610 - Flags: review?(kinetik)
I've noticed that with MP4 now, like when seeking, they only send a partial media segment of about 1s ; probably so that the seek completes quickly and you can get immediately an image.

maybe they recently changed how they are appending content.
Comment on attachment 8641610 [details] [diff] [review]
Bug-1187247-MediaSegment-can-also-start-at-SimpleBlock.patch

Review of attachment 8641610 [details] [diff] [review]:
-----------------------------------------------------------------

This should probably accept a regular Block too.

And please change the commit message; it's not correct that a media segment can start at a SimpleBlock per the spec.  What's really happening (not that the current parser enforces this) is that we should be inside a media segment in the parsing loop and the appendBuffer is adding new frames.
Attachment #8641610 - Flags: review?(kinetik) → review+
(In reply to Matthew Gregan [:kinetik] from comment #10)
> This should probably accept a regular Block too.
ok also adding Block.

> And please change the commit message; it's not correct that a media segment
> can start at a SimpleBlock per the spec.  What's really happening (not that
> the current parser enforces this) is that we should be inside a media
> segment in the parsing loop and the appendBuffer is adding new frames.

updated commit message
Attachment #8641610 - Attachment is obsolete: true
Attachment #8641624 - Flags: review+
https://hg.mozilla.org/mozilla-central/rev/37ce03221f95
https://hg.mozilla.org/mozilla-central/rev/15ef1802114f
Status: REOPENED → RESOLVED
Closed: 7 years ago7 years ago
Resolution: --- → FIXED
Depends on: 1192517
You need to log in before you can comment on or make changes to this bug.