Open Bug 1462786 Opened 6 years ago Updated 4 years ago

Use the real OpenH264 plugin for mochitest

Categories

(Core :: WebRTC: Audio/Video, enhancement, P3)

enhancement

Tracking

()

People

(Reporter: drno, Unassigned)

References

Details

The fake plugin currently used for making WebRTC calls in mochitest is repeatedly causing pain.

We should use the real OpenH264 plugin instead for our automated tests. Since Firefox normally downloads the plugin > 1min after it got started and stores it in the user profile directory we need to download the plugin before Firefox gets started for the mochitests.

The current proposal is to download the plugin from the Cisco CDN and put a copy into Mozilla's own internal, protected CDN and then have a script download the plugin from that CDN before each test execution.
Stuart is the Mozilla internal CDN reachable only for/from test machines?
If so we might have to differentiate between running in the test network (download from Mozilla internal test CDN) and running on a developers machines (download from the Cisco CDN on the public internet).
Flags: needinfo?(sphilp)
I'm not sure myself, Kendall are you able to answer those questions related to CDN and work with Joel to figure this out (he's back Monday)?
Flags: needinfo?(sphilp) → needinfo?(klibby)
TBH, I'm not sure what you mean by "Mozilla's own internal, protected CDN." What's the address of that endpoint? We've got private HTTPS endpoints for pulling down things needed by tests, so I'm sure we can make it happen, but I'll start with trying to get a clearer picture. CC on :catlee and :coop, too; they'll have a good idea of our options and would be the people I go to next.
Flags: needinfo?(klibby)
When I was speaking with :drno earlier, I was referring to tooltool (the "internal, protected CDN") as a possible option to store the plugin and fetch from automation.
Assignee: nobody → dminor
Status: NEW → ASSIGNED
(In reply to Nils Ohlmeier [:drno] from comment #1)
> Stuart is the Mozilla internal CDN reachable only for/from test machines?
> If so we might have to differentiate between running in the test network
> (download from Mozilla internal test CDN) and running on a developers
> machines (download from the Cisco CDN on the public internet).

It looks like tooltool offers public or private visibility [1]. Public would be ideal as we could then use one url regardless of whether or not we were running in automation. I didn't see anything in the Cisco license that made it sound like we couldn't redistribute their binary, as long as it was not packaged with an end user application. :drno, what do you think?

I have a try run here [2] for linux64 with passing mochitests which grabbed the plugin directly from Cisco. I'm trying a push with more platforms at the moment.

[1] https://wiki.mozilla.org/ReleaseEngineering/Applications/Tooltool#How_To_Upload_To_Tooltool
[2] https://treeherder.mozilla.org/#/jobs?repo=try&revision=25741626397abebfca3de4d9097e0e91e62d9c6d
Flags: needinfo?(drno)
Full try run here: https://treeherder.mozilla.org/#/jobs?repo=try&revision=08def410c92695725618e6b03b842a178a4a7a4c

Some of these seem to correspond to known intermittents, but I'm also seeing
PROCESS-CRASH | Main app process exited normally | application crashed [@ mozilla::gmp::GMPChild::ProcessingError(mozilla::ipc::HasResultCodes::Result, char const*)]

in some of the logs. I'll investigate further.
Discussed this with :drno, and it looks like we'll fix up the fake h.264 plugin for the branch 64 landing, and switch to the real one at a later date.
Status: ASSIGNED → NEW
Assignee: dminor → nobody
(In reply to Dan Minor [:dminor] from comment #5)
> (In reply to Nils Ohlmeier [:drno] from comment #1)
> > Stuart is the Mozilla internal CDN reachable only for/from test machines?
> > If so we might have to differentiate between running in the test network
> > (download from Mozilla internal test CDN) and running on a developers
> > machines (download from the Cisco CDN on the public internet).
> 
> It looks like tooltool offers public or private visibility [1]. Public would
> be ideal as we could then use one url regardless of whether or not we were
> running in automation. I didn't see anything in the Cisco license that made
> it sound like we couldn't redistribute their binary, as long as it was not
> packaged with an end user application. :drno, what do you think?

I fear that if Mozilla would offer a link to download the plugin we would become the distributor of the plugin.

I'll double check with legal how to handle this.
Flags: needinfo?(drno)
Assignee: nobody → dminor
See Also: → 1509012
I'm not planning to do anything with this until after we get an updated version of openh264 to workaround Bug 1492038.
Depends on: 1492038
Depends on: 1513000
No longer depends on: 1492038
Blocks: 1532576
No longer blocks: 1532576

I'm not going to get to this anytime soon.

Assignee: dminor → nobody
Severity: normal → S3
Priority: P2 → P3
You need to log in before you can comment on or make changes to this bug.