Closed Bug 859195 Opened 11 years ago Closed 11 years ago

canplaythrough event fails to fire on media elements derived from remote streams when applying patch bug 831789 and running the basic peer connection smoke tests

Categories

(Core :: WebRTC: Audio/Video, defect)

defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: jsmith, Unassigned)

Details

(Whiteboard: [WebRTC][blocking-webrtc-][qa-automation-blocked])

Attachments

(1 file)

After doing lots of creative approaches on bug 831789, I've hit a wall on trying to get those tests running - the canplaythrough event appears to be failing to fire on the media elements derived from remote Media Streams given from the onaddstream callback with that patch. In theory, I believe that patch should work - upon calling setRemoteDescription with a stream already added, we should get an onaddstream callback eventually with a valid stream that generates media flow. However, what I'm actually seeing appears to be the media stream I'm getting from onaddstream is "broken" - applying the stream to a media element and trying to play it shows that I'm not getting any canplaythrough events fired.

If this ends up being a bug in the test that I'm not seeing, then feel free to close this bug as invalid and explain why.
Blocks: 831789
Roc, this blocks some important test automation work for webrtc.  Can you assess what's likely going on and how hard it would be to fix?

Any logs Jason could get for you that would make this easier?  Or help solving it?
Flags: needinfo?(roc)
Whiteboard: [WebRTC][blocking-webrtc-]
Have you called play() on the element? Currently we won't call canPlayThrough() until playback actually starts.
Flags: needinfo?(roc)
(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #2)
> Have you called play() on the element? Currently we won't call
> canPlayThrough() until playback actually starts.

Yup.

https://mxr.mozilla.org/mozilla-central/source/dom/media/tests/mochitest/mediaStreamPlayback.js#137

Where the media element is generated through:

https://mxr.mozilla.org/mozilla-central/source/dom/media/tests/mochitest/head.js#69

And the stream is generated from an onaddstream callback.
When I go to http://mozilla.github.io/webrtc-landing/pc_test.html and add a canplaythrough handler on pc2video, it does get fired.

Got a reduced testcase for this?
Keywords: testcase-wanted
Hmm...so interestingly enough, running this through the web works fine - I'm seeing canplaythrough fire respectively on each media element derived from a remote stream in this test case I just attached.
Given that Henrik just hit a very similar issue, I think this might be a test framework bug, not a bug in gecko.

I'm going to close this and when Henrik or I figures out the event handler issue here, we'll open a new bug to track the work to resolve the event handling problem.
No longer blocks: 831789
Keywords: testcase-wanted
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → INVALID
Talking with whimboo, now I'm rethinking this is a bug in mochitest after his investigation he conducted - it actually revealed an actual bug. He thinks we should hold off retrying anything until the media stream tracks landed, cause he thinks something could change here.

But strangely enough, an end to end test is his investigation never revealed the bug. It only happened in mochitest. So I'm going to work on getting a reduced test case in the context of mochitest then.
Status: RESOLVED → REOPENED
Keywords: testcase-wanted
Resolution: INVALID → ---
(In reply to Jason Smith [:jsmith] from comment #8)
> Talking with whimboo, now I'm rethinking this is a bug in mochitest after
> his investigation he conducted - it actually revealed an actual bug. He
> thinks we should hold off retrying anything until the media stream tracks
> landed, cause he thinks something could change here.

Meant to say - actual bug in core gecko, not mochitest or the framework.
Blocks: 831789
At this point, I've exhausted all efforts to get a reduced test case outside of the patch in bug 831789 and potentially a slight reduction of it. But I'm generally noticing the canplaythrough & timeupdate events are running into trouble firing when being analyzed as part of the command framework.

Eric - You mentioned you would be interested in helping debug this. Could you try running the mochitests with the patch in bug 831789 and seeing what the debugger is saying that might be causing the problem?
Flags: needinfo?(ekr)
Keywords: testcase-wanted
Whiteboard: [WebRTC][blocking-webrtc-] → [WebRTC][blocking-webrtc-][qa-automation-blocked]
Per talking with Eric, this is confirmed to be invalid. Media flow only starts happening after the handshake is established, not midway.
No longer blocks: 831789
Status: REOPENED → RESOLVED
Closed: 11 years ago11 years ago
Flags: needinfo?(ekr)
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: