Closed Bug 1187247 Opened 9 years ago Closed 9 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
Status: NEW → RESOLVED
Closed: 9 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+
Status: REOPENED → RESOLVED
Closed: 9 years ago9 years ago
Resolution: --- → FIXED
Depends on: 1192517
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: