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 (deleted) —
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.
(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) (deleted) — — 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)
Attached patch Patch: Hardcode YouTube.com override in C++ (obsolete) (deleted) — — Splinter Review
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) (deleted) — — 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?
Attached patch Patch: Override userAgent to masquerade Firefox 43 as 44. (obsolete) (deleted) — — Splinter Review
* 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.
Attached patch Patch: Override userAgent to masquerade Firefox 43 as 42. (obsolete) (deleted) — — Splinter Review
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+
Attached patch Patch: Override userAgent to masquerade Firefox 43 as 42. (obsolete) (deleted) — — Splinter 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: