Closed Bug 1199573 Opened 6 years ago Closed 6 years ago

Sound during HTML5 video playback cuts off in some videos in Nightly 43a1


(Core :: Audio/Video: Playback, defect)

43 Branch
Windows 7
Not set



Tracking Status
firefox42 --- fixed
firefox43 + fixed


(Reporter: zxspectrum3579, Assigned: jya)




(Keywords: regression)


(1 file, 1 obsolete file)

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:

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:

Suspect:Bug 1195073
Blocks: 1195073
Ever confirmed: true
Keywords: regression
Did you turn on webm??
What is right-click "Stats for nerds" showing?

Sounds like the same as bug 1199518
Flags: needinfo?(alice0775)
Sorry, I meant bug 1199583 in comment 5
(In reply to Jean-Yves Avenard [:jya] from comment #6)
> Sorry, I meant bug 1199583 in comment 5

Default(new profile)
Flags: needinfo?(alice0775)
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
	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.

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.
Assignee: nobody → jyavenard
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+
Duplicate of this bug: 1199583
Blocks: 1197083
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla43
Blocks: 1195303
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
Fixed faster than I could track it. Tracking anyway in case it reopens.
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?
Flags: needinfo?(jyavenard)
Duplicate of this bug: 1200051
You need to log in before you can comment on or make changes to this bug.