Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

update from origin #8

Merged
merged 13 commits into from
Sep 1, 2021
Merged

update from origin #8

merged 13 commits into from
Sep 1, 2021

Conversation

Canta
Copy link
Owner

@Canta Canta commented Sep 1, 2021

No description provided.

joeyparrish and others added 13 commits July 29, 2021 13:54
This brings our default build config more in line with what is
necessary for some platforms anyway: using the system-installed
toolchain and sysroot to build everything.

We will no longer fetch source or binaries for any specific build
tools, such as libc++, clang, gold, binutils, or valgrind.

The main part of this change is the changing of default gyp settings
in gyp_packager.py.  For this, a bug in gyp_packager.py had to be
fixed, in which similar GYP_DEFINE key names (such as clang and
host_clang) would conflict, causing some defaults not to be installed
properly.

In order to enable clang=0 by default, some changes had to be made in
common.gypi:
  - compiler macros added to fix a compatibility issue between
    Chromium's base/mac/ folder and the actual OSX SDK
	- replaced clang_warning_flags variables with standard cflags
	  settings, plus xcode_settings for OSX
  - turned off warnings-as-errors for non-shaka code, rather than
		allow-listing specific warning types, since we can't actually fix
    those warnings on any platform
  - disabled two specific warnings in shaka code, both of which are
    caused by headers from our non-shaka dependencies

Also, one warning (missing "override" keyword) has been fixed in
vod_media_info_dump_muxer_listener.h.

Although these changes were done to make building simpler on a wider
array of platforms (arm64, for example), it seems to make the build a
bit faster, too.  For me, at least, on my main Linux workstation:
  - "gclient sync" now runs 20-30% faster
  - "ninja -C out/Release" now runs 5-13% faster

The following environment variables are no longer required:
  - DEPOT_TOOLS_WIN_TOOLCHAIN
  - MACOSX_DEPLOYMENT_TARGET
Documentation, Dockerfiles, and GitHub Actions workflows have been
updated to reflect this.

The following GYP_DEFINES are no longer required for anyone:
  - clang=0
  - host_clang=0
  - clang_xcode=1
  - use_allocator=none
  - use_experimental_allocator_shim=0
Documentation, Dockerfiles, and GitHub Actions workflows have been
updated to reflect this.

The following repos are no longer dependencies in gclient:
  - binutils
  - clang
  - gold
  - libc++
  - libc++abi
  - valgrind

The following gclient hooks have been removed:
  - clang
  - mac_toolchain
  - sysroot

Change-Id: Ie94ccbeec722ab73c291cb7df897d20761a09a70
This fixes the Debug build of libpng on arm64 by avoiding CPU-specific
optimizations that are not in our sources list.  The Release build
appears to have been unaffected, possibly due to link-time
optimizations or dead code stripping.

Change-Id: I900e00fe30b9f3748f2587cfea89a636b3a19811
This converts all time parameters to signed, finishing a cleanup that
was started in 2018 in b4256bf.  This changes the type of:
  - timestamps
    - PTS specifically
  - timestamp offsets
  - timescales
  - durations

This excludes:
  - MP4 box definitions
  - DTS specifically

This is meant to address signed/unsigned conversion issues on arm64
that caused some test cases to fail.

Change-Id: Ic752a20cbc6e31fea6bc0894d1771833171e7cbe
There is not a good reason to use a long-lived token attached to
shaka-bot.  Instead, use a short-lived, automatic token generated by
GitHub Actions for the workflow run.
We never produced static release executables on Linux before, but the dynamic libraries they depended on were universal enough that nobody noticed. Now that we have released v2.5 and switched to GitHub Actions for CI builds, the Linux executables depend on libatomic, which is causing issues for some users.

Although we can't create fully-static executables on macOS or Windows, we can at least do so on Linux.

This adds a GYP variable static_link_binaries which can be set to request full-static binaries on Linux. This also exposes the Chromium build variable disable_fatal_linker_warnings, which is necessary when static linking on Linux due to static-link-related warnings generated by libcurl for its use of getaddrinfo. Finally, this enforces the definition of __UCLIBC__ with static linking on Linux, which is the only way to disable malloc hooks in Chromium base. Those hooks cause linker failures when linking statically on Linux.

A new check has been added to the release workflow to ensure that the builds we create are statically linked on Linux.

Closes #965
When using CC=clang CXX=clang++, there is a binutils version check
that does not work correctly in common.gypi.  Since we are stuck with
a very old version of chromium/src/build, there is nothing to do but
patch it to remove the check.  Thankfully, this version number does
not control anything critical in the build settings as far as we can
tell.

Change-Id: Id749d97c5898917592f66136538ee0fa5ca78767
This will also allow us to create official arm64 builds starting with
our next release.

Change-Id: Iaca5e8406c5e28883346a7884eb0f30815ad0d19
This was causing failures on arm64, where the build action had an
arm-specific clause that was skipped due to the missing parameter.

Change-Id: I71b7fb15120855c444749dc2216b5f19f0561f6e
The newest pylint release complained about several issues that the
older release did not.  This resolves those issues:

 - removes unneeded "u" prefix from strings
 - adds "encoding" parameter for all open() calls
 - because "encoding" is a python3-only parameter, use python3 in all
   the scripts that we control

Unfortunately, python2 is required for any scripts that import modules
from the ancient Chromium build system we're using (referenced by
DEPS), as well as kokoro scripts.

Change-Id: I2e9f97af508efe58b5a71de21740e59b1528affd
# LL-DASH Support
These changes add support for LL-DASH streaming. 

**NOTE:** LL-HLS support is still in progress, but it's coming. :) 

## Testing
`./chunking_unittest --gtest_filter="ChunkingHandlerTest.LowLatencyDash"`

`./media_event_unittest --gtest_filter="MpdNotifyMuxerListenerTest.LowLatencyDash"`

`./mpd_unittest --gtest_filter="PeriodTest.LowLatencyDashMpdGetXml"`
`./mpd_unittest --gtest_filter="SimpleMpdNotifierTest.NotifyAvailabilityTimeOffset"`
`./mpd_unittest --gtest_filter="SimpleMpdNotifierTest.NotifySegmentDuration"`
`./mpd_unittest --gtest_filter="LowLatencySegmentTest.LowLatencySegmentTemplate"`

Note, packager_test must be run from the main project directory
`./out/Release/packager_test --gtest_filter="PackagerTest.LowLatencyDashEnabledAndUtcTimingNotSet"`
`./out/Release/packager_test --gtest_filter="PackagerTest.LowLatencyDashEnabledAndUtcTimingNotSet"`
The generate_version_string script was only producing correct results
in python 2, not python 3.  The gyp file that references it explicitly
runs it in python3.  The shebang line of the script has been updated
to match.  The script itself has been updated such that it now works
correctly in both python2 and python3.

Scripts that are only used as modules (not executed directly) have had
their shebang lines removed.

This fixes CI failures on GitHub Actions.

Change-Id: I309bafd2fb05e8fb33f5e092ead179c8c42ea5d3
Now that we have multiple architectures, we should factor both OS and
architecture into the names of release binaries.  This makes the names
more formulaic, as well as consistent with the static-ffmpeg-binaries
repository.  Shaka Streamer will pull binaries from both this repo and
that one, so consistent names would be helpful.

The pssh-box release is actually OS and architecture independent, so
remove the suffix from that and only release one copy of it.

Change-Id: Ief3de49fae267c5267647a8dd4377023777ead37
It was suggested in code review for another project that we update the
runner labels for clarity.  This brings Packager in line with that, so
that we are using the same labels across projects.

The runners have already been updated to register with the new label.

Change-Id: I30b22530225b5bd22b965ba98d276bcd74ade6cf
@Canta Canta merged commit b97e098 into Canta:master Sep 1, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants