Skip to content

Commit

Permalink
automate: enable proprietary_codecs
Browse files Browse the repository at this point in the history
  • Loading branch information
@jakogut
jakogut committed Apr 5, 2018
1 parent 30c5739 commit a049315
Showing 1 changed file with 3 additions and 2 deletions.
5 changes: 3 additions & 2 deletions tools/automate.py
View file
Original file line number Diff line number Diff line change
Expand Up @@ -870,8 +870,9 @@ def getenv():
# GN configuration
env["CEF_USE_GN"] = "1"
# Issue #73 patch applied here with "use_allocator=none"
env["GN_DEFINES"] = "use_sysroot=true use_allocator=none symbol_level=0 use_jumbo_build=true"
env["GN_DEFINES"] += " use_gtk3=true use_cups=false use_gnome_keyring=false use_vaapi=true"
env["GN_DEFINES"] = "use_sysroot=false use_allocator=none symbol_level=0 use_jumbo_build=true"
env["GN_DEFINES"] += " use_vaapi=true proprietary_codecs=true"
env["GN_DEFINES"] += " use_gtk3=true use_cups=false use_gnome_keyring=false"
env["GN_DEFINES"] += " enable_reporting=false enable_remoting=false enable_nacl=false"
# To perform an official build set GYP_DEFINES=buildtype=Official.
# This will disable debugging code and enable additional link-time
Expand Down

14 comments on commit a049315

@cztomczak
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jakogut Just FYI: use_jumbo_build=true is a developer productivity feature that doesn't seem stable and should not be used for production releases.

@cztomczak
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jakogut Why isn't VA-API enabled by default, is this because it is not stable? Or is it only acceleration for proprietary codecs?

@jakogut
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@cztomczak VAAPI is only enabled for Intel hardware on ChromeOS. This includes free codecs such as VP9, if the hardware supports it.

To my knowledge, the reasoning is that Google can't guarantee stability on all of the hardware and software combinations that support VAAPI, so it's disabled by default on Linux, and has to be patched in. You can find that patch in this same repo, it's based off the VAAPI patch from this repo: https://github.com/gcarq/inox-patchset

@cztomczak
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jakogut Thanks. I've also found this patch in Arch Linux [1]. I guess they are the same.

[1] https://aur.archlinux.org/cgit/aur.git/tree/chromium-vaapi-r18.patch?h=chromium-vaapi

@jakogut
Copy link
Contributor Author

@jakogut jakogut commented on a049315 May 23, 2018 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, that's also where I originally found the patch. It works pretty well, though so far, I've only tested on Intel hardware.

It's worth noting that on all but the newest Intel hardware, VP9 and H265/HEVC are not hardware accelerated. I use a heavily modified version of the Chrome extension h264ify to force video content to be served using codecs that my hardware supports.

You can find what codecs your hardware supports with vainfo.

@cztomczak
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jakogut Thanks!

@cztomczak
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jakogut Does setting symbol_level=0 speeds up build significantly?

@jakogut
Copy link
Contributor Author

@jakogut jakogut commented on a049315 Sep 9, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@cztomczak I haven't compared build times with and without, but I enable it for smaller binaries. The Chromium documentation [1] says that it does cut down build times.

[1] https://www.chromium.org/developers/gn-build-configuration

@cztomczak
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jakogut Thanks. I will be doing improvements to build times via Issue #470. You might want to apply a recent commit aec9f62 that increased the default ninja jobs and it will make builds faster.

@jakogut
Copy link
Contributor Author

@jakogut jakogut commented on a049315 Sep 9, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@cztomczak I generally just specify --ninja-jobs when I build.

Also, I nearly have an arm build of cefpython working, so you might see some pull requests at some point related to that. I'd like to get away from maintaining my own fork and features separately.

@cztomczak
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jakogut Support for ARM builds would be cool. Note that cefpython is still at v66, so you're ahead.

@jakogut
Copy link
Contributor Author

@jakogut jakogut commented on a049315 Sep 10, 2018 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@cztomczak I successfully built an armv7l wheel [1] (python 3.{6,7} only) last night, using a lot of manual steps, but it seems to work. I haven't actually been able to run my application yet because of unrelated graphics driver issues.

Also, I compiled CEF on an x86_64 machine to save time, then copied the distribution to an armv7l machine where cefpython3 was built without having to worry about configuring a cross-compiler. This would ideally all be done on the same machine, but will take more work to automate.

EDIT: Also, I've been maintaining my own fork because I have no interest in Windows or macOS support. Is there any way I can contribute my CEF updates back to you, or are they not usable without multi-platform support and testing?

[1] https://github.com/jakogut/cefpython/releases/tag/69.0-armv7l

@cztomczak
Copy link
Owner

@cztomczak cztomczak commented on a049315 Sep 10, 2018 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jakogut Great progress. Feel free to make updates in Issue #267 ("ARM support"), so others can find this and test as well.

Regarding contributing back. If it's about exposing new APIs it doesn't need to be tested on all platforms (in most cases). Support for new features in tools also shouldn't be a problem. ARM support is welcome as well. But when it's about updating CEF version, that is a more complex task that I would prefer to do myself. If I accept CEF update then I need to support it and that can be time consuming since there are many examples, python versions and platforms to support. I look forward for a long term sponsorship, so I could devote more time to this project.

@jakogut
Copy link
Contributor Author

@jakogut jakogut commented on a049315 Sep 10, 2018 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's an experimental armv7l build available here: https://github.com/jakogut/cefpython/releases/tag/69.0-armv7l

Swiftshader and v8 snapshots must be disabled with the GN options use_swiftshader=false v8_use_snapshot=false.

Compiling requires a lot of manual steps, including building CEF using automate.py with the --arm-build flag, copying the resulting distrib from build/chromium/src/cef/binary_distrib/cef_binary_*_linuxarm/to an armv7l system, editing out x86 specific options such as -msse2 and -m32 from cmake/cef_variables.cmake, replacing the relevant OS_POSTFIX* variables in tools/common.pywith linuxarm and building as normal with build_distrib.py.

The resulting wheel must then be renamed so that the platform is linux_armv7l, instead of linux-armv7l before installing.

Please sign in to comment.