We depended on this font size being set in the font server's CSS, but
did not realize we had this implicit dependency. This makes our
desired font size explicit.
This protects us from applications which happen to use the same font
and class name with a different default size. Note that applications
which intend to change our icon size can still do so explicitly in
their own styles. This is meant only to protect against accidental
conflicts.
Closes#2633
Change-Id: I0a2993c8b2e39596b47eb59b7e1a4a6373633c0b
When we changed the font for the icons without changing the class
name, we lost upstream styles from the font server. This was not
obvious in our demo, but was more obvious in other apps where the font
size was different.
By using the same class name as used by the font server, we get those
upstream styles applied correctly.
Issue #2633
Change-Id: I615c1dfd86e5b9802d03050c5db0154ac196c2ef
@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
The IMA SDK URLs in the service worker were http, and should have been
https. This caused an issue when deploying v3.0.0 to appspot.
The IMA SDK URLs in the demo specified no protocol, but that is not
necessary, since https works in all contexts.
The IMA SDK URLs in the docs also specified no protocol, and one of
them was incorrect.
This corrects the mistaken URLs and makes them universally https.
Change-Id: I53dbf25ddb16ec882fcf3c070bcebed726277be1
Since createSegments_() is asynchronous, and we are updating all the streams
in parallel, the global playlistStartTime_ value may get changed when we update
other playlists, rather than the current playlist. This caused the references'
start and end times discontinuous in a stream.
Closes#2605
Change-Id: Ib2dd1161f4075486f79b0122b98e558ea7d05aaa
One of the src= playback tests was failing on Chromecast with an
estimated rate of about 20% when the src= tests are run alone. The
timeout for playback to start was found to be too short on that
resource-limited embedded device. This increases the playback timeout
in the test.
Fixes: 157702575
Change-Id: Ib8d5a0d961bc0e99e77c16b93ca63569f3a2cc31
This change adds the following methods on CastReceiver:
- setContentMetadata(metadata)
- clearContentMetadata()
- setContentTitle(title)
- setContentImage(imageUrl)
- setContentArtist(artist)
These should be called from the CastReceiver's app data callback.
The title, image, and artist methods cover all the Cast content
metadata fields that have an effect in the Google Home App as of June
2020, and setContentMetadata can be used to set one of several object
formats with many more fields defined in the Cast SDK docs.
See https://developers.google.com/cast/docs/reference/messages and the
definitions of GenericMediaMetadata, MovieMediaMetadata,
TvShowMediaMetadata, and MusicTrackMediaMetadata for details.
This also uses these methods from our cast receiver demo, so our demo
will now set all possible metadata when casting our content library.
Closes#2606
Change-Id: I6386276449dbddd2501cd6e3e52206f7fb30b8fd
1. We get the start time for either the first segment in the playlist,
or a segment after discontinuity. The logic for getting the start time
in both places is almost the same.
Moving the dupliate code to getStartTime_() function.
2. We create a temporary SegmentReference to get the start time.
Moving creating the SegmentReference into getStartTime_() function.
3. Moving the logic of getting timestampOffset for a discontinuity
segment into a seperate function.
createSegments_() is now 20+ lines shorter.
Change-Id: If484aab56aa169d4a0f9166813d696724230b919
The fix for Google Home scrubber in 8c3775ce (Change-Id
Iceec95f18cf15325b7ee2350a0f30f31edc90560) did not come with a
regression test. This change covers that fix with an automated test.
I have confirmed that the test fails without the fix.
Issue #2606
Change-Id: I13a2bcfb2fcca059db4e909d7c27fb68b0bfb409
Details of the cleanup:
- Don't replace the load() spy with a non-spy
- Fix an out-of-date comment on an explicit delay in a test
- Hoist expectMediaInfo helper to make it available for all tests
- Simulate loading content before the "generic controls messages" to allow the
use of expectMediaInfo
- Don't do a substring comparison on a JSON blob, which is inherently
unreliable, and compare the parsed object structure instead
Related to #2606
Change-Id: Ifb46e223ba800c0e10cbdfa6cb847faa8424cd3d
The current implementation of pixelAspectRatio in DASH is wrong. `@par` in DASH is "picture aspect ratio" so the correct is populate this field with `@sar`.
There is not a separate message for skip forward or skip backward, and
we already support seek. So there's no obvious reason to claim we
can't support skip forward and skip backward.
Related to #2606
Change-Id: If9a931afa2d6a0d323b561ed9f6500f79fb0d1bd
The docs for the Cast messages say that duration is optional, so it
seems better to omit it for live content, rather than send back an
absurdly-large number.
Note that this does not seem to affect seeking in live streams.
Seeking in live streams seems to be disallowed by the Google Home app
either way.
Related to #2606
Change-Id: Id7d3911b410489b56643afaaee12102b5d6929a1
When we get a GET_STATUS request, we are supposed to send back media
info. That field is only optional for other requests.
This fixes the scrubber in the Google Home app for VOD content.
Issue #2606
Change-Id: Iceec95f18cf15325b7ee2350a0f30f31edc90560
The replace() method of SegmentIndex was only ever used in HlsParser,
and was never exported from v2.5.x. We have decided at the last
minute to drop it before v3, so this change removes it from the
upgrade docs.
Change-Id: I0d89745dbeac14e1bf90e8e87f3401a797ea9792
When we get a playlist update, we replace the list of SegmentReferences
in the SegmentIndex. However, the position pointer in the
SegmentIterator of the SegmentIndex is not updated, and still points to
the index of the old SegmentReference list. Thus, the current
SegmentReference may be null.
We should merge the new SegmentReference list with the old list, and
mark the offset of the list.
Closes#2605
Change-Id: Ia6740e1173ac48467e7b141257cc9c6148e30a0c
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
In getSegmentReferenceNeeded_(), we get a SegmentReference base on
(presentationTime - maxDrift) time. If no SegmentReference is avaiable,
we wait until next update.
For live edge, if the SegmentReference with the drifted time is always
out of the segment availability start/end time window, we don't append
any segments.
If we can't find a valid segment with the drifted time, we should seek
with the presentation time.
Fixes#2589
Change-Id: I3fedc002ffc5c99f9dd1d1bf9525aca141b9a2be
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
Changes to the load() promise resolution on iOS for #2483 accidentally
broke language preferences in src= mode, and the regression test for
this revealed subtleties in how and when tracks may be selected with
Apple's native HLS.
By waiting for a "change" event on video.textTracks, we can make sure
Apple is ready to accept our own text track selection.
This should now work correctly on all platforms.
Closes#2593
Change-Id: Iec59b89001fbec3779a0f7087ce11efe1be003ef
I'm not sure what caused the change, but after some other changes
merged, screenshots on Linux were off slightly and needed an update.
Screenshots in Safari were way off, and a workaround in the screenshot
utility needed to be removed.
Change-Id: Ic28d83dddcd6272b4cbb83aa7a3dcdb5c8fcdad9
This adds our first screenshot-based layout tests and the
infrastructure to use WebDriver for screenshots through Karma.
This new kind of test will be skipped in any non-WebDriver context.
There are many pieces to this system.
First, we update the Karma WebDriver launcher to a newly-released
version that lets us access the client spec object from the launcher.
Second, we build a Karma middleware plugin to respond to HTTP requests
from the tests. We handle /screenshot/isSupported and return a bool
so tests can be skipped on non-WebDriver launchers. We also handle
/screenshot/diff to take the screenshot and compare it to a known-good
version.
The screenshot is a full-page screenshot, since element screenshots
don't work consistently across all the browsers in our test lab. The
screenshot is then cropped to a rectangle specified in the request.
This rectangle is measured to match a specific element, so in
practice, we are screenshotting just one element.
Browsers use sub-pixel rendering, effectively rendering at a scale
larger than the "pixels" seen by JS. The screenshot comes in at this
scale, so the requested cropping rectangle is scaled to match, then
the cropped screenshot is scaled down to the JS-measured size.
Because of sub-pixel rendering, element offsets can be non-integer
numbers. Normally, Karma puts the tests in a iframe, above which is a
variable-height banner showing which devices are connected to Karma
and what state they are in. So this variation and the lack of integer
offsets means we can run into stability issues due to rounding errors.
To make offsets consistent and improve stability of the screenshots,
this banner is now disabled in our Karma config.
The cropping, scaling, and diffing of images is handled Karma-side by
a node module called Jimp.
Before we start the layout tests for UITextDisplayer, we use a node
module in the browser called fontfaceonload to wait for our web fonts
to be fully loaded. This module is a polyfill that polls on IE and
uses a standard API in modern browsers to wait for our font to load.
This is all wrapped into a new test util called waitForFont.
Screenshots are stored in test/test/assets/screenshots/ and are
organized into folders by platform and browser and named according to
an identifier specified by each test case. The new screenshot is
written to disk with the suffix "-new", and a diff image is written
with the suffix "-diff". When a test fails, we can review the changes
in a browser with test/test/assets/screenshots/review.html. The
known-good screenshots can be updated with the new tool
build/updateScreenshots.py.
Change-Id: Ib477fd3c459de466c6dc91e9a60d3e2579164b12
These issues were mostly introduced in "Don't preload data on iOS",
and were not detectable in Chrome. They came up during a full test
pass in our test lab on all browsers.
Change-Id: Ife6e157a18df84ea30b840615f6d06a22e340a44
Instead of calling video.load() and waiting for loadeddata for src=,
wait for loadedmetadata. This should be a safe event to use in most
cases, and calling video.load() causes native HLS to start preloading
an uncontrollable amount of content.
The exception is if the app sets preload='none' on the video element.
If this happens, we will detect it, log a warning, and avoid the
loadedmetadata event which may never fire. This is not a scenario we
will officially support, but at least we can prevent a hang in
player.load().
Closes#2483
Change-Id: Id64c8f23cb8fa82bb5c301abafb51f2d9d8730f7
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
Rather than making the gradient 92px tall, make it 15% of the size of
the video container. This is consistent with the size of the controls
and the position of the subtitles when the controls are shown.
In this way, the size of the gradient is now proportional and
responsive to the size of the video container.
This was spotted while developing screenshot-based layout tests using
relatively small containers.
Change-Id: I304d99a26be90b9eefa50dc179b924da15dc601d
Removing the controls container when destroying the UI restores the
DOM back to its pre-constructor state after destroy() is complete.
This allows the video container to be reused.
This became an issue while developing screenshot-based layout tests.
Change-Id: I5aa74e9ef443037ad84ac6c8acf7d09f657d6b5e
While developing screenshot-based layout tests, it was discovered that
IE 11 did not position VTT/TTML regions in the same way as other
browsers. This turned out to be caused by a bug in IE's flexbox
implementation in which flex items that are center-positioned can
overflow the flex parent.
This uses the work-around recommended here:
https://github.com/philipwalton/flexbugs/tree/6e720da8#flexbug-2Closes#2584
Change-Id: I22b9790b8f5798ba757a111d2c502dd5a3415441
Theodore Abshire
Jacob Trimble
Joey Parrish
michellezhuo
Álvaro Velad Galván
Sandra Lokshina
Alex Jones