It turns out that workflows were the wrong way to abstract reusable
pieces of work. This turns common steps into custom actions (build
docs, build packager, test packager) which can be used as encapsulated
steps in multiple workflows.
This is a much more natural way to avoid duplication compared to the
previous approach of triggering one workflow from another. This also
has the benefit of all of the steps of a release being represented on
GitHub as a single workflow, making it easier to understand what is
happening and what event triggered those steps.
Change-Id: Ife156d60069a39594c7b3bb3bc32080e6453b544
This replaces Travis (for Linux & Mac) and Appveyor (for Windows) with
GitHub Actions. In addition to using GitHub Actions to test PRs, this
also expands the automation of releases so that the only manual steps
are:
1. Create a new CHANGELOG.md entry
2. Create a release tag
Workflows have been create for building and testing PRs and releases,
for publishing releases to GitHub, NPM, and Docker Hub, and for
updating documentation on GitHub Pages.
When a new PR is created, GitHub Actions will:
- Build and test on all combinations of OS, release type, and library
type
Appveyor's workflow took ~2 hours, whereas the new GitHub Actions
workflow takes ~30 minutes.
When a new release tag is created, GitHub Actions will:
- Create a draft release on GitHub
- Extract release notes from CHANGELOG.md & attach them to the
draft release
- Build and test on all combinations of OS, release type, and library
type, aborting if any build or test fails
- Attach release artifacts to the draft release, aborting if any
one artifact can't be prepared
- Fully publish the draft release on GitHub
- Publish the same release to NPM (triggered by GitHub release)
- Publish the same release to Docker Hub (triggered by GitHub release)
- Update the docs on GitHub pages
Closes#336 (GitHub Actions workflow to replace Travis and Appveyor)
b/190743862 (internal; tracking replacement of Travis)
Change-Id: Ic53eef60a8587c5d1487769a0cefaa16eb9b46e7
In e2efb5d4, I fixed shared_library builds on Windows, but I
introduced another issue in which the libpackager_type variable was
not correctly defined by default. This meant that the build only
worked with this variable explicitly-defined in GYP_DEFINES when
gclient sync was run.
This fixes the default definition so that libpackager_type does not
need to be defined explicity.
Related to #318 (shared_library builds on Windows)
Issue #336 (progress toward GitHub Actions workflow to replace Travis
and Appveyor, where we need to build and test shared_library on all
platforms)
b/190743862 (internal; tracking replacement of Travis)
Change-Id: If353e1d3c312ab0c568d4d4d2b789e922d7216e1
Shared library builds worked, but failed tests because they were made
with the wrong CRT linker settings. Strings allocated within the
library could not be freed outside the library because the dynamic CRT
was not used.
This sets necessary gyp variables to link with a dynamic CRT on
Windows, thereby fixing tests running in shared library mode that
otherwise hung in a GitHub Actions environment.
Related to #318 (shared_library builds on Windows)
Issue #336 (progress toward GitHub Actions workflow to replace Travis
and Appveyor, where we need to build and test shared_library on all
platforms)
b/190743862 (internal; tracking replacement of Travis)
Change-Id: Iffefd27c2aa4ec479ce1d10b099483e417d2231f
To make shared_library builds work on Windows with MSVS 2019, this
commit:
- Silences a useless warning about a private member in dll-exported
Status class.
- Exports the File class used by packager.exe
- Removes the explicit File dependency in packager.exe in favor of
libpackager, now that File is exported
- Add missing defines in packager.exe and packager_test.exe that
instruct the linker to import Status and File from the library
Closes#318 (shared_library builds on Windows)
Issue #336 (progress toward GitHub Actions workflow to replace Travis
and Appveyor, where we need to build and test shared_library on all
platforms)
b/190743862 (internal; tracking replacement of Travis)
Change-Id: I091f1655d88d36f353f7df497101eef17729eefe
At this point static_library builds are working in MSVS 2019. shared_library builds are still not working.
Closes#867 (MSVS 2019)
Issue #318 (progress toward shared_library support on Windows)
Issue #336 (progress toward replacing Travis & Appveyor with GitHub Actions, which uses MSVS 2019)
b/190743862 (internal; tracking replacement of Travis)
Because a StreamState object contains a unique_ptr, it is not
copyable. A vector of StreamStates, therefore, causes a compile error
on resize or push_back, both of which invoke the copy constructor.
I don't know why MSVS complains, but clang does not.
To fix this, I'm changing vector<StreamState> into deque<StreamState>.
At this point static_library builds are working in MSVS 2019.
shared_library builds are still not working.
Issue #867 (MSVS 2019)
Issue #336 (progress toward replacing Travis & Appveyor with GitHub
Actions, which uses MSVS 2019)
b/190743862 (internal; tracking replacement of Travis)
Change-Id: Iaa9d5fc357102d15eac96c29ebeee7c7236e976b
It is not working correctly in gcc 4.8 or earlier, which is still
popular (bundled by default in CentOS 7).
Issue #865, #929.
Change-Id: I136446a70831bd0237cd29646dd349fe7558176b
Legacy players, e.g. older versions of ExoPlayer, do not handle default webvtt text alignment correctly. Need to specify `align:center` explicitly cues without text alignment for backwards compatibility.
Fixes#925.
- Do not write the HTTP PUT response to cache which can potentially overflow the cache buffer as it is not consumed.
- VLOG(1) instead of LOG(ERROR) on HttpFile::Size() as it can be called during normal code execution.
- Add a command line flag `--user_agent` to allow users to specify their custom user agent string.
Fixes#939.
It is not working correctly in gcc 4.8 or earlier, which is still
popular (e.g. bundled by default in CentOS 7).
Fixes#865, #929.
Change-Id: I55a42428dbd2a12fc2c3b1e6a49fdd662a295dca
This also allows setting the language of different text streams from
the same input. Multiple streams can use the same input stream
using different cc_index values and can each use a different language.
This also will try to pull the language from the input if not
specified.
Change-Id: I7078710b509b7d77dad8cb4299a82f954af7e9e7
Note that this only supports a single page within the DVB-sub stream.
Multiple pages will be merged together. A follow-up will allow
selecting a specific page.
This only supports outputting using TTML or MP4+TTML; you cannot have
DVB-sub output nor can you output it in WebVTT. Since DVB-sub
uses images, it is hard to impossible to do this with WebVTT.
This also only supports interlaced images, not progressive images
nor text.
Closes#832
Change-Id: Id6dbb6393c7b9a05722e61c6bd255bef5e69a7d8
Issue #149
Co-authored-by: Andreas Motl <andreas.motl@elmyra.de>
Co-authored-by: Rintaro Kuroiwa <rkuroiwa@google.com>
Co-authored-by: Ole Andre Birkedal <o.birkedal@sportradar.com>
Previously if there are no bytes remaining, SkipBytes(0) would fail,
which results in parsing error in
AACAudioSpecificConfig::ParseProgramConfigElement.
Fixes#875.
Change-Id: I271899a37303d0d3fa0cf1bf90f99227058b82df
I.e. the flag --generate_sidx_in_media_segments,
--nogenerate_sidx_in_media_segments work for both single-segment
and multi-segment mode with this change.
Related to #862.
Change-Id: Icd27fd00e8e036ba0c4709b48650372429cc0351
The reference count in 'sidx' box is a uint16 field, which allows at
most 0xFFFF entries, i.e. at most 0xFFFF subsegments, which is roughly
18 hours for one second segments.
Do not fail packaging when it happens. Instead, generate a warning and
truncate the number of references to 0xFFFF instead.
Note that the actual number of mp4 fragments in the mp4 file can still
be more than 0xFFFF. The stream will not play to the end in DASH, but
it will play successfully in HLS.
Workarounds #862.
Change-Id: Ib3930418d1528df1f9ea64cda0d0ebaa78d26abb
This allows us to have presentationTimeOffset for text streams since
this needs to appear on a SegmentList/SegmentBase/SegmentTemplate.
Issue #832
Change-Id: Id3ab3308029185815d50a6cb1142e6a97f744d4f