Skip to content

Conversation

@peaBerberian
Copy link
Collaborator

After some brainstorming related to #1470, we noticed that as is, our old mediaCapabilitiesProber experimental tool could gain by being more flexible.

Especially, the getCompatibleDRMConfigurations method checked multiple EME MediaKeySystemConfiguration at once and returned information on actual configurations compatible to them once all of them have been checked.

We wondered whether this method would not be more useful by making it less powerful: we'll now only check for a single MediaKeySystemConfiguration per method call (and rename that method to checkDrmConfiguration).
Doing this signals to an application that it can just combine multiple calls if it wants the old behavior (e.g. through a Promise.all), use Promise.race to just obtain the first one etc. (this would still be possible with the previous API, but seemed unnatural to application developers).

I also added a timeout argument to it, but realized that it might be very complex to maintain, as theoretically checkDrmConfiguration could call multiple browser API sequentially in the future (as other mediaCapabilitiesProber's methods are doing).
In that case, where are we supposed to apply the timeout: to each browser API call or globally on the method?


I also profited from this work to rewrite the implementation of other mediaCapabilitiesProber's method without changing their API, as I found that a lot of its data-processing code was unneeded and difficult to follow.

@peaBerberian peaBerberian added the proposal This Pull Request or Issue is only a proposal for a change with the expectation of a debate on it label Jun 26, 2024
@peaBerberian peaBerberian added this to the 4.2.0 milestone Jun 27, 2024
@peaBerberian peaBerberian added the Priority: 2 (Medium) This issue or PR has a medium priority. label Jul 26, 2024
@peaBerberian peaBerberian force-pushed the misc/mcp-refacto branch 3 times, most recently from 99059eb to 538aff1 Compare September 4, 2024 16:57
@peaBerberian peaBerberian modified the milestones: 4.2.0, 4.3.0 Oct 4, 2024
@peaBerberian peaBerberian modified the milestones: 4.3.0, 4.4.0 Apr 7, 2025
@peaBerberian peaBerberian force-pushed the dev branch 2 times, most recently from 00fc806 to b7216b4 Compare April 15, 2025 18:14
@peaBerberian peaBerberian force-pushed the misc/mcp-refacto branch 2 times, most recently from 076c092 to aaec181 Compare April 22, 2025 18:19
@github-actions
Copy link

✅ Automated performance checks have passed on commit 086705d2356d97175bb1b90a86b91cda7dd6d43f with the base branch dev.

Details

Performance tests 1st run output

No significative change in performance for tests:

Name Mean Median
loading 19.88ms -> 20.18ms (-0.295ms, z: 1.52915) 27.30ms -> 27.45ms
seeking 15.44ms -> 18.22ms (-2.784ms, z: 0.89372) 11.40ms -> 11.40ms
audio-track-reload 26.90ms -> 27.19ms (-0.291ms, z: 2.58275) 39.45ms -> 39.60ms
cold loading multithread 48.31ms -> 47.38ms (0.936ms, z: 10.74112) 71.10ms -> 69.90ms
seeking multithread 21.37ms -> 29.35ms (-7.981ms, z: 0.64715) 10.65ms -> 10.50ms
audio-track-reload multithread 26.78ms -> 26.79ms (-0.012ms, z: 1.02091) 39.30ms -> 39.30ms
hot loading multithread 15.87ms -> 15.80ms (0.072ms, z: 3.22256) 23.10ms -> 22.80ms

@canalplus canalplus deleted a comment from github-actions bot Apr 22, 2025
@github-actions
Copy link

github-actions bot commented May 7, 2025

✅ Automated performance checks have passed on commit 2440b2cabee15ee9da1a3a89ad633377aa1a230d with the base branch dev.

Details

Performance tests 1st run output

No significative change in performance for tests:

Name Mean Median
loading 19.30ms -> 19.65ms (-0.357ms, z: 1.92629) 26.40ms -> 26.55ms
seeking 15.26ms -> 15.86ms (-0.600ms, z: 2.58705) 11.10ms -> 11.10ms
audio-track-reload 26.26ms -> 26.15ms (0.104ms, z: 1.71632) 38.25ms -> 37.95ms
cold loading multithread 46.57ms -> 45.71ms (0.860ms, z: 13.05967) 67.95ms -> 66.75ms
seeking multithread 21.91ms -> 20.56ms (1.343ms, z: 0.22689) 10.35ms -> 10.35ms
audio-track-reload multithread 26.12ms -> 25.93ms (0.191ms, z: 2.06951) 38.10ms -> 37.95ms
hot loading multithread 15.32ms -> 15.02ms (0.301ms, z: 7.45733) 22.05ms -> 21.60ms

export default function probeHDCPPolicy(
config: IMediaConfiguration,
): Promise<[ProberStatus]> {
export default async function probeHDCPPolicy(
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel that this function can either throw or return "NotSupported"
I'm wondering if we should catch any errors and return "NotSupported"

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Complex to say.

It fails if EME API failed to be called.

NotSupported would be if there's a high priority of the HDCP version being unsupported but here we're not so sure.

Maybe Unknown? I'm under the impression that for now Unknown is only for when the getStatusForPolicy API is not available, which is slightly different than e.g. requestMediaKeySystemAccess failing yet both would just indicate that it is unknown.....

Then, when applications handle promises, they generally also handle rejections (even linters often force that). So I'm not sure.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I removed the Unkown and it only returns "Supported" / "NotSupported" or reject

@github-actions
Copy link

✅ Automated performance checks have passed on commit afec1f5a5cc87c640ec77deb560a2f78318aaf89 with the base branch dev.

Details

Performance tests 1st run output

No significative change in performance for tests:

Name Mean Median
loading 18.97ms -> 18.92ms (0.060ms, z: 0.93514) 25.95ms -> 25.80ms
seeking 17.16ms -> 16.52ms (0.639ms, z: 1.07438) 10.95ms -> 10.95ms
audio-track-reload 25.76ms -> 26.10ms (-0.336ms, z: 0.53573) 37.65ms -> 37.65ms
cold loading multithread 46.17ms -> 45.28ms (0.886ms, z: 14.16195) 67.65ms -> 66.45ms
seeking multithread 19.15ms -> 14.46ms (4.696ms, z: 0.10779) 10.35ms -> 10.35ms
audio-track-reload multithread 25.73ms -> 25.72ms (0.003ms, z: 0.35913) 37.65ms -> 37.65ms
hot loading multithread 14.81ms -> 14.77ms (0.043ms, z: 5.09527) 21.45ms -> 21.30ms

ProbeHDCPPolicy can either, succeed with "Supported" | "NotSupported" | "Unknown" or reject.
Success with "unknown" or reject both occurs when the navigator API failed to execute and the support
of HDCP cannot be determined. To standardize the behavior of this function, the "Unknown"
return is removed and replaced by a promise rejection.
@github-actions
Copy link

✅ Automated performance checks have passed on commit 8c27b3b86ebef5ef89330c718477a5680eb9cc77 with the base branch dev.

Details

Performance tests 1st run output

No significative change in performance for tests:

Name Mean Median
loading 19.58ms -> 19.91ms (-0.326ms, z: 0.34568) 26.85ms -> 26.85ms
seeking 19.97ms -> 16.03ms (3.946ms, z: 0.35553) 11.25ms -> 11.10ms
audio-track-reload 26.37ms -> 26.49ms (-0.116ms, z: 0.34248) 38.55ms -> 38.55ms
cold loading multithread 47.28ms -> 47.55ms (-0.271ms, z: 9.69561) 69.15ms -> 68.10ms
seeking multithread 18.59ms -> 22.58ms (-3.993ms, z: 0.60042) 10.35ms -> 10.35ms
audio-track-reload multithread 26.29ms -> 26.17ms (0.122ms, z: 1.69261) 38.55ms -> 38.25ms
hot loading multithread 15.54ms -> 15.42ms (0.113ms, z: 3.03935) 22.20ms -> 22.05ms

@github-actions
Copy link

✅ Automated performance checks have passed on commit b34f4c2b0a51e001ba09ccc86ae17df97d0473d2 with the base branch dev.

Details

Performance tests 1st run output

No significative change in performance for tests:

Name Mean Median
loading 20.26ms -> 20.29ms (-0.023ms, z: 0.28825) 27.90ms -> 28.05ms
seeking 22.85ms -> 18.93ms (3.915ms, z: 1.12495) 11.40ms -> 11.40ms
audio-track-reload 27.08ms -> 27.12ms (-0.039ms, z: 0.37983) 39.75ms -> 39.60ms
cold loading multithread 48.24ms -> 47.57ms (0.669ms, z: 8.88062) 70.95ms -> 69.75ms
seeking multithread 24.70ms -> 26.10ms (-1.397ms, z: 1.87441) 10.50ms -> 10.50ms
audio-track-reload multithread 26.87ms -> 26.82ms (0.051ms, z: 1.06271) 39.45ms -> 39.30ms
hot loading multithread 16.28ms -> 16.12ms (0.152ms, z: 2.77614) 23.55ms -> 23.40ms

@peaBerberian peaBerberian merged commit 4f6e5de into dev Jun 24, 2025
11 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Priority: 2 (Medium) This issue or PR has a medium priority. proposal This Pull Request or Issue is only a proposal for a change with the expectation of a debate on it

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants