Closed Bug 1166394 Opened 10 years ago Closed 10 years ago

YouTube (HTML5) portrait video not playing in nightly on OS X (recent regression)

Categories

(Core :: Audio/Video, defect)

Product:
Core
Component:
Audio/Video
Version:
41 Branch
Platform:
x86_64
macOS
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
VERIFIED FIXED
Tracking Flags:
Tracking Status
firefox41 + verified

People

(Reporter: milan, Unassigned)

References

Details

(Keywords: regression)

I imagine this is already reported and known, but I can't find the bug, so I'll just add one anyway. Attempting to play https://www.youtube.com/watch?v=3UA9jaCOiTY&feature=youtu.be on nightly just leaves me with a black video. Mouse over the timeline and the thumbnail preview is correct, but the main video is black. OK on dev edition 40. Dimension dependent. When it fails to play properly, the dimension is 854x480 *2, resolution 270x480@30 (at the end.) During playing, the dimension is 270x480 *2. If I resize the window to get the dimension down to 203x360 *2, it plays fine. No special prefs. 15" Retina MacBook Pro, 10.9.5, early 2013. Central regression range: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=35918b0441b4&tochange=4fb7ff694bf5 Inbound regression range: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=8aa33b2cd1b1&tochange=d9b6cc4ce4cc
Blocks: 1164480
Flags: needinfo?(smichaud)
Flags: needinfo?(ajones)
I have *no* idea how my patch could have done this ... but it seems that it did. I'll back it out and later try to figure out why.
Flags: needinfo?(smichaud)
Fixed by backing out my patch for bug 1164480.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Flags: needinfo?(ajones)
Could it be that the actual CFSTR for that key is different depending on the platform? The incorrect key would explain this behaviour. The IOSurface generated by the hardware decoder must be made global in order to work with e10s, otherwise you'll get black frames as the other process can't access the content of the IOSurface.
I currently suspect it's something a lot more stupid -- I suspect that where my first patch put a CFStringRef, I need to put a CFStringRef*. I'll try that tomorrow. At least I know how to test :-)
> At least I know how to test :-) At least now I know how to test :-)
Did the backout make today's Nightly? I'm still seeing this bug with Firefox 41.0a1 20150520030205.
(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #9) > Did the backout make today's Nightly? I'm still seeing this bug with Firefox > 41.0a1 20150520030205. No the backout didn't land in m-c until 6am this morning.
Tracking enabled for 41, to make sure this gets fixed.
tracking-firefox41: --- → +
Anthony, could you please confirm whether this bug is fixed in the latest nightly or not? If this bug is still repro on nightly, please revert status-firefox41 from "Fixed" to "Affected".
status-firefox41: affected → fixed
It certainly is still fixed for me.
Firefox 41.0a1 20150520030205 reproduces this bug. Firefox 41.0a1 20150618030206 does not reproduce this bug.
Status: RESOLVED → VERIFIED
status-firefox41: fixed → verified
Flags: needinfo?(anthony.s.hughes)
You need to log in before you can comment on or make changes to this bug.