Closed Bug 1233970 Opened 9 years ago Closed 9 years ago

YouTube no longer serving MSE/webm to Firefox 43 users.

Categories

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

43 Branch
defect

Tracking

()

RESOLVED FIXED
Tracking Status
firefox42 --- wontfix
firefox43 + verified
firefox44 --- unaffected
firefox45 --- unaffected
firefox46 --- unaffected
relnote-firefox --- 43+

People

(Reporter: anuragg, Assigned: cpearce)

References

Details

Attachments

(2 files, 6 obsolete files)

Attached file ff.txt —
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:43.0) Gecko/20100101 Firefox/43.0
Build ID: 20151216175450

Steps to reproduce:

I have used always used media.mediasource.webm.enabled true in all previous FF versions to let VP9 be default version to be used for html5 videos. But this isn't working anymore on FF 43.0.1. 

1. All videos are being played as mp4/avc.
2. youtube.com/html5 shows VP( enabled but still videos play with mp4/avc.
Attaching about:support file.


Actual results:

Video play in mp4/AVC


Expected results:

Video should have used webm/vp9 codec as in previous release.
Component: Untriaged → Audio/Video: Playback
Product: Firefox → Core
What does this page reports?
http://w3c-test.org/media-source/mediasource-is-type-supported.html

Ultimately, what YouTube decide to use based on browser agent is outside our control.
Chris, is this something we can check with YouTube?
Flags: needinfo?(cpeterson)
(In reply to Jean-Yves Avenard [:jya] from comment #1)
> Ultimately, what YouTube decide to use based on browser agent is outside our
> control.

But why behavior should change after upgrade to newer firefox version ?


Output for: http://w3c-test.org/media-source/mediasource-is-type-supported.html

Summary

Harness status: OK

Found 38 tests
30 Pass
8 Fail
Details
Result	Test Name	Message
Pass	Test invalid MIME format "video"	
Pass	Test invalid MIME format "video/"	
Fail	Test invalid MIME format "video/webm"	assert_equals: supported expected false but got true

test_type_support/<@http://w3c-test.org/media-source/mediasource-is-type-supported.html:17:1
Test.prototype.step@http://w3c-test.org/resources/testharness.js:1382:20
test@http://w3c-test.org/resources/testharness.js:496:9
test_type_support@http://w3c-test.org/media-source/mediasource-is-type-supported.html:15:1
@http://w3c-test.org/media-source/mediasource-is-type-supported.html:23:1

Fail	Test invalid MIME format "video/webm;"	assert_equals: supported expected false but got true

test_type_support/<@http://w3c-test.org/media-source/mediasource-is-type-supported.html:17:1
Test.prototype.step@http://w3c-test.org/resources/testharness.js:1382:20
test@http://w3c-test.org/resources/testharness.js:496:9
test_type_support@http://w3c-test.org/media-source/mediasource-is-type-supported.html:15:1
@http://w3c-test.org/media-source/mediasource-is-type-supported.html:23:1

Fail	Test invalid MIME format "video/webm;codecs"	assert_equals: supported expected false but got true

test_type_support/<@http://w3c-test.org/media-source/mediasource-is-type-supported.html:17:1
Test.prototype.step@http://w3c-test.org/resources/testharness.js:1382:20
test@http://w3c-test.org/resources/testharness.js:496:9
test_type_support@http://w3c-test.org/media-source/mediasource-is-type-supported.html:15:1
@http://w3c-test.org/media-source/mediasource-is-type-supported.html:23:1

Fail	Test invalid MIME format "video/webm;codecs="	assert_equals: supported expected false but got true

test_type_support/<@http://w3c-test.org/media-source/mediasource-is-type-supported.html:17:1
Test.prototype.step@http://w3c-test.org/resources/testharness.js:1382:20
test@http://w3c-test.org/resources/testharness.js:496:9
test_type_support@http://w3c-test.org/media-source/mediasource-is-type-supported.html:15:1
@http://w3c-test.org/media-source/mediasource-is-type-supported.html:23:1

Fail	Test invalid MIME format "video/webm;codecs=""	assert_equals: supported expected false but got true

test_type_support/<@http://w3c-test.org/media-source/mediasource-is-type-supported.html:17:1
Test.prototype.step@http://w3c-test.org/resources/testharness.js:1382:20
test@http://w3c-test.org/resources/testharness.js:496:9
test_type_support@http://w3c-test.org/media-source/mediasource-is-type-supported.html:15:1
@http://w3c-test.org/media-source/mediasource-is-type-supported.html:23:1

Fail	Test invalid MIME format "video/webm;codecs="""	assert_equals: supported expected false but got true

test_type_support/<@http://w3c-test.org/media-source/mediasource-is-type-supported.html:17:1
Test.prototype.step@http://w3c-test.org/resources/testharness.js:1382:20
test@http://w3c-test.org/resources/testharness.js:496:9
test_type_support@http://w3c-test.org/media-source/mediasource-is-type-supported.html:15:1
@http://w3c-test.org/media-source/mediasource-is-type-supported.html:23:1

Pass	Test invalid MIME format "video/webm;codecs=",""	
Pass	Test invalid MIME format ""	
Pass	Test invalid MIME format "null"	
Fail	Test invalid mismatch between major type and codec ID "audio/webm;codecs="vp8""	assert_equals: supported expected false but got true

test_type_support/<@http://w3c-test.org/media-source/mediasource-is-type-supported.html:17:1
Test.prototype.step@http://w3c-test.org/resources/testharness.js:1382:20
test@http://w3c-test.org/resources/testharness.js:496:9
test_type_support@http://w3c-test.org/media-source/mediasource-is-type-supported.html:15:1
@http://w3c-test.org/media-source/mediasource-is-type-supported.html:37:1

Pass	Test invalid mismatch between major type and codec ID "audio/mp4;codecs="avc1.4d001e""	
Pass	Test invalid mismatch between minor type and codec ID "audio/mp4;codecs="vorbis""	
Pass	Test invalid mismatch between minor type and codec ID "audio/webm;codecs="mp4a.40.2""	
Pass	Test invalid mismatch between minor type and codec ID "video/mp4;codecs="vp8""	
Pass	Test invalid mismatch between minor type and codec ID "video/webm;codecs="mp4a.40.2""	
Pass	Test invalid mismatch between minor type and codec ID "video/mp4;codecs="vorbis""	
Pass	Test invalid mismatch between minor type and codec ID "video/webm;codecs="mp4a.40.2""	
Pass	Test invalid codec ID "audio/mp4;codecs="mp4a""	
Pass	Test invalid codec ID "audio/mp4;codecs="mp4a.40""	
Pass	Test invalid codec ID "audio/mp4;codecs="mp4a.40.""	
Pass	Test invalid codec ID "audio/mp4;codecs="mp4a.67.3""	
Pass	Test valid WebM type "video/webm;codecs="vp8""	
Pass	Test valid WebM type "video/webm;codecs="vorbis""	
Pass	Test valid WebM type "video/webm;codecs="vp8,vorbis""	
Pass	Test valid WebM type "video/webm;codecs="vorbis, vp8""	
Pass	Test valid WebM type "audio/webm;codecs="vorbis""	
Fail	Test valid WebM type "AUDIO/WEBM;CODECS="vorbis""	assert_equals: supported expected true but got false

test_type_support/<@http://w3c-test.org/media-source/mediasource-is-type-supported.html:17:1
Test.prototype.step@http://w3c-test.org/resources/testharness.js:1382:20
test@http://w3c-test.org/resources/testharness.js:496:9
test_type_support@http://w3c-test.org/media-source/mediasource-is-type-supported.html:15:1
@http://w3c-test.org/media-source/mediasource-is-type-supported.html:58:1

Pass	Test valid MP4 type "video/mp4;codecs="avc1.4d001e""	
Pass	Test valid MP4 type "video/mp4;codecs="avc1.42001e""	
Pass	Test valid MP4 type "audio/mp4;codecs="mp4a.40.2""	
Pass	Test valid MP4 type "audio/mp4;codecs="mp4a.40.5""	
Pass	Test valid MP4 type "audio/mp4;codecs="mp4a.67""	
Pass	Test valid MP4 type "video/mp4;codecs="mp4a.40.2""	
Pass	Test valid MP4 type "video/mp4;codecs="avc1.4d001e,mp4a.40.2""	
Pass	Test valid MP4 type "video/mp4;codecs="mp4a.40.2 , avc1.4d001e ""	
Pass	Test valid MP4 type "video/mp4;codecs="avc1.4d001e,mp4a.40.5""
(In reply to anuragg from comment #2)
> (In reply to Jean-Yves Avenard [:jya] from comment #1)
> > Ultimately, what YouTube decide to use based on browser agent is outside our
> > control.
> 
> But why behavior should change after upgrade to newer firefox version ?
> 
> 

Because the user agent changed?
Try changing it back to say it's 42 instead of 43. 

That would prove my theory. 

Because as it is. The test below shows that everything is as it should be. 
You have mediasource webm available. 

Try this stream:
http://blog.wirewax.com/building-a-media-source-html5-player-with-adaptive-streaming-44/

Or this one:
http://people.mozilla.org/~jyavenard/tests/mse_webm/youtube-stall.html

Does it play?
@ Richard, do you know why YouTube would start serving MP4 to a Firefox 43 user (on OS X 10.6) who previously received WebM with Firefox 42? They manually opted into WebM by flipping the about:config pref "media.mediasource.webm.enabled" to true.

@ Anuragg, do you still receive MP4 if you create a new Firefox profile?

https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles
Flags: needinfo?(cpeterson) → needinfo?(rleider)
> 
> @ Anuragg, do you still receive MP4 if you create a new Firefox profile?
> 

Thanks - i created a new profile, enabled webm flag to true, still seeing mp4/AVC1 being served for 43.0.1.
(In reply to Jean-Yves Avenard [:jya] from comment #3)

> Try this stream:
> http://blog.wirewax.com/building-a-media-source-html5-player-with-adaptive-
> streaming-44/
> 
> Or this one:
> http://people.mozilla.org/~jyavenard/tests/mse_webm/youtube-stall.html
> 
> Does it play?

Both Play.
Log from 2nd video:
1: Log: (times in ms)
2: files=../../mediatest/webm/segment-164a1ea00-00026.bin,../../mediatest/webm/segment-164a1ea00-00027.bin,../../mediatest/webm/segment-164a1ea00-00028.bin,../../mediatest/webm/segment-164a1ea00-00029.bin,../../mediatest/webm/segment-164a1ea00-00030.bin,../../mediatest/webm/segment-164a1ea00-00031.bin,../../mediatest/webm/segment-164a1ea00-00032.bin,../../mediatest/webm/segment-164a1ea00-00033.bin,../../mediatest/webm/segment-164a1ea00-00034.bin,../../mediatest/webm/segment-164a1ea00-00035.bin,../../mediatest/webm/segment-164a1ea00-00036.bin,../../mediatest/webm/segment-164a1ea00-00037.bin,../../mediatest/webm/segment-164a1ea00-00038.bin,../../mediatest/webm/segment-164a1ea00-00039.bin
2: mime=audio/webm
2: codecs=opus
7: * video.ratechange
12: * video.loadstart
12: * mediaSource.sourceopen - mediaSource readyState: open
12: mediaSource.addSourceBuffer('audio/webm; codecs=opus)
12: mediaSource readyState: open
13: Will download: [0]../../mediatest/webm/segment-164a1ea00-00026.bin
14: Will download: [1]../../mediatest/webm/segment-164a1ea00-00027.bin
15: Will download: [2]../../mediatest/webm/segment-164a1ea00-00028.bin
16: Will download: [3]../../mediatest/webm/segment-164a1ea00-00029.bin
17: Will download: [4]../../mediatest/webm/segment-164a1ea00-00030.bin
18: Will download: [5]../../mediatest/webm/segment-164a1ea00-00031.bin
19: Will download: [6]../../mediatest/webm/segment-164a1ea00-00032.bin
20: Will download: [7]../../mediatest/webm/segment-164a1ea00-00033.bin
21: Will download: [8]../../mediatest/webm/segment-164a1ea00-00034.bin
22: Will download: [9]../../mediatest/webm/segment-164a1ea00-00035.bin
24: Will download: [10]../../mediatest/webm/segment-164a1ea00-00036.bin
25: Will download: [11]../../mediatest/webm/segment-164a1ea00-00037.bin
26: Will download: [12]../../mediatest/webm/segment-164a1ea00-00038.bin
27: Will download: [13]../../mediatest/webm/segment-164a1ea00-00039.bin
35: URL ../../mediatest/webm/segment-164a1ea00-00026.bin loaded.
36: Downloaded: [0]../../mediatest/webm/segment-164a1ea00-00026.bin size=272
36: URL ../../mediatest/webm/segment-164a1ea00-00027.bin loaded.
36: Downloaded: [1]../../mediatest/webm/segment-164a1ea00-00027.bin size=65536
37: URL ../../mediatest/webm/segment-164a1ea00-00028.bin loaded.
37: Downloaded: [2]../../mediatest/webm/segment-164a1ea00-00028.bin size=65536
37: URL ../../mediatest/webm/segment-164a1ea00-00029.bin loaded.
37: Downloaded: [3]../../mediatest/webm/segment-164a1ea00-00029.bin size=1452
37: URL ../../mediatest/webm/segment-164a1ea00-00030.bin loaded.
38: Downloaded: [4]../../mediatest/webm/segment-164a1ea00-00030.bin size=40592
38: URL ../../mediatest/webm/segment-164a1ea00-00031.bin loaded.
38: Downloaded: [5]../../mediatest/webm/segment-164a1ea00-00031.bin size=23492
38: URL ../../mediatest/webm/segment-164a1ea00-00032.bin loaded.
38: Downloaded: [6]../../mediatest/webm/segment-164a1ea00-00032.bin size=65536
39: URL ../../mediatest/webm/segment-164a1ea00-00033.bin loaded.
39: Downloaded: [7]../../mediatest/webm/segment-164a1ea00-00033.bin size=149028
39: URL ../../mediatest/webm/segment-164a1ea00-00034.bin loaded.
40: Downloaded: [8]../../mediatest/webm/segment-164a1ea00-00034.bin size=68539
40: URL ../../mediatest/webm/segment-164a1ea00-00035.bin loaded.
40: Downloaded: [9]../../mediatest/webm/segment-164a1ea00-00035.bin size=142384
41: URL ../../mediatest/webm/segment-164a1ea00-00036.bin loaded.
41: Downloaded: [10]../../mediatest/webm/segment-164a1ea00-00036.bin size=404515
41: URL ../../mediatest/webm/segment-164a1ea00-00037.bin loaded.
42: Downloaded: [11]../../mediatest/webm/segment-164a1ea00-00037.bin size=402509
42: URL ../../mediatest/webm/segment-164a1ea00-00038.bin loaded.
42: Downloaded: [12]../../mediatest/webm/segment-164a1ea00-00038.bin size=391388
43: URL ../../mediatest/webm/segment-164a1ea00-00039.bin loaded.
43: Downloaded: [13]../../mediatest/webm/segment-164a1ea00-00039.bin size=65536
43: All downloads finished
43: sourceBuffer.appendBuffer([0]../../mediatest/webm/segment-164a1ea00-00026.bin, length 272):
61: * sourceBuffer.updatestart
62: * video.progress
62: * sourceBuffer.update
62: * sourceBuffer.updateend
62: sourceBuffer.buffered.length = 0
63: sourceBuffer.duration = 0
63: video.duration=169.001
63: mediasource.duration = 169.001
63: video.buffered ={}
63: * sourceBuffer.updateend for sourceBuffer.appendBuffer([0]../../mediatest/webm/segment-164a1ea00-00026.bin, length 272)
63: sourceBuffer.appendBuffer([1]../../mediatest/webm/segment-164a1ea00-00027.bin, length 65536):
64: * sourceBuffer.updatestart
64: * video.durationchange
64: video.duration=169.001
64: mediasource.duration = 169.001
70: video.loadedmetadata
70: video.height=0
70: video.width=0
70: video.duration=169.001
70: mediasource.duration = 169.001
71: * video.loadeddata
71: * sourceBuffer.update
71: * sourceBuffer.updateend
71: sourceBuffer.buffered.length = 1
71: sourceBuffer.buffered.start(0) = 80.001
72: sourceBuffer.duration = 2.9799999999999898
72: video.duration=169.001
72: mediasource.duration = 169.001
72: video.buffered ={{ 80.001,82.981 }}
72: * sourceBuffer.updateend for sourceBuffer.appendBuffer([1]../../mediatest/webm/segment-164a1ea00-00027.bin, length 65536)
73: sourceBuffer.appendBuffer([2]../../mediatest/webm/segment-164a1ea00-00028.bin, length 65536):
77: * sourceBuffer.updatestart
77: * video.play
78: * video.timeupdate
79: * video.waiting. video.currentTime=77.981
90: * video.seeking
114: * sourceBuffer.update
114: * sourceBuffer.updateend
115: sourceBuffer.buffered.length = 1
115: sourceBuffer.buffered.start(0) = 80.001
115: sourceBuffer.duration = 6.280000000000001
115: video.duration=169.001
115: mediasource.duration = 169.001
115: video.buffered ={{ 80.001,86.281 }}
115: * sourceBuffer.updateend for sourceBuffer.appendBuffer([2]../../mediatest/webm/segment-164a1ea00-00028.bin, length 65536)
116: sourceBuffer.appendBuffer([3]../../mediatest/webm/segment-164a1ea00-00029.bin, length 1452):
117: * sourceBuffer.updatestart
119: * video.seeking
121: * video.timeupdate
123: * video.seeked
123: * video.canplay
124: * video.playing
133: * sourceBuffer.update
133: * sourceBuffer.updateend
133: sourceBuffer.buffered.length = 1
133: sourceBuffer.buffered.start(0) = 80.001
133: sourceBuffer.duration = 6.339999999999989
134: video.duration=169.001
134: mediasource.duration = 169.001
134: video.buffered ={{ 80.001,86.341 }}
134: * sourceBuffer.updateend for sourceBuffer.appendBuffer([3]../../mediatest/webm/segment-164a1ea00-00029.bin, length 1452)
134: sourceBuffer.appendBuffer([4]../../mediatest/webm/segment-164a1ea00-00030.bin, length 40592):
142: * sourceBuffer.updatestart
160: * video.waiting. video.currentTime=81.341
163: * sourceBuffer.update
163: * sourceBuffer.updateend
164: sourceBuffer.buffered.length = 1
164: sourceBuffer.buffered.start(0) = 80.001
164: sourceBuffer.duration = 8.33999999999999
164: video.duration=169.001
164: mediasource.duration = 169.001
165: video.buffered ={{ 80.001,88.341 }}
165: * sourceBuffer.updateend for sourceBuffer.appendBuffer([4]../../mediatest/webm/segment-164a1ea00-00030.bin, length 40592)
165: sourceBuffer.appendBuffer([5]../../mediatest/webm/segment-164a1ea00-00031.bin, length 23492):
169: * video.seeking
170: * sourceBuffer.updatestart
171: * video.canplay
171: * video.playing
182: * video.seeking
184: * video.timeupdate
184: * video.seeked
185: * video.canplay
185: * video.playing
192: * sourceBuffer.update
192: * sourceBuffer.updateend
192: sourceBuffer.buffered.length = 1
192: sourceBuffer.buffered.start(0) = 80.001
193: sourceBuffer.duration = 9.5
193: video.duration=169.001
193: mediasource.duration = 169.001
193: video.buffered ={{ 80.001,89.501 }}
193: * sourceBuffer.updateend for sourceBuffer.appendBuffer([5]../../mediatest/webm/segment-164a1ea00-00031.bin, length 23492)
194: sourceBuffer.appendBuffer([6]../../mediatest/webm/segment-164a1ea00-00032.bin, length 65536):
207: * sourceBuffer.updatestart
215: * video.waiting. video.currentTime=84.501
221: * sourceBuffer.update
221: * sourceBuffer.updateend
221: sourceBuffer.buffered.length = 1
222: sourceBuffer.buffered.start(0) = 80.001
222: sourceBuffer.duration = 12.64
222: video.duration=169.001
222: mediasource.duration = 169.001
222: video.buffered ={{ 80.001,92.641 }}
223: * sourceBuffer.updateend for sourceBuffer.appendBuffer([6]../../mediatest/webm/segment-164a1ea00-00032.bin, length 65536)
223: sourceBuffer.appendBuffer([7]../../mediatest/webm/segment-164a1ea00-00033.bin, length 149028):
233: * video.seeking
234: * sourceBuffer.updatestart
235: * video.canplay
235: * video.playing
236: * video.seeking
238: * video.timeupdate
238: * video.seeked
238: * video.canplay
239: * video.playing
248: * sourceBuffer.update
248: * sourceBuffer.updateend
248: sourceBuffer.buffered.length = 1
248: sourceBuffer.buffered.start(0) = 80.001
248: sourceBuffer.duration = 19.799999999999997
249: video.duration=169.001
249: mediasource.duration = 169.001
249: video.buffered ={{ 80.001,99.801 }}
249: * sourceBuffer.updateend for sourceBuffer.appendBuffer([7]../../mediatest/webm/segment-164a1ea00-00033.bin, length 149028)
249: sourceBuffer.appendBuffer([8]../../mediatest/webm/segment-164a1ea00-00034.bin, length 68539):
250: * sourceBuffer.updatestart
250: * video.waiting. video.currentTime=94.801
285: * sourceBuffer.update
285: * sourceBuffer.updateend
285: sourceBuffer.buffered.length = 1
286: sourceBuffer.buffered.start(0) = 80.001
286: sourceBuffer.duration = 23
286: video.duration=169.001
286: mediasource.duration = 169.001
286: video.buffered ={{ 80.001,103.001 }}
286: * sourceBuffer.updateend for sourceBuffer.appendBuffer([8]../../mediatest/webm/segment-164a1ea00-00034.bin, length 68539)
287: sourceBuffer.appendBuffer([9]../../mediatest/webm/segment-164a1ea00-00035.bin, length 142384):
316: * video.seeking
316: * sourceBuffer.updatestart
328: * video.canplay
329: * video.playing
334: * video.seeking
335: * video.timeupdate
336: * video.seeked
336: * video.canplay
336: * video.playing
336: * sourceBuffer.update
336: * sourceBuffer.updateend
336: sourceBuffer.buffered.length = 1
337: sourceBuffer.buffered.start(0) = 80.001
337: sourceBuffer.duration = 30
337: video.duration=169.001
337: mediasource.duration = 169.001
337: video.buffered ={{ 80.001,110.001 }}
337: * sourceBuffer.updateend for sourceBuffer.appendBuffer([9]../../mediatest/webm/segment-164a1ea00-00035.bin, length 142384)
338: sourceBuffer.appendBuffer([10]../../mediatest/webm/segment-164a1ea00-00036.bin, length 404515):
339: * sourceBuffer.updatestart
340: * video.waiting. video.currentTime=105.001
367: * sourceBuffer.update
367: * sourceBuffer.updateend
367: sourceBuffer.buffered.length = 1
368: sourceBuffer.buffered.start(0) = 80.001
368: sourceBuffer.duration = 50
368: video.duration=169.001
368: mediasource.duration = 169.001
368: video.buffered ={{ 80.001,130.001 }}
369: * sourceBuffer.updateend for sourceBuffer.appendBuffer([10]../../mediatest/webm/segment-164a1ea00-00036.bin, length 404515)
369: sourceBuffer.appendBuffer([11]../../mediatest/webm/segment-164a1ea00-00037.bin, length 402509):
371: * video.seeking
371: * sourceBuffer.updatestart
380: * video.canplay
381: * video.playing
383: * video.seeking
385: * video.timeupdate
386: * video.seeked
386: * video.canplay
387: * video.playing
387: * sourceBuffer.update
388: * sourceBuffer.updateend
388: sourceBuffer.buffered.length = 1
388: sourceBuffer.buffered.start(0) = 80.001
388: sourceBuffer.duration = 70
388: video.duration=169.001
388: mediasource.duration = 169.001
388: video.buffered ={{ 80.001,150.001 }}
388: * sourceBuffer.updateend for sourceBuffer.appendBuffer([11]../../mediatest/webm/segment-164a1ea00-00037.bin, length 402509)
389: sourceBuffer.appendBuffer([12]../../mediatest/webm/segment-164a1ea00-00038.bin, length 391388):
397: * sourceBuffer.updatestart
398: * video.waiting. video.currentTime=145.001
426: * video.progress
426: * video.durationchange
426: video.duration=169.021
427: mediasource.duration = 169.021
427: * sourceBuffer.update
427: * sourceBuffer.updateend
427: sourceBuffer.buffered.length = 1
428: sourceBuffer.buffered.start(0) = 80.001
428: sourceBuffer.duration = 89.01999999999998
428: video.duration=169.021
428: mediasource.duration = 169.021
428: video.buffered ={{ 80.001,169.021 }}
428: * sourceBuffer.updateend for sourceBuffer.appendBuffer([12]../../mediatest/webm/segment-164a1ea00-00038.bin, length 391388)
428: sourceBuffer.appendBuffer([13]../../mediatest/webm/segment-164a1ea00-00039.bin, length 65536):
467: * video.seeking
467: * sourceBuffer.updatestart
470: * video.canplay
471: * video.playing
473: * video.seeking
475: * video.timeupdate
476: * video.seeked
476: * video.canplay
476: * video.playing
483: * sourceBuffer.update
483: * sourceBuffer.updateend
483: sourceBuffer.buffered.length = 2
483: sourceBuffer.buffered.start(0) = 0
483: sourceBuffer.duration = 6.041
483: video.duration=169.021
483: mediasource.duration = 169.021
484: video.buffered ={{ 0,6.041 }{ 80.001,169.021 }}
484: * sourceBuffer.updateend for sourceBuffer.appendBuffer([13]../../mediatest/webm/segment-164a1ea00-00039.bin, length 65536)
485: * video.waiting. video.currentTime=164.021
511: * video.seeking
512: * video.waiting. video.currentTime=164.021
513: * video.timeupdate
514: * video.seeked
515: * video.canplay
515: * video.playing
797: * video.timeupdate
1067: * video.progress
1082: * video.timeupdate
1366: * video.timeupdate
1649: * video.timeupdate
1930: * video.timeupdate
2216: * video.timeupdate
2498: * video.timeupdate
2780: * video.timeupdate
3064: * video.timeupdate
3345: * video.timeupdate
3519: * video.stalled
3630: * video.timeupdate
3913: * video.timeupdate
4197: * video.timeupdate
4483: * video.timeupdate
4768: * video.timeupdate
5051: * video.timeupdate
5333: * video.timeupdate
Ok. The issue is on YouTube side then.
I can confirm that changing my user-agent from "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:44.0) Gecko/20100101 Firefox/44.0" to "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:43.0) Gecko/20100101 Firefox/43.0"

and I no longer get serve mse/webm
Summary: Update to Firefox 43 (Mac OSX) breaks HTML 5(VP9 - Youtube) Video player → YouTube no longer serving MSE/webm to Firefox 43 users.
See Also: → 1233340
(In reply to Jean-Yves Avenard [:jya] from comment #7)
> Ok. The issue is on YouTube side then.

Jean-Yves is correct. YouTube changed something on their side. We're talking with our YouTube contacts now.
Flags: needinfo?(rleider)
[Tracking Requested - why for this release]: install with no h264 decoder (Windows XP, Windows Vista without media extension, Windows 7/8/10 K and KN variant will only play Youtube at a maximum 360p

Google has indicated that they won't fix their problem until January. We want to fake our user agent to report version 44 when accessing youtube URLs.
Attached patch Patch: Hardcode YouTube.com override in C++ (obsolete) — — Splinter Review
So it turns out the Firefox team disabled site-specific overrides in bug 896114 because processing the overrides took up about ~8.9% of page load time...

So we could hard-code the override for youtube in C++ in Navigator::GetUserAgent() to avoid any perf regression.

jya: does this work?
Attachment #8701012 - Flags: feedback?(jyavenard)
Attachment #8701012 - Attachment is obsolete: true
Attachment #8701012 - Flags: feedback?(jyavenard)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P1
Comment on attachment 8701020 [details] [diff] [review]
Patch: Hardcode YouTube.com override in C++

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

::: dom/base/Navigator.cpp
@@ +2798,5 @@
> +    MOZ_LOG(sLogModule,
> +            mozilla::LogLevel::Debug,
> +            ("Navigator::GetUserAgent() origin=%s", NS_ConvertUTF16toUTF8(origin).get()));
> +
> +    if (NS_SUCCEEDED(rv) && origin.EqualsLiteral("https://www.youtube.com")) {

You should ignore the URL scheme because YouTube still serves http:// to some regions.
Attached patch Patch: Hardcode YouTube.com override in C++ (obsolete) — — Splinter Review
jya: does this work?
Attachment #8701168 - Flags: feedback?(jyavenard)
Attachment #8701020 - Attachment is obsolete: true
Should we not wrap all this logic in #ifdef XP_WIN to limit the impact of this change as much as we can?
* Detect when the we're loading YouTube, and change the userAgent to from Firefox 43 to be Firefox 44.
* This means YouTube will serve use MSE+WebM/VP9, instead of 360p non-MSE.
Assignee: nobody → cpearce
Attachment #8701168 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #8701168 - Flags: feedback?(jyavenard)
(In reply to Chris Pearce (:cpearce) from comment #17)
> Created attachment 8701224 [details] [diff] [review]
> Patch: Override userAgent to masquerade Firefox 43 as 44.
> 
> * Detect when the we're loading YouTube, and change the userAgent to from
> Firefox 43 to be Firefox 44.
> * This means YouTube will serve use MSE+WebM/VP9, instead of 360p non-MSE.

Note: this is a patch against 43, which we intent to ship as a dot release in 43 only.
We are already shipping 43.0.2 today.
Discussed with ajones here, and we think it's best for Firefox 43 to masquerade as 42, as that means affected YouTube users will fallback to Flash, which has a known risk profile. We've not had much chance to see MSE/WebM running on XP hardware yet.
Attachment #8701224 - Attachment is obsolete: true
Attachment #8701239 - Flags: review?(jduell.mcbugs)
Attachment #8701239 - Flags: review?(bugs)
Comment on attachment 8701239 [details] [diff] [review]
Patch: Override userAgent to masquerade Firefox 43 as 42.

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

Not the most beautiful hack in the world, but if this will exist only in FF 43 I'm good with it.
Attachment #8701239 - Flags: review?(jduell.mcbugs) → review+
Attachment #8701239 - Attachment is obsolete: true
Attachment #8701239 - Flags: review?(bugs)
Attachment #8701250 - Flags: review?(bugs)
Comment on attachment 8701250 [details] [diff] [review]
Patch: Override userAgent to masquerade Firefox 43 as 42.

>+  if (mozilla::Preferences::GetBool("media.youtube-ua.override", false) &&
>+      nsContentUtils::IsYouTubeURI(aURI)) {
>+    const nsAdoptingString& from =
>+      mozilla::Preferences::GetString("media.youtube-ua.override.from");
>+    const nsAdoptingString& to =
>+      mozilla::Preferences::GetString("media.youtube-ua.override.to");
>+    if (!from.IsEmpty() && !to.IsEmpty()) {
>+      ua.ReplaceSubstring(NS_ConvertUTF16toUTF8(from), NS_ConvertUTF16toUTF8(to));
>+      CopyASCIItoUTF16(ua, aUserAgent);
>+    }
>+    return NS_OK;
I don't understand why we need to call CopyASCIItoUTF16 early here and also return early.
Don't we want nsISiteSpecificUserAgent to be used, if it is available.


>+  return eTLDplusOne.EqualsLiteral("youtube.com") ||
>+         eTLDplusOne.EqualsLiteral("youtube-nocookie.com") ||
>+         eTLDplusOne.EqualsLiteral("ytimg.com");
It would be really nice to have some comment here to hint why these domains.


>+    mOverrideYouTubeUserAgent = mozilla::Preferences::GetBool("media.youtube-ua.override", false);
And it is ensured that this is called only on mainthread?


>@@ -684,16 +692,28 @@ nsHttpHandler::BuildUserAgent()
>     }
>     if (!isFirefox) {
>         // App portion
>         mUserAgent += ' ';
>         mUserAgent += mAppName;
>         mUserAgent += '/';
>         mUserAgent += mAppVersion;
>     }
>+
>+    if (mOverrideYouTubeUserAgent) {
>+      mYouTubeUserAgent = mUserAgent;
>+      const nsAdoptingString& from =
>+        mozilla::Preferences::GetString("media.youtube-ua.override.from");
>+      const nsAdoptingString& to =
>+        mozilla::Preferences::GetString("media.youtube-ua.override.to");
>+      if (!from.IsEmpty() && !to.IsEmpty()) {
>+          mYouTubeUserAgent.ReplaceSubstring(NS_ConvertUTF16toUTF8(from),
>+                                             NS_ConvertUTF16toUTF8(to));
>+      }
>+    }
And this. Is this main thread only method?
Especially this is something I can't verify easily.
Can't really give r+ unless I hear some convincing argument that this all is safe.
Attachment #8701250 - Flags: review?(bugs)
Addressed comments.
Pref are now cached in Init() method (called on main thread)
Attachment #8701339 - Flags: review?(bugs)
Attachment #8701250 - Attachment is obsolete: true
Olli, for the background, the issue at play is that YouTube has made a change on their backend that limits 43 users to 360p resolution. They won't fix it until next year.

It's been decided that we would fake our user agent until then to report as 42 so at least people get adaptative high-resolution flash.
Apologies to all impacted by this transient configuration.  Firefox 43 users who do not have h.264 will get 360p VP8 until the configuration is updated early next year.  The very large majority of Firefox users watching YouTube have h.264. For them, and for user who get VP9, <video> MSE performs better overall than Flash.
(In reply to Richard Leider from comment #26)
> Apologies to all impacted by this transient configuration.  Firefox 43 users
> who do not have h.264 will get 360p VP8 until the configuration is updated
> early next year.  The very large majority of Firefox users watching YouTube
> have h.264. For them, and for user who get VP9, <video> MSE performs better
> overall than Flash.

Richard, thanks for your comment here. Unfortunately this is not an acceptable state for us. We have many millions of users whose Youtube experience suddenly got significantly degraded, and we're not willing to leave them in that state over the holidays. Any chance you guys could simply roll back the change you guys made? If not, we're forced to ship a Firefox update that lies to you guys about the Firefox version, which really is not a good option for either of us :(
Unfortunately, the YouTube code won't be updated until January.
Comment on attachment 8701339 [details] [diff] [review]
Override YouTube userAgent to fake Firefox 42 in Firefox 43.

>+
>+
>+    rv = Preferences::AddBoolVarCache(&mOverrideYouTubeUserAgent,
>+                                      "media.youtube-ua.override", false);
Nit, extra newline before this.


>+    if (NS_FAILED(rv)) {
>+        mOverrideYouTubeUserAgent = false;
>+    }
>+    mOverrideYouTubeUserAgentFrom =
>+        NS_ConvertUTF16toUTF8(mozilla::Preferences::GetString("media.youtube-ua.override.from"));
>+    mOverrideYouTubeUserAgentTo =
>+        NS_ConvertUTF16toUTF8(mozilla::Preferences::GetString("media.youtube-ua.override.to"));
>+
I would have put all this pref handling to 
InitUserAgentComponents but either way, doesn't matter much
Attachment #8701339 - Flags: review?(bugs) → review+
(In reply to Olli Pettay [:smaug] from comment #29)

> I would have put all this pref handling to 
> InitUserAgentComponents but either way, doesn't matter much

It was put there as this is the function where another pref is read.
Comment on attachment 8701339 [details] [diff] [review]
Override YouTube userAgent to fake Firefox 42 in Firefox 43.

Approval Request Comment
[Feature/regressing bug #]: None, it's a YouTube backend issue
[User impact if declined]: 6% of YouTube firefox users will get 360P non-adaptative video. After this patch is applied, they will get what they used to get with 42 (which on Windows XP is flash and on linux is MSE/webm)
[Describe test coverage new/current, TreeHerder]: Manual tests on multiple platforms.
[Risks and why]: Hard to assess, the hack is very localised to users with YouTube. Can't think of any,
[String/UUID change made/needed]: None
Attachment #8701339 - Flags: approval-mozilla-release?
Comment on attachment 8701339 [details] [diff] [review]
Override YouTube userAgent to fake Firefox 42 in Firefox 43.

Taking the patch in release in case we do a dot release.
Attachment #8701339 - Flags: approval-mozilla-release? → approval-mozilla-release+
Added to the release notes with "On some Windows configurations, fix the decoding of some videos on YouTube (1233970)" as wording.
We ran Firefox 43.0.3 on multiple platforms and saw that on Windows XP 32-bit with HTML5 enabled we will not get more then 360p and on other platforms the quality is not affected, see bellow for more details. .
I noticed that it's the same with Firefox 42.0, so I need a confirmation is this is intended or not.

- Windows 7 x64, Windows 10 x64 and Mac OS X 10.9.5 (HTML5 by default)
-- Supported: WebM VP8 / Media Source Extensions / HTMLVideoElement / H.264 / MSE & H.264
-- Not supported: *MSE & WebM VP9*
--- Mime Type: video/mp4; codecs="avc1.640028"
-- Max resolution not affected for both Flash and HTML5.

- Windows XP 32bit (Flash by default)
-- Supported: *MSE & WebM VP9* / WebM VP8 / Media Source Extensions / HTMLVideoElement
--- Mime Type: vireo/webm; codecs="vp8.0, vorbis"
-- Not Supported: H.264 / MSE & H.264
-- Max resolution 
--- 360p on HTML5
--- not affected on Flash


- Ubuntu 13.04 (Flash by default)
-- Supported: MSE & WebM VP9 / WebM VP8 / Media Source Extensions / HTMLVideoElement / H.264 / MSE & H.264
--- Mime Type: video/mp4; codecs="avc1.4d401f"
-- Max resolution not affected for both Flash and HTML5.
Flags: needinfo?(jyavenard)
Being like 42 is exactly what we want as far as what system is used. 
What you should see is that if h264 isn't supported you get either MSE/webm-vp9 or Flash. For now due to YouTube bug you will get flash. 

The difference with 42 is that on system where h264 isn't supported or if there's no hardware acceleration available (like you would have in a virtual machine or systems with broken drivers), you now have MSE/webm enabled.

When you tube fixes their configuration, we expect all the systems normally using flash to now use html5/MSE 

From your message, things appear to be as they should be: unless the user selected to force html5: you should be getting flash
Flags: needinfo?(jyavenard)
(In reply to Bogdan Maris, QA [:bogdan_maris] from comment #35)
> We ran Firefox 43.0.3 on multiple platforms and saw that on Windows XP
> 32-bit with HTML5 enabled we will not get more then 360p and on other
> platforms the quality is not affected, see bellow for more details. .
> I noticed that it's the same with Firefox 42.0, so I need a confirmation is
> this is intended or not.
> 
> - Windows 7 x64, Windows 10 x64 and Mac OS X 10.9.5 (HTML5 by default)
> -- Supported: WebM VP8 / Media Source Extensions / HTMLVideoElement / H.264
> / MSE & H.264
> -- Not supported: *MSE & WebM VP9*
> --- Mime Type: video/mp4; codecs="avc1.640028"
> -- Max resolution not affected for both Flash and HTML5.
> 
> - Windows XP 32bit (Flash by default)
> -- Supported: *MSE & WebM VP9* / WebM VP8 / Media Source Extensions /
> HTMLVideoElement
> --- Mime Type: vireo/webm; codecs="vp8.0, vorbis"
> -- Not Supported: H.264 / MSE & H.264
> -- Max resolution 
> --- 360p on HTML5
> --- not affected on Flash
> 
> 
> - Ubuntu 13.04 (Flash by default)
> -- Supported: MSE & WebM VP9 / WebM VP8 / Media Source Extensions /
> HTMLVideoElement / H.264 / MSE & H.264
> --- Mime Type: video/mp4; codecs="avc1.4d401f"
> -- Max resolution not affected for both Flash and HTML5.

Can this be checked on OSX platforms too possibly ? I filed this as saw issue on OSX 10.9/10.6.8 also - where webm/vp9 was not being served even though enabled.
Mac has hardware accelerated video. So as described in comment 76 MSE/h264 will be used by default and is unaffected by the YouTube problem.

It will receive MSE/webm if the user manually enabled (your case) when YouTube fix their configuration (scheduled for January)
(In reply to anuragg from comment #37)
> (In reply to Bogdan Maris, QA [:bogdan_maris] from comment #35)
> > - Windows 7 x64, Windows 10 x64 and *Mac OS X 10.9.5* (HTML5 by default)
> > -- Supported: WebM VP8 / Media Source Extensions / HTMLVideoElement / H.264
> > / MSE & H.264
> > -- Not supported: *MSE & WebM VP9*
> > --- Mime Type: video/mp4; codecs="avc1.640028"
> > -- Max resolution not affected for both Flash and HTML5.
> 
> Can this be checked on OSX platforms too possibly ? I filed this as saw
> issue on OSX 10.9/10.6.8 also - where webm/vp9 was not being served even
> though enabled.

Already did checked on Mac OS X 10.9.5.

(In reply to Jean-Yves Avenard [:jya] from comment #36)
> Being like 42 is exactly what we want as far as what system is used. 
> What you should see is that if h264 isn't supported you get either
> MSE/webm-vp9 or Flash. For now due to YouTube bug you will get flash. 
> 
> The difference with 42 is that on system where h264 isn't supported or if
> there's no hardware acceleration available (like you would have in a virtual
> machine or systems with broken drivers), you now have MSE/webm enabled.
> 
> When you tube fixes their configuration, we expect all the systems normally
> using flash to now use html5/MSE 
> 
> From your message, things appear to be as they should be: unless the user
> selected to force html5: you should be getting flash

Thanks for the clarification. Then based on your comment this 'hotfix' is verified.
> Then based on your comment this 'hotfix' is verified.
FYI, this wasn't an hotfix in the classical sense but a "classical" dot release.
Thanks for the verification
This has landed and is now in the 43.0.3 release. Marking as verified fixed.
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
(In reply to Jean-Yves Avenard [:jya] from comment #53)
> for references, here is the bug about mediasource-is-type-supported.html
> https://github.com/w3c/web-platform-tests/issues/2409

Thank you for your answers. 

Is there way to enable VP9 for web cams streaming on youtube (like https://www.youtube.com/watch?v=7ZgaM5J5xKU) for test purpose, because played for hours in HTML5 with h264 it leads to huge memory leak (fulfils all the virtual memory) and crashes FF (just FF, Chrome and Opera play nice).
(In reply to mikhail.rokhin from comment #54)

> Is there way to enable VP9 for web cams streaming on youtube (like
> https://www.youtube.com/watch?v=7ZgaM5J5xKU) for test purpose, because
> played for hours in HTML5 with h264 it leads to huge memory leak (fulfils
> all the virtual memory) and crashes FF (just FF, Chrome and Opera play nice).

When you open a proper bug and stop hijacking this one, I will answer your question :)
(In reply to Jean-Yves Avenard [:jya] from comment #55)
> (In reply to mikhail.rokhin from comment #54)
> 
> > Is there way to enable VP9 for web cams streaming on youtube (like
> > https://www.youtube.com/watch?v=7ZgaM5J5xKU) for test purpose, because
> > played for hours in HTML5 with h264 it leads to huge memory leak (fulfils
> > all the virtual memory) and crashes FF (just FF, Chrome and Opera play nice).
> 
> When you open a proper bug and stop hijacking this one, I will answer your
> question :)

Fine)) Here it is https://bugzilla.mozilla.org/show_bug.cgi?id=1235516
(In reply to PTO until Jan 5 - Chris Pearce (:cpearce) from comment #12)
> Created attachment 8701012 [details] [diff] [review]
> Patch: Hardcode YouTube.com override in C++
> 
> So it turns out the Firefox team disabled site-specific overrides in bug
> 896114 because processing the overrides took up about ~8.9% of page load
> time...
> 
> So we could hard-code the override for youtube in C++ in
> Navigator::GetUserAgent() to avoid any perf regression.
> 
> jya: does this work?

FWIW we see a lot of perf impact on mobile too, where overrides are still enabled, and are working on mitigating it via bug 1148544
Depends on: 1236030
It's very sad that you decided to lie about the User-Agent on requests to *.youtube.com and, what's worse, decided to roll this out in the middle of the holiday season (28th-29th of December).

FWIW, certain features of YouTube's site (enabled only to users in Europe) were broken because of this change. Fortunately, the change wasn't visible to YT users, but it caused us pain nonetheless.

Could you please refrain from selectively spoofing the User-Agent like this?

Also, what's the plan for removing this workaround? Have you tested FF 44, or are you waiting for a change on the YT's side, or is this hack going to make it into FF 44 in similarly haphazard fashion in a dot-release?
Please ensure you read the whole bug, particularly comments 26-28, where we asked if a fix could be put in and were told that it wasn't possible. As you state, the holiday season is busy for everyone, and we want our users to have the best possible experience. YT's broken UA sniffing affected users negatively and would not be addressed before this month, so action was taken to ensure people would get the best possible experience with YT.

Your comment and tone ignore the fact that people put the time in to identify the root cause and ask if a fix could be pushed. We were told it wasn't possible, and ensured that our eng contacts at YT were made aware of both the problem and the course of action to be taken if it wasn't possible. There was nothing haphazard about this, and we took pains to try and find other ways. As you say, it didn't affect users other than ensuring their experience was as optimal as possible, which was the entire point.

(In reply to adamwos from comment #58)
> It's very sad that you decided to lie about the User-Agent on requests to
> *.youtube.com and, what's worse, decided to roll this out in the middle of
> the holiday season (28th-29th of December).
> 
> FWIW, certain features of YouTube's site (enabled only to users in Europe)
> were broken because of this change. Fortunately, the change wasn't visible
> to YT users, but it caused us pain nonetheless.
> 
> Could you please refrain from selectively spoofing the User-Agent like this?
> 
> Also, what's the plan for removing this workaround? Have you tested FF 44,
> or are you waiting for a change on the YT's side, or is this hack going to
> make it into FF 44 in similarly haphazard fashion in a dot-release?
I'm sorry, there seems to be a misunderstanding here. What adamwos is saying is that a separate unrelated feature is now broken for many Firefox users in Europe on all OSs, not just XP and Linux. It is not immediately visible but it does cause additional annoyance for these users.
I have read the bug, but as I'm not a YouTube engineer, I don't really understand the technical details of the video codecs etc., or why YouTube is detecting things based on User-Agent with an upper bound. (It seems pretty weird that it falls back to something crappier for a browser that's "too new".) But that's not my complaint anyway.

My issue (and #60 is correct, that's what I was going after) is that another feature that I oversee, present also on YouTube, was broken because of the spoofing of User-Agent that sent values inconsistent between google.* and youtube.com. In case anyone from Mozilla is interested in the technical details, please feel free to reach out to me in private; I'm not going to post too many details on a public forum. The fact that we didn't brick YouTube entirely in a user-visible way for all Firefox 43 users in Europe is but a happy coincidence on our side.

My comment was meant to point out that this change had the potential to break stuff outside of its immediate area of influence (and in fact it did, just without user-visible effects), and I don't see anyone having considered these implications.
Also, I'd like to apologize for the tone of my original message. I've reread my comments and it is needlessly confrontational, and the tone probably doesn't fit this bugzilla; that wasn't my intention. I made my comments not as YouTube or Google in general, but as an engineer responsible for some common functionality that is also included in YouTube's site, and which was unfortunately broken by this change. I understand pretty well they might've been the only option deemed necessary at that time, and I do understand that YT folks were involved.

Just to clarify, my goals here are not to "find people responsible" or pick a fight. I wanted to point out for future benefit that such changes have a potential to break sites' functionality in unexpected ways and, if anyone is interested in the details on how, provide them.
Thanks Adam. And apologies from our end that we caused pain for you. We were caught between a rock and a hard place at an unfortunate time of the year and just had to make the best we could of the situation. We were aware of the risks but had to take them. We're eager to undo the UA changes, and can do so quickly, as soon as the underlying issue is fixed. I'm told that is actively worked on, being debugged right now, so hopefully we can undo this very very soon.

Thanks,
Johnny
(In reply to Adam Wos from comment #62)
> Just to clarify, my goals here are not to "find people responsible" or pick
> a fight. I wanted to point out for future benefit that such changes have a
> potential to break sites' functionality in unexpected ways and, if anyone is
> interested in the details on how, provide them.

FWIW I am the person responsible for the decision to spoof the UA. There are a number of scenarios where it isn't safe to assume that the same UA is presented across multiple domains. There are a number of things I would personally like to do in the future that would violate that assumption.
YouTube now works correctly for me (serves VP9 instead of 360p VP8) on Windows XP when I disable the 43's UA override. We will be pushing out the hotfix to disable the UA override very soon (in bug 1237209).
After updating on Windows XP Youtube main site and all Youtube embeds won't play html5. 
I had to reinstall flash to get youtube to work. 

It used to be no trouble html5 and 1080. Then Firefox 43.0.2 the html5 player stopped playing any HD content, now 43.0.4 html5 is no longer supported when using Firefox on Youtube.

Yea I know I should swap this old box, it's been primarily an old backup server as it has a bunch of shared hard drives and such, I've just been putting off upgrading as I need to swap the motherboard/cpu/ram and get a ssd and decide what os. 

Anyhow summary info: Firefox 43.0.4 / WinXP sp3, after update youtube no longer loads html5, had to reinstall flash to get youtube to work, but id rather not have flash on a xp box :P
Eric, you should be able to get HTML5 video again (using VP9) with Firefox 43 on XP if you set the about:config pref "media.youtube-ua.override" = false. A Firefox fix (that just changes that pref) will be released soon, but in the meantime you can set the pref manually.
(In reply to Chris Peterson [:cpeterson] from comment #68)
> Eric, you should be able to get HTML5 video again (using VP9) with Firefox
> 43 on XP if you set the about:config pref "media.youtube-ua.override" =
> false. A Firefox fix (that just changes that pref) will be released soon,
> but in the meantime you can set the pref manually.

Well it forced the player but hd content is extremely choppy

and I noticed now I've lost hardware acceleration it seems, I noticed I don't have hardware h264 anymore, which may be trouble. But wasn't prior to whatever changed the last couple versions.

Supports Hardware H264 Decoding	No; Failed to create H264 decoder

very strange how it all worked, are firefox profiles backwards compatible? 
would reinstalling the older version fix the issue on older xp?
(In reply to Eric from comment #69)
> and I noticed now I've lost hardware acceleration it seems, I noticed I
> don't have hardware h264 anymore, which may be trouble. But wasn't prior to
> whatever changed the last couple versions.

XP doesn't include an H.264 decoder, so Firefox on XP will either use Flash or VP9. But it sounds like you didn't have Flash installed before? Are you sure YouTube was serving HTML5 video with H.264?

Firefox does not support hardware decoding of VP9, so it's not surprisingly that VP9 would use more CPU than Flash and H.264.


> very strange how it all worked, are firefox profiles backwards compatible? 
> would reinstalling the older version fix the issue on older xp?

Yes, Firefox profiles are usually backwards compatible.
The browser used to have h.264 hardware acceleration in flash.
but it's now gone. I didn't know Firefox doesn't support vp9 hardware acceleration. The reason I thought it was "gone" is losing h.264 accel and both the html5 in youtube after using your about:config workaround and flash on vimeo are extremely choppy locking up the browser as it freezes unable to play hd. 
But vp9 and flash in hd in firefox is extremely choppy and freezes up the entire browser. couple seconds play then freeze, repeat, but drop down to 360/480 and fine. 

Playing h.264 in VLC smooth as silk, so I'm just confused, but again its no big deal as this thing OS is obsolete and it's mainly a curiosity what may have changed. 

I don't know if this is a similar issue to this loss of h264 accleration also "maybe" : https://bugzilla.mozilla.org/show_bug.cgi?id=1210519

I haven't done the test of blocking the cisco plugin from autoinstalling. But I never honestly double checked prior to 43.0.2 when everything was perfect.

Prior to 43.0.2 I didn't have any issues playing 1080p content on vimeo, dailymotion, youtube. 

But with 43.0.2 I submitted a bug about the html5 player no longer offered HD support at this that was linked here: https://bugzilla.mozilla.org/show_bug.cgi?id=1235293

Now after 43.0.4 and using your workaround I got html5 player back on youtube but HD locks up system every couple moments on vimeo/dailymotion and other sites video playback is really choppy.

I wasn't up to speed on vp9, that's why I thought it was accelerated as prior to the changes occured in 43.0.2 flash or whatnot I had zero performance issues. I'd stream live HD streams on this old box while gaming with them on the main box and such.

Anyhow I've tried various tricks to force h264 acceleration back in about:config but it didn't work.
I tried this trick from this past October: http://www.sevenforums.com/browsers-mail/382635-firefox-drives-you-nuts-because-h264-decoding-poor-read-here.html

but that didn't fix my problem. That's why I was thinking of reinstalling the firefox prior to the 43.0.2 version. mainly for occasional live stream watch while gaming on main pc. 

I uninstalled flash and reinstalled it and reset profile and imported my stuff back in. But unfortunately 

html5test.com shows
Codecs
MPEG-4 ASP support No 
H.264 support No

and in Firefox menu -> troubleshooting information
Supports Hardware H264 Decoding	No; Failed to create H264 decoder

while I guess that doesn't have anything to do with VP9 being choppy now all the sudden, but coincidentally flash videos and html5 vp9 are very choppy in hd and play a couple seconds and freeze and moving the mouse even the mouse freezes until i can hit the stop on player or close tab. 

Anyways thank you for your time, Im not expecting anything with XP, again, no big deal, I was just curious and it was a little frustrating that what worked without hitches and was smooth (even though i didn't know the details about vp9 but it played smooth at 1080p)now giving me a headache hehe.


Thanks again for the info,

-Eric

P.S.
According to Nvidia PureVideo information on the card in this old box. 
9800 gtx+
Core type: G92
PureVideo HD: VP2
VDPAU feature set: A
Supports complete acceleration for H.264 and partial acceleration for MPEG-1, MPEG-2, VC-1/WMV9

as you can see it's primarily a hard drive holder for backups, just occasional browsing when gaming on other pc.
(In reply to Anthony Jones (:kentuckyfriedtakahe, :k17e) from comment #64)
> (In reply to Adam Wos from comment #62)
> > Just to clarify, my goals here are not to "find people responsible" or pick
> > a fight. I wanted to point out for future benefit that such changes have a
> > potential to break sites' functionality in unexpected ways and, if anyone is
> > interested in the details on how, provide them.
> 
> FWIW I am the person responsible for the decision to spoof the UA. There are
> a number of scenarios where it isn't safe to assume that the same UA is
> presented across multiple domains. There are a number of things I would
> personally like to do in the future that would violate that assumption.

Anthony, hope you don't mind, I reached out to you privately to get more details on that, in order not to hijack this thread any more.
Eric, I filed bug 1237937 to track your VP9 performance problems on XP. We should move our discussion to that bug.
raised another Bug 1238077 as follow up from here. There should still be atleast some co-ordination or prioritization between YT/Google to Mozilla, if it impacts in big way. [Please close it, if folks at mozilla do not agree on there]
Did youtube corrected the bug ?
I still see all videos played as mp4/avc ...

firefox 43.0.4
media.mediasource.webm.enabled = true
it shows the html5 player and shows vp9 on the stats for nerds for me but it still broken as far as playback for me.

Dropped Frames: 1411/1922
lol

even 480p videos the browser nearly freezes up.
and seems acceleration was removed for flash, at least in another bug was mentioned. 
I don't know what happened.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: