Closed Bug 1513000 Opened 6 years ago Closed 5 years ago

Update to Openh264 plugin release v1.8.1

Categories

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

Product:
Core
Component:
WebRTC: Audio/Video
Version:
67 Branch
Type:
enhancement

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: dminor, Assigned: dminor)

References

(Blocks 3 open bugs)

Details

Attachments

(7 files, 2 obsolete files)

Bug 1513000 - Updates to mozharness openh264 scripts and configs; r=callek!
(deleted), text/x-phabricator-request
Details
Bug 1513000 - Add taskcluster configuration for building openh264 plugin; r=callek!
(deleted), text/x-phabricator-request
Details
Bug 1513000 - Add private/openh264/* artifact access scopes to Decision task for level1+ repos. r=tomprince
(deleted), text/x-phabricator-request
Details
Bug 1513000 - Sign openh264 binaries. r=tomprince
(deleted), text/x-phabricator-request
Details
Bug 1513000 - Create action to trigger Openh264. r=tomprince
(deleted), text/x-phabricator-request
Details
Bug 1513000 - expose revision as an attribute on the openh264 jobs. r=tomprince
(deleted), text/x-phabricator-request
Details
Bug 1513000: [openh264] Adjust `create_tasks` call in openh264 action for Bug 1528362; r?Callek
(deleted), text/x-phabricator-request
Details 
We want to update to v1.8.1 of the Openh264 plugin.
I'm marking this P1 for fixing in 66.
Rank: 9
Priority: -- → P1
I've built local copies of 1.8.1 for Linux, OS X and Windows. Linux and OS X are working fine with the testing I've done so far. Windows is not, but perhaps I'm not building it properly. I'll enable logging and investigate further.

Nick, will you be able to help out with this update?
Flags: needinfo?(nthomas)
I'm also not able to build a working copy of v1.7.1 on my Windows system, so I'm not going to worry about this too much for now. From looking at Bug 1284285 it looks like the usual process is for us to generate binaries, sign them, and then pass them to Cisco prior to getting WebRTC people involved in testing.
Dan, I'll redirect your request over to catlee for scheduling.

Last time we did this we updated the mozharness support for building OpenH264 but it's quite possible the world has shifted in the meantime. The Docs attachment on bug 1380605 details what was done, there are lots of manual steps there. Signing would certainly differ now, and it would be great if this was automated in taskcluster. The infrequent releases mean we haven't committed the time to do that. Are you interested in doing so ?
Flags: needinfo?(nthomas) → needinfo?(catlee)
Getting this fixed is a very high priority for us because it works around an issue where video coming from Safari freezes (Bug 1492038).

Unless there is someone available to start work on this right away, I think it makes sense for me to work on this. It will probably take me longer than someone familiar with the process and taskcluster, but on the other hand, I can get started this morning.
I have linux32 and linux64 builds working and I'm looking at macosx64 cross compiles next.
This is the try build where I'm seeing 403s trying to retrieve the OSX SDK: https://treeherder.mozilla.org/#/jobs?repo=try&revision=fbd9e9e7ca565bb9d919a4ce279c3f8983b9a441

I could also use help on uploading the artifacts in a way that they are only accessible to Mozilla employees.

Thanks!
dminor, callek, and myself met and discussed plan going forward. Given priority of this version we will not block on writing automation for this. Dan will look into trying to fix builds and callek will do some prep work next week over holidays. Assumption is we will roll this out at start of Jan once people are back from holidays and we have QA, signoffs, etc.

Plan on order:

Builds:
* linux* in working state
* macos hitting tooltool sdk download permission error. Dan will pass callek try link for help
* windows hitting build errors. Dan will look into more first
* build artifact permissions. callek will help make artifacts more private on try

Signing:
* this will be outside automation. callek to either work with secops for autograph or use old signing infra

Crash reporting:
* callek to look more into what we did for last openh264 version

Uploading:
* Dan to sync with cisco for how we want to upload builds once we have them


Publishing
* callek to create release blob
* dan to determine with nils how we want to roll this out. API is not changing so we could uplift this to release quickly. Probably want to test on nightlytest channel first.
* QA should sign-off before making live on release
* callek to update rules based on dan/nils rollout request

^ callek to update docs with goal of enlisting someone else from releng to do next version.
Flags: needinfo?(catlee)
(In reply to Dan Minor [:dminor] from comment #7)
> This is the try build where I'm seeing 403s trying to retrieve the OSX SDK:
> https://treeherder.mozilla.org/#/
> jobs?repo=try&revision=fbd9e9e7ca565bb9d919a4ce279c3f8983b9a441

So this job is trying to contact tooltool via the public endpoint, since you have the proxy enabled you should just do like https://dxr.mozilla.org/mozilla-central/source/testing/mozharness/configs/builds/build_pool_specifics.py#6 and specify the http:// path for it.
(In reply to Dan Minor [:dminor] from comment #7)
> I could also use help on uploading the artifacts in a way that they are only
> accessible to Mozilla employees.

As far as artifacts, if you store them in a (exposed to worker) location named `private/...` they will only be available to moco employees + NDA. https://docs.taskcluster.net/docs/manual/design/namespaces#artifacts

This should be fine, and can be done in task definition like:

```
  artifacts:
    public/logs:
      path: /builds/worker/logs/
      expires: '2019-01-18T13:47:19.996Z'
      type: directory
    public/build:
      path: /builds/worker/artifacts/
      expires: '2019-01-18T13:47:19.996Z'
      type: directory
    private/openh264:
       path: /builds/worker/private_artifacts/   # This can be whatever you want
       expires: 'whatever-datetime'
       type: directory
```

This allows any file/folder placed in the `path` you specify to be exposed via taskcluster artifacts under "private/openh264/..." -- Feel free to reach out if this is unclear to you.
Thank you for the suggestions. I'm now able to cross-compile with clang but not link, it looks like I will need to add a specialized Makefile for cross-compiling as it doesn't seem like we can pass in the correct options to the linker with the current setup.

After a long delay, I've started working on this again. I have builds for all platforms now.

I had a few oddities with win64 though. If I attempt to upload a directory as an artifact, I get an exception and no logs [1]. Uploading a file works fine [2]. There seems to be something that expects an artifact at public/build [3]. I worked around that last one by creating an empty directory there, but it seems weird. Any suggestions on these would be appreciated.

I had to make some modifications to the openh264 Makefiles to get clang on windows working, so I'll have to get those upstreamed. I also have a bunch of warnings that would be nice to fix. Upstream supports clang on Android, but support was added after 1.8.1, so we'll have to target a newer version, or get the support backported.

Next step would be to get the symbols available. Just to confirm, before I spend time on this, we do use those somewhere?

Thanks!

[1] https://treeherder.mozilla.org/#/jobs?repo=try&revision=be9bbce7a7a15a4c36fdf2668be676e358560dff&selectedJob=225465463
[2] https://treeherder.mozilla.org/#/jobs?repo=try&revision=434ca218c0f25c805147523a58b3dd5fc1b3fbc8&selectedJob=225502484
[3] https://treeherder.mozilla.org/#/jobs?repo=try&revision=c763d0e4688d33e0e5a07a025f9354a8ddda5dc2&selectedJob=225489870

Flags: needinfo?(bugspam.Callek)

(In reply to Dan Minor [:dminor] from comment #12)

I had a few oddities with win64 though. If I attempt to upload a directory as an artifact, I get an exception and no logs [1]. Uploading a file works fine [2]. There seems to be something that expects an artifact at public/build [3]. I worked around that last one by creating an empty directory there, but it seems weird. Any suggestions on these would be appreciated.

Leaving n-i so I can look into this part before I disperse myself (I'll have to look more on this part on monday)

Next step would be to get the symbols available. Just to confirm, before I spend time on this, we do use those somewhere?

I was previously asked to be sure I uploaded symbols to our symbol server for openh264, I suspect Socorro reports on them somehow. I don't have any further insight than that as I don't do crash analysis nor do I know which teams would have seen openh264 crash reports to tell us about them.

If I need to go digging in my old bugmail for further details I can, but that is what I know offhand.

(In reply to Dan Minor [:dminor] from comment #12)

After a long delay, I've started working on this again. I have builds for all platforms now.

I had a few oddities with win64 though. If I attempt to upload a directory as an artifact, I get an exception and no logs [1].

[1] https://treeherder.mozilla.org/#/jobs?repo=try&revision=be9bbce7a7a15a4c36fdf2668be676e358560dff&selectedJob=225465463

The log shows:

[taskcluster:error] &errors.errorString{s:"Rel: can't make build\\openh264\\artifacts relative to /build/openh264/artifacts"}
[taskcluster:error] Rel: can't make build\openh264\artifacts relative to /build/openh264/artifacts

This is due to the task payload declaring the following artifact:

    {
      "name": "private/openh264",
      "path": "/build/openh264/artifacts",
      "type": "directory"
    },

The path is relative to the task directory, so shouldn't have a leading / (i.e. I think you need "build/openh264/artifacts"). I think if you remove it, that should fix the problem.

Uploading a file works fine [2]. There seems to be something that expects an artifact at public/build [3]. I worked around that last one by creating an empty directory there, but it seems weird. Any suggestions on these would be appreciated.

[3] https://treeherder.mozilla.org/#/jobs?repo=try&revision=c763d0e4688d33e0e5a07a025f9354a8ddda5dc2&selectedJob=225489870

Similarly, there is an artifact declared in the task payload:

    {
      "name": "public/build",
      "path": "public/build",
      "type": "directory"
    }

This tells the worker that it should find a directory there for uploading. If you remove this from task definition, that should solve the problem.

Thanks for looking pete!

Flags: needinfo?(bugspam.Callek)

Hi Pete,

Thank you for having a look! Removing the forward slash from my artifact path did fix things for using a directory, strange that it worked for a file.

The "public/build" artifact is not a part of my kind.yml file [1], it must be coming from somewhere else, but I can work around that.

[1] https://hg.mozilla.org/try/file/434ca218c0f2/taskcluster/ci/openh264-plugin/kind.yml

Try run here: https://treeherder.mozilla.org/#/jobs?repo=try&revision=762348d38f37cbb2079af16dd008a8c48796f8c7

It turns out that all builds look for "public/build", but it's only an error on windows. I'll just create an empty directory for that.

I'm waiting on an upstream pull request: https://github.com/cisco/openh264/pull/3095. Once that lands, we'll have to decide whether we want to ask for a backport the Android clang support to 1.8.1 or maintain the differences (just one Makefile) as a local patch.

I've done some limited testing of the plugins built on treeherder on my Linux and Windows systems and they look good so far.

I discussed it with Nils yesterday and we don't want to delay this any further. I've produced a backport of the required patch and my pull request and updated kind.yml to point to that for the Android builds. I've forked it to github.com/dminor/openh264. If that's a concern, we can probably move it to the mozilla organization without too much trouble.

Try run here: https://treeherder.mozilla.org/#/jobs?repo=try&revision=ae1dfc36a29f85c263f2a557736b45abb01159b6

I've disabled running the gtests. The tests won't run on the Linux builders due to a glibc mismatch, won't run on Windows without getting git added to the build machines, OS X is now a cross-compile and we never ran them on Android anyway. We do local testing of the builds anyway, so I don't think this is a huge concern.

Depends on D19817

Pushed by dminor@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/ddb817eed3bc
Updates to mozharness openh264 scripts and configs; r=callek
https://hg.mozilla.org/integration/mozilla-inbound/rev/471db22054e7
Add taskcluster configuration for building openh264 plugin; r=callek
Keywords: leave-open

when we can get the new FF with openh264 1.8.1?

(In reply to Elliot from comment #27)

when we can get the new FF with openh264 1.8.1?

The best answer I can give at this time is "soon" we're pretty close to being able to finalize what is needed here, there will be some Quality Assurance steps to make sure nothing is wrong of course along the way.

which nightly build I can test? I want to make sure Webex webapp can work normally. thanks.

Attachment #9047540 - Attachment is obsolete: true
Pushed by jwood@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/9ce8f26f311b
expose revision as an attribute on the openh264 jobs. r=tomprince
https://hg.mozilla.org/integration/autoland/rev/81a50b35b482
Sign openh264 binaries. r=tomprince
https://hg.mozilla.org/integration/autoland/rev/26021d8ebb27
Create action to trigger Openh264. r=tomprince
Pushed by mozilla@hocat.ca:
https://hg.mozilla.org/integration/autoland/rev/a88b39ffb1f1
[openh264] Adjust `create_tasks` call in openh264 action for Bug 1528362; r=Callek

https://hg.mozilla.org/mozilla-central/rev/a88b39ffb1f1

Debugging Symbols are on our server now, for all platforms as of this writing.

Status Update: Binaries all sent over for hosting, there seems to be some issues (internally) with Android, which may prompt a new build. We plan to ship the desktop versions as-is at this time. Once we are able to serve them to users we'll update this bug so that interested people can follow along.

Is there any plan to tag v1.8.1 for those who build the plugin from source?

(In reply to Elliot from comment #29)

which nightly build I can test? I want to make sure Webex webapp can work normally. thanks.

Hi Elliot, this is now available on the 'nightlytest' update channel. You need to edit the channel-prefs.js file in your Firefox installation and change the value there to be 'nightlytest'. If you already have a copy of the openh264 plugin, you will want to remove the 'media.gmp-manager.lastCheck' pref in about:config to force it to do check for updates. Otherwise, I think it only checks for updates once a day. Please let us know if you run into any problems.

Flags: needinfo?(aisnote)
Depends on: 1533001

(In reply to Dan Minor [:dminor] from comment #41)

(In reply to Elliot from comment #29)

which nightly build I can test? I want to make sure Webex webapp can work normally. thanks.

Hi Elliot, this is now available on the 'nightlytest' update channel. You need to edit the channel-prefs.js file in your Firefox installation and change the value there to be 'nightlytest'. If you already have a copy of the openh264 plugin, you will want to remove the 'media.gmp-manager.lastCheck' pref in about:config to force it to do check for updates. Otherwise, I think it only checks for updates once a day. Please let us know if you run into any problems.

still not get the 1.8.1 plugin as I followed your steps.

Flags: needinfo?(aisnote)

(In reply to Elliot from comment #42)

(In reply to Dan Minor [:dminor] from comment #41)

(In reply to Elliot from comment #29)

which nightly build I can test? I want to make sure Webex webapp can work normally. thanks.

Hi Elliot, this is now available on the 'nightlytest' update channel. You need to edit the channel-prefs.js file in your Firefox installation and change the value there to be 'nightlytest'. If you already have a copy of the openh264 plugin, you will want to remove the 'media.gmp-manager.lastCheck' pref in about:config to force it to do check for updates. Otherwise, I think it only checks for updates once a day. Please let us know if you run into any problems.

still not get the 1.8.1 plugin as I followed your steps.

You should do the following:

  • Exit Firefox completely
  • Change the .js file that holds the update prefs (in the application folder, not profile) for app.update.channel to be 'nightlytest' instead of 'nightly' and save this file
  • Launch firefox
  • delete 'media.gmp-manager.lastCheck' preference in about:config
  • (maybe restart firefox, not sure how often we would check for openh264 otherwise)

and you should get 1.8.1, if you are on Desktop. If you do not and still end up with 1.7.1 I'd like to know what OS you are on and some more details so I can try to track down why.

Flags: needinfo?(aisnote)

This was just rolled out to Nightly users, and will remain Nightly Only for now. Android is not updated yet.

For all platforms, Firefox 67 and later will have 1.8.1. I'm going to call this done.

Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Keywords: leave-open
Resolution: --- → FIXED
Version: 63 Branch → 67 Branch

Hello, i dunno if this is the right place but would it be possible to update to 2.0.0 https://github.com/cisco/openh264/commit/5f76764444393f333b6a6e3d64f72ee454b3f612

Greg, the major change in 2.0.0 is the B-Frame support. It's rarely used in RTC, so the Cisco Openh264 team didn't ask Firefox to pick up this release.

(In reply to Hank Peng from comment #47)

Greg, the major change in 2.0.0 is the B-Frame support. It's rarely used in RTC, so the Cisco Openh264 team didn't ask Firefox to pick up this release.

ok.

Flags: needinfo?(aisnote)

2.1.0 has been released: https://github.com/cisco/openh264/commit/032f97db96827f9c4c183de5bc3794fce7b76bf6

And now the release notes:

v2.1.0

  • Experimentally support for multi-thread decoding(default disabled,and may result in random problems if enabled)
  • Assembly optimization for loongson platform
  • Update meson version to 5
  • Some minor bug fixes

Considering 2.0.0 was out since last July and skipped over for current FF, maybe about time and in time for 76?

(In reply to Arthur K. from comment #50)

And now the release notes:

v2.1.0

  • Experimentally support for multi-thread decoding(default disabled,and may result in random problems if enabled)
  • Assembly optimization for loongson platform
  • Update meson version to 5
  • Some minor bug fixes

Considering 2.0.0 was out since last July and skipped over for current FF, maybe about time and in time for 76?

I've filed Bug 1619988 for this.

Blocks: openh264-2_3_2
Blocks: WebRTC-OpenH264
Attachment #9044716 - Attachment is obsolete: true
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: