-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
fix(cast): Use cast platform APIs in MediaCapabilties polyfill #4727
Conversation
supported
for MediaCapabilties.decodingInfo() polyfill in Cast devices.
Incremental code coverage: 100.00% |
…rs-in-mediacapabilitiesdecodinginfo-polyfill-for-cast-platform
…d capitalization error for the 'framerate' parameter.
@JulianDomingo There seems to be a lot of bugs in the tests when running on Chromecast, can you review it? Thanks! |
Sure thing, it looks like |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM if spyOn doesn't need cleanup
f625b35
to
2b8ecf9
Compare
…ble. Only throw an error if the entire cast namespace is unavailable.
2b8ecf9
to
6a8cf51
Compare
….__platform.__canDisplayType
@avelad @joeyparrish Based on my findings with the Chromecast lab failures, the tests were failing due to
This obviously contradicts with my manual tests on my Chromecast devices. Maybe this has something to do with the |
lib/polyfill/media_capabilities.js
Outdated
frameRate = undefined, | ||
transferFunction = undefined, | ||
}) { | ||
if (!(window.cast && cast)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: I don't believe you need both of these checks. I would just say if (!window.cast)
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done, removed.
lib/polyfill/media_capabilities.js
Outdated
* width: Describes the stream horizontal resolution in pixels. | ||
* height: Describes the stream vertical resolution in pixels. | ||
* frameRate: Describes the frame rate of the stream. | ||
* transferFunction: Describes the video transfer function supported by | ||
* the rendering capabilities of the user agent. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since all of these come from videoConfig, I feel like you should just pass that instead of creating a new record type.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done, thanks
shaka.util.Error.Category.CAST, | ||
shaka.util.Error.Code.CAST_API_UNAVAILABLE); | ||
} else if (!(cast.__platform__ && cast.__platform__.canDisplayType)) { | ||
shaka.log.warning('Expected cast APIs to be available! Falling back to ' + |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is very strange. I'd like to help you look into that, but I don't want to hold up the PR for it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, was held up on this for a while - the lab tests were failing without this check.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I spent a solid day on this, and it's time for me to give up for now. I managed to forward the Cast platform APIs through an iframe boundary, but not in a way that is compatible with Karma's websocket usage. :-(
'codecs="hev1.2.4.L153.B0"; ' + | ||
'width=512; ' + | ||
'height=288; ' + | ||
'framerate=23.976023976023978; ' + |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks brittle. I don't know if we can rely on this exact amount of detail in converting a number to a string on all devices. Can you make the framerate 24 for this test instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done, forgot to consider precision here.
lib/polyfill/media_capabilities.js
Outdated
* width: Describes the stream horizontal resolution in pixels. | ||
* height: Describes the stream vertical resolution in pixels. | ||
* frameRate: Describes the frame rate of the stream. | ||
* transferFunction: Describes the video transfer function supported by | ||
* the rendering capabilities of the user agent. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1
supported
for MediaCapabilties.decodingInfo() polyfill in Cast devices.See #4726 for more context. This allows Cast devices to properly filter stream variants with a resolution surpassing that of the device's capabilities. We place the fix in the `MediaCapabilities` polyfill since it's intended to be the right way to check for anything related to platform support. HDR support checks will require `eotf=smpte2048`, as indicated in #2813 (comment). Specifically, a `{hev|hvc}1.2` profile is only an *indication* of an HDR transfer function, but *may* be a non-HDR 10-bit color stream. In Cast, the platform can distinguish between the two by explicitly providing the transfer function; it uses `smpte2048` (`"PQ"`) because this is the "basis of HDR video formats..." (https://en.wikipedia.org/wiki/Perceptual_quantizer).
See #4726 for more context. This allows Cast devices to properly filter stream variants with a resolution surpassing that of the device's capabilities. We place the fix in the `MediaCapabilities` polyfill since it's intended to be the right way to check for anything related to platform support. HDR support checks will require `eotf=smpte2048`, as indicated in #2813 (comment). Specifically, a `{hev|hvc}1.2` profile is only an *indication* of an HDR transfer function, but *may* be a non-HDR 10-bit color stream. In Cast, the platform can distinguish between the two by explicitly providing the transfer function; it uses `smpte2048` (`"PQ"`) because this is the "basis of HDR video formats..." (https://en.wikipedia.org/wiki/Perceptual_quantizer).
See #4726 for more context. This allows Cast devices to properly filter stream variants with a resolution surpassing that of the device's capabilities. We place the fix in the `MediaCapabilities` polyfill since it's intended to be the right way to check for anything related to platform support. HDR support checks will require `eotf=smpte2048`, as indicated in #2813 (comment). Specifically, a `{hev|hvc}1.2` profile is only an *indication* of an HDR transfer function, but *may* be a non-HDR 10-bit color stream. In Cast, the platform can distinguish between the two by explicitly providing the transfer function; it uses `smpte2048` (`"PQ"`) because this is the "basis of HDR video formats..." (https://en.wikipedia.org/wiki/Perceptual_quantizer).
See #4726 for more context. This allows Cast devices to properly filter stream variants with a resolution surpassing that of the device's capabilities. We place the fix in the `MediaCapabilities` polyfill since it's intended to be the right way to check for anything related to platform support. HDR support checks will require `eotf=smpte2048`, as indicated in #2813 (comment). Specifically, a `{hev|hvc}1.2` profile is only an *indication* of an HDR transfer function, but *may* be a non-HDR 10-bit color stream. In Cast, the platform can distinguish between the two by explicitly providing the transfer function; it uses `smpte2048` (`"PQ"`) because this is the "basis of HDR video formats..." (https://en.wikipedia.org/wiki/Perceptual_quantizer).
See #4726 for more context.
This allows Cast devices to properly filter stream variants with a resolution surpassing that of the device's capabilities.
We place the fix in the
MediaCapabilities
polyfill since it's intended to be the right way to check for anything related to platform support.HDR support checks will require
eotf=smpte2048
, as indicated in #2813 (comment). Specifically, a{hev|hvc}1.2
profile is only an indication of an HDR transfer function, but may be a non-HDR 10-bit color stream. Take for instance this publicly available hls.js HEVC stream (https://devstreaming-cdn.apple.com/videos/streaming/examples/bipbop_adv_example_hevc/master.m3u8) which contains stream variants with thehvc1.2.4.L123.B0
codecs, but with a resolution < 4K:In Cast, the platform can distinguish between the two by explicitly providing the transfer function; it uses
smpte2048
("PQ"
) because this is the "basis of HDR video formats..." (https://en.wikipedia.org/wiki/Perceptual_quantizer). Below you can see the platform correctly distinguishing between an HDR-capable and non-HDR capable HDMI sink device (using a 4K-capable Chromecast):canDisplayType()
results on a 1920x1080 ASUS monitor:canDisplayType()
results on a 4K HDR TCL 2017 Roku TV (43"):