User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:43.0) Gecko/20100101 Firefox/43.0 Build ID: 20150827030213 Steps to reproduce: Played this video: https://youtu.be/SvBH6e3XgfM Actual results: At around 1:09 sounds cuts off. I tested the same part via Flash Player, and it has worked fine, and also Chrome browser's HTML5 player, and it was fine there. Expected results: Normal continuous playback with sound
Component: Untriaged → Audio/Video: Playback
OS: Unspecified → Windows 7
Product: Firefox → Core
Hardware: Unspecified → x86_64
You're comparing three different things, and three different contents. In Chrome is will be a webm/vp9 video, then you have Flash using its own thing and Firefox using MSE with mp4/h264. I can't reproduce it here at 1:09 ; I do see sounds cutting off from time to time simply because it's rebuffering and YouTube has waited to long to load audio.
you may want to compare with chrome using the same content. set media.mediasource.webm.enabled preference to true then reload the page. Warning: VP9 isn't hardware accelerated, so it will use more CPU than using h264
Thanks; I did not even need additional tests with WebM: after video I cited I have played more videos and in one of them I also had sound abruptly cut off in the middle. However, when I move tracker to a different point at different place then moved it back where sound has disappeared previously, this time sound has picked up again. And now when I tried to reproduce the effect in the video I cited in the initial report, I could not. (All of that is by default settings; it were AVC streams.) This means that this bug is not reliably reproducible and, most likely, is not within exactly playback code, but with decoding. For some reason sometimes it breaks, and other times not -- weirdly enough, the very same stream.
[Tracking Requested - why for this release]: I can reproduce the problem. Especially when the 1080P, It is reproduced 5/5 probability. Regression window: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=b2eb913e58c9c7ddeddb7bdfb95e0846498da514&tochange=bfaf42941097 Suspect:Bug 1195073
Did you turn on webm?? What is right-click "Stats for nerds" showing? Sounds like the same as bug 1199518
(In reply to Jean-Yves Avenard [:jya] from comment #6) > Sorry, I meant bug 1199583 in comment 5 Default(new profile)
Video ID: SvBH6e3XgfM Dimensions: 640 x 360 Resolution: 1920 x 1080@30 Volume: 100% Stream Host: r3---sn-3pm7sn7k Stream Type: https CPN: gi7qc8rJZbEAug6m Mime Type: video/mp4; codecs="avc1.640028" DASH: yes (137/140) Connection Speed: 6755 Kbps Dropped Frames: 2/299
about:media when sound stopped HTMLMediaElement debug data https://www.youtube.com/watch?v=SvBH6e3XgfM&feature=youtu.be mediasource:https://www.youtube.com/264314d8-9a01-404b-be7e-e7c570e2169f currentTime: 73.766238 SourceBuffer 0 start=0 end=70.008185 SourceBuffer 1 start=0.025 end=129.655 Internal Data: Dumping data for demuxer 130f5c00: Dumping Audio Track Buffer(audio/mp4a-latm): - mLastAudioTime: 70.008185 NumSamples:3015 Size:1648146 NextGetSampleIndex:3015 NextInsertionIndex:3015 Buffered: ranges=[(0.000000, 70.008185)] Dumping Video Track Buffer(video/avc) - mLastVideoTime: 73.998900 NumSamples:3886 Size:40018600 NextGetSampleIndex:2218 NextInsertionIndex:3886 Buffered: ranges=[(0.025000, 129.655000)]
Ok; can reproduce it now. STR: 1. Seek to 0. 2. Pause 3. Change resolution to 1080P 4. When reaching 70s, audio will stop playing. there's a another regression here: playback should stall because we don't have audio. Yet it doesn't.
Attachment #8654100 - Flags: review?(gsquelart) → review+
The WebMContainerParser doesn't handle a media segment made of a single block with data. It would properly detect that we had a complete media segment but return false.
Attachment #8654450 - Flags: review?(gsquelart)
Comment on attachment 8654450 [details] [diff] [review] [MSE] Properly handle partial media header received prior a discontinuity. Carrying r+
Attachment #8654450 - Flags: review?(gsquelart) → review+
Just a heads up: this fixes a problem with screen sharing under e10s on Linux as documented in bug 1195303. Therefore it would be good if this could get uplifted to Aurora, but I assume that will be covered by bug 1197083.
Comment on attachment 8654450 [details] [diff] [review] [MSE] Properly handle partial media header received prior a discontinuity. Approval Request Comment [Feature/regressing bug #]: MSE [User impact if declined]: Video playback can stall. This is part of the fix for the regression blocking bug 1197083. [Describe test coverage new/current, TreeHerder]: Landed on m-c some days ago. [Risks and why]: Risk is reasonable. Changes are specific to MSE code. [String/UUID change made/needed]: None.
Attachment #8654450 - Flags: approval-mozilla-aurora?
Attachment #8654100 - Attachment is obsolete: true
Comment on attachment 8654450 [details] [diff] [review] [MSE] Properly handle partial media header received prior a discontinuity. Fix a regression and improve e10s, taking it.
Attachment #8654450 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
I'm hitting conflicts trying to uplift this to aurora. Can we get a branch specific patch for this?
pushed it as part of https://hg.mozilla.org/releases/mozilla-aurora/pushloghtml?changeset=7437f28133fc
You need to log in before you can comment on or make changes to this bug.