This is an MP4 Parser which extracts CEA-708 packets from Fragmented MP4 streams.
The Closed Caption Parser (shaka.media.ClosedCaptionParser) will own this MP4 Parser, and will initialize it and call it as shown. As data comes in, the parser will parse this data, and the caption packets data then be returned in a callback (on708Data), as shown. Here, a theoretical decoder (future pull request, mentioned as a Todo comment) will decode and extract the parsed captions from these packets.
Issue #2648
The period-flattening algorithm is run even on single-period content
if the manifest is dynamic, because we don't know if another period
will be added later.
As a failsafe, we should create one output per input for single-period
content, and we can ensure that no streams are unused by marking an
input stream as the "best match" for an output if they share the same
ID. That way, even if all other characteristics for two inputs are
the same, the input-to-output mapping for single-period content will
always be sane.
That ID-based logic was missing for text streams. This change
corrects that.
Closes#2646
Change-Id: I28c6c63d92bcf710ae0072783911f9e66ed78228
This fixes all the license headers in the main library, which corrects
the appearance of the main license in the compiled output.
It seems that the `!` in the header forces the compiler to keep it in
the output. I believe older compiler releases did this purely based
on `@license`.
Issue #2638
Change-Id: I7f0e918caad10c9af689c9d07672b7fe9be7b2f3
@exportInterface is used by the extern generator, but ignored by the
compiler. @export should be used for shaka.util.FairPlayUtils and
shaka.util.BufferUtils.
Closes#2626 and #2627
Since we are getting strict about semantic versioning, we can't remove
features in v3.1. Any backward compatibility we offer will be
maintained until v4.0.
The exception is explicit IE 11 support, which will still be removed
in v3.1.
To help us follow the rules for removal, the Deprecate utility no
longer accepts a minor version argument.
Change-Id: I4dd94a6084e4ed72eeec410eb9aa0ad974d8dac8
We have decided to bump the major version number instead of the minor
number, based primarily on the fact that this release breaks
compatibility with our previous manifest structure.
Change-Id: I67e4c8267c6e103cfc7278e09daac186ae5cbbc6
For some reason, the new compiler in the master branch let this by,
but the old compiler in the v2.5.x branch complained when I
cherry-picked the utility.
Change-Id: I1e688f72594b74ed7d2a7c2801eb179b8ec13e8c
When we construct final streams in period flattening, we start them
off original streams and then combine streams from each period that
best matches the characteristics of the original stream.
The original stream also participates in the matching process, but
it was possible for it not to get selected as the best match if
there were other streams with similar characteristics.
This change adds logic to always prefer the original stream if
it's encountered.
Also, this change adds a bandwidth comparison for audio
streams to ensure the closest streams get matched bandwidth-wise.
Issue #2537.
Change-Id: I5d99a452a12ea1c4bb70fa8aba4bec479ff9d27b
It does not make sense to truly export an abstract interface. This
should always have used the exportInterface annotation.
Change-Id: If170b41b89728dd549669cee0c606de492b79ad9
We used to alias static utility methods by assigning the method itself
to a local variable. This is not allowed by the new Closure Compiler
release that we are adopting, and for good reason.
The old compiler did not understand the use of "this" in static
methods, but the new one does. And it turns out that when we start
using "this" in static methods (see #2532), aliasing the method itself
can break everything.
When you refer to "this" in a static method, it refers to the class.
This is really useful in utility classes that have private static
methods they use to perform common tasks. However, just as it ruins
the value of "this" to alias an instance method, the same is true of
an ES6 class's static method.
The fix is to always alias the class instead of the method. The new
compiler will simply not let us get away with the old way any more, so
regressions after this are unlikely.
Issue #2528 (compiler upgrade)
Issue #2532 (static "this")
Change-Id: Id800d466e639c7cbcf4aa6fbb05114c772a2229f
The old compiler would let us export a static method on a class
without exporting the whole class and its constructor. The new
compiler silently ignores `@export` for any methods of a non-exported
class.
This means that for the latest Closure Compiler, we must export any
class with exported static methods. In some cases, these are
non-utility classes with constructors we'd rather not export, but the
constructor is implicitly exported by exporting the class itself.
This was initially caught by the integration tests. The error wasn't
especially helpful, so I added a try/catch to loadShaka that makes the
error more apparent:
TypeError: Cannot read property 'registerParserByMime' of undefined
To make sure we do not make this mistake again, I've added a check to
the extern generator, which was already able to detect these types of
classes. I don't know a compiler-based way to do it, since the
compiler silently ignores the export annotations in these cases.
Issue #2528
Change-Id: I797c75a8098b0bb3cf837588569f878253dec2cf
Various issues with the nullability of number types led to various
fixes, including:
- defaulting a nullable number to 0 to avoid propagating a null value
through calculations
- adding an assertion or runtime check that something is not null
- moving an existing null check to before the calculation
- returning early on null during an iteration
- changing a nullable number to non-nullable
- defaulting to NaN instead of null
These issues were caught by a compiler upgrade.
Issue #2528
Change-Id: I86d516c74a42ee3624c33d7513d2d4c76d3ea589
In "Remove extraneous exports" (Change-Id
Iaf142397f31bd927bf942499a79da595f77361d5), I removed an export that
was actually required in the newer compiler. This replaces the
missing export.
Issue #2528
Change-Id: I3e9ec7085d813365dab917b4712571585d2286c8
In many places, we check error codes on shaka.util.Error. But the
compiler doesn't know that what is caught in "catch" is that type, so
we add type assertions.
In some cases, we know that other types may also be thrown, so there
are also some runtime checks. Some of these had to be refactored to
allow the compiler to correctly infer types.
Change-Id: I053bd7e96213c689aae3889315052dd402124690
In many places, the implicit type info was insufficient. For example,
document.createElement returns Element, but the actual return is
always a subclass of Element. In many cases, we need the compiler to
know that a specific subclass is in use, so that it can correctly
check our use of subclass-specific properties. Another common pattern
is confusion between Node and Element (which is a subclass of Node).
Almost all of the changes in the demo and UI are Element-related.
In some places, we referred to HTMLMediaElement, used in the Player
API, instead of the more specific HTMLVideoElement in use in our demo.
Since the demo uses video-specific properties, we must use the more
specific type.
Another case is the use of document.createEvent, which returns Event
according to the compiler, but in reality always returns a subclass,
like CustomEvent.
In one case in NetworkingEngine, correcting the type of an
AbortableOperation led to the discovery that we had been incorrectly
accessing a private method of that type.
In goog.Uri, there were several instances of "*" for a type, which the
newer compiler won't accept. These have all been corrected.
Finally, in some places, we had the wrong nullability on a type.
These were all caught by a compiler upgrade.
Issue #2528
Change-Id: I7f2d070e3da32fe9ff5f444315649f3cbdb5a4a5
The compiler is very picky about the use of the "disabled" property on
HTMLElement, since it is only defined on certain subclasses of that.
This adds a method to create a button with the correct type to satisfy
the compiler.
Issue #2528
Change-Id: I31cacd62a35acc87b245ab362dbab55d791cf34d
This is only defined on Stream, not Variant. This bug has was
introduced in PR #2332 and the v2.5.8 release and affects v2.5.8 -
v2.5.10. The corresponding feature (frameRate restrictions) has
actually never worked.
This was caught by a compiler upgrade which is still in progress.
Change-Id: I0409d9be8d3f6eb0794775ca29f28b98208bab4f
This method (shaka.util.Uint8ArrayUtils.equal) was removed between
v2.5.0 and v2.6, but could be in use by applications. This change
adds the utility method back, with a deprecation warning.
Change-Id: Ifd780759ae389e766c1889a83545cfda8969e76b
These exports are not needed by the application. Some of them may
have been added to work around the extern generator's lack of support
for partially-exported classes.
Change-Id: Iaf142397f31bd927bf942499a79da595f77361d5
In the process, this removes the in-progress flag, which should fix
issues where the storage instance can't be re-used after an error.
Closes#1432Closes#2432
Change-Id: I51018e170fb9ab262b5c70125a03d979c8ccfb08
This creates a new utility used by DashParser and old offline DB
formats to combine Streams across Periods. This allows multi-Period
DASH content to be played without period-specific structures in the
manifest format, StreamingEngine, or Player. This also makes the
Tracks stable across Periods.
Closes#1339 (flatten periods)
Closes#1698 (rapid period transitions issue)
Closes#856 (audio change causes bitrate change)
Change-Id: Icb04c8e47e36eacf7ac024a5063130d85a115e54
When period-flattening combines Streams, key ID arrays would get very
long with duplicates.
This changes keyIds in the manifest and offline structures from Array
to Set.
Issue #1339
Change-Id: I003d23e567efafa771ecd2ad597900181604ad18
This removes periods from the internal manifest structure and cleans
up code and tests accordingly. This leaves us unable to play
multi-period DASH & offline streams until the main period-flattening
algorithm is completed in shaka.util.Periods.
Three test cases have been disabled for the moment.
Multi-period playback will be restored in a smaller, more focused
follow-up commit, with disabled tests re-enabled.
Issue #1339 (flatten periods)
Issue #1698 (rapid period transitions issue)
Issue #856 (audio change causes bitrate change)
Closes#892 (refactor StreamingEngine)
Change-Id: I0cbf3b56bfdb51add15229df323b902f0b2e643a
The 'webkitkeyneeded' and 'encrypted' events send similar data, but
they were incompatible with each other and our transform handling.
This makes our polyfill produce the same format as the browser for
cases where the browser may only fire the old event. This also makes
our utilities work with the new format.
The 'webkitkeyneeded' event was a length-prefixed UTF-16 string while
the 'encrypted' event was just a UTF-8 string.
This also makes a breaking change in the transform callback to pass the
init data type. This shouldn't break anyone that only uses the first
argument; the second argument was mainly added so we could have the
default transform work without knowing anything.
This change could also break people who use custom transform functions.
The init data format is changing, which could break people who read
it directly. If they follow the tutorial and use our utilities, it
shouldn't break. This also updates the tutorial to match the new format
and be more clear about the format.
Fixes#2214
Change-Id: I006382028e828e31e20e085114fd7fd85c0e1eaa
When playing an asset, the player will first choose a codec, based
on the lowest average bandwidth.
However, the storage mechanism did not have any such filtering;
instead, all it did (if using the default track filtering plugin) was
pick the middle-bandwidth audio track. This lead to it sometimes making
different codec decisions than the player would have.
This CL breaks the codec filtering logic out into a helper function, and
calls it both for playback and storage.
It also adds headers comments to some functions in the demo page.
Closes#2390
Change-Id: I09f1a24753121afd0e7500577c0f64ccffe5a4d1
querySelector isn't available in Shaka Player Embedded. Since we only
use it to find nodes with a specific tag name, we can usually use
getElementsByTagName.
Issue google/shaka-player-embedded#113
Change-Id: Ia225e5d1f7598b13bd05db868fe2ea566dca4493
`'webkitneedkey'` events are fired with the same `event.initData` for the video and audio tracks, and a new session is needed for each.
Closes#813 (duplicate sessions required on Tizen)
Closes#2447 (polyfills broken on Tizen)
Closes#2448 (PlayReady broken on Tizen)
In the code for supportsChunkSize, we test to see if a given chunk
size is supported by array to string conversion by trying to perform an
operation on a Uint8Array of that size without throwing an error.
However, the result of that operation was only ever referenced inside an
assert. Because asserts are compiled out in release builds, the
result of that operation was not being used... and thus, the entire
call was being compiled out.
This changes the return value of the function to use the result of the
operation, thus preventing it from being compiled out.
This also adds a unit test that will detect this problem in the future.
Closes#2433
Change-Id: If3048531afc460beb16de0dda7f7fcbd5499fdaf
Instead of having the "factories" use "new" to construct them, now they
will be plain functions.
Closes#1521
Change-Id: Ia6151ad679a78a5c6db128d43094c82add0af348
Álvaro Velad Galván
Muhammad Haris
Joey Parrish
Muhammad Haris
Jacob Trimble
michellezhuo
Oren Me
Sandra Lokshina
Sergei Gridasov
Theodore Abshire
Peter Nycander