Closed Bug 1386033 Opened 7 years ago Closed 5 years ago

HTMLMediaElement::CaptureStream() breaks video playback

Categories

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

defect

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: bryce, Unassigned)

References

Details

Attachments

(1 file)

Calling CaptureStream on a video element may result in the playback of the video breaking. I see this manifesting as playback freezing. The video does not report being suspended or paused, and logging shows the MediaDecoder continuing to move the same 2 frames to the video sink. I can seek the video, seeing the new frame at the location I seek to, however playback will not advance after the seek. Note, this does not happen for all videos. Proof of concept attached using on of the test videos in central.
Looks like this particular video may be aberrant in some way. I had thought that it may be videos lacking audio, but testing with seek.webm from the same test directory does not reproduce the issue. Other mp4s without audio work also. As a trap for new players, bug 1183510 means that if you test this with a video with audio you won't hear the audio.

The issue appears to be, at least in part, in the VideoSink[1]. In the failure case the clockTime is not advanced and the video stalls. When the element is being captured the mAudioSink is a DecodedStream, while when no capture is used mAudioSink is a AudioSinkWrapper -- these have different code for the GetPosition call. That said, for other media I've tested with, time is advancing even with a DecodedStream, so I suspect there's something else going on here.

[1]: https://searchfox.org/mozilla-central/source/dom/media/mediasink/VideoSink.cpp#436

Works fine for me now. I'm going to assume it's been overtaken by events.

Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: