Closed Bug 1597216 Opened 5 years ago Closed 5 years ago

createMediaElementSource(), mozCaptureStream() or setSinkId() for a media element displayed through picture-in-picture will stall the pip-player's video

Categories

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

defect

Tracking

()

RESOLVED FIXED
mozilla72
Tracking Status
firefox71 --- wontfix
firefox72 --- fixed

People

(Reporter: pehrsons, Assigned: pehrsons)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

Looking at the code for how picture-in-picture hooks into the VideoSink, using any of the methods mentioned in the title, will stall the pip-player's video, because they all cause the MediaDecoderStateMachine to create a new MediaSink, and that seems like a case that's not covered.

Found while looking at bug 1596777.

This only affects picture-in-picture really. Mike, can you triage this?

I can try to provide a fix.

Flags: needinfo?(mconley)

Thanks for filing!

Blocks: videopip
Flags: needinfo?(mconley)
Priority: -- → P3

Actually, I'm not the triage owner for this component - so I'm resetting the priority to let the triage owner or their team set the priority.

Priority: P3 → --
Priority: -- → P3

(In reply to Mike Conley (:mconley) (:⚙️) (Wayyyy behind on needinfos) from comment #3)

Actually, I'm not the triage owner for this component - so I'm resetting the priority to let the triage owner or their team set the priority.

Well I mean, I am part of the triage team for this component, but seeing that this only impacts your feature, I'd like your input on the priority. The buggy code here exists for the sole purpose of supporting picture-in-picture.

The buggy code here exists for the sole purpose of supporting picture-in-picture.

Fair, it just felt rather presumptuous of me to set the priority in someone else's component.

I think P3 makes sense.

Blocks: 1521964

Does it affect 71? (we ship pip on windows in 71)

Flags: needinfo?(apehrson)

From what I can tell, yes this affects 71 - but I suspect the occurrence of this bug in the wild will likely be infrequent (I don't believe any of the major sites we're targeting like YouTube, Netflix, Amazon Prime or Twitch use these APIs).

(In reply to Mike Conley (:mconley) (:⚙️) (Wayyyy behind on needinfos) from comment #8)

From what I can tell, yes this affects 71 - but I suspect the occurrence of this bug in the wild will likely be infrequent (I don't believe any of the major sites we're targeting like YouTube, Netflix, Amazon Prime or Twitch use these APIs).

I agree with this. I'm not aware of a large video site using any of these APIs.

Flags: needinfo?(apehrson)
Assignee: nobody → apehrson
Status: NEW → ASSIGNED
Pushed by pehrsons@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/01d2c84810f0
Handle changes to mMediaSink in MediaDecoderStateMachine. r=alwu
Backout by dvarga@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/e01020298260
Backed out 7 changesets (bug 1597216, bug 1596777, bug 1536156) for reftest failures at reftest/bipbop_300_215kbps.mp4.lastframe.htm. On a CLOSED TREE
Flags: needinfo?(apehrson)
Pushed by pehrsons@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/5e146778e544
Handle changes to mMediaSink in MediaDecoderStateMachine. r=alwu
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla72
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: