Allow level-id to be different in codec match #3023

henbos · 2024-11-21T11:51:11Z

henbos · 2024-11-21T11:51:36Z

@aboba Does this wording make sense to you?

webrtc.html

fippo · 2024-11-21T13:46:32Z

if you want to go this route you will also need to take care of RFC6184s level-asymmetry-allowed, no? All of this is reasonably well-defined in IETF specs though (well, not quite for HEVC) already

henbos · 2024-11-21T14:55:00Z

if you want to go this route you will also need to take care of RFC6184s level-asymmetry-allowed, no?

No this is just about the codec matching algorithm used to sanity check input to setParameters/setCodecPreferences, what is actually negotiated based on this is defined somewhere else.

As for sending the selected codec, the description is kind of vague, RTCRtpEncodingParmaters.codec just says:

Optional value selecting which codec is used for this encoding's RTP stream. If absent, the user agent can chose to use any negotiated codec.

And setParameters just says:

In parallel, configure the media stack to use parameters to transmit sender.[[SenderTrack]].

So it's just "codec used for selecting what to send", we might want to create an issue about clarifying not to send greater than the level-id that was negotiated, but that seems more like an editorial note.

henbos · 2024-11-21T15:03:50Z

not to send greater than the level-id

We might want to update getParameters().encodings[i].codec to match the level-id that you find in getParamters().codecs though? Separate issue though because that is the same as what happens with setCodecPreferences() today

webrtc.html

amendments.json

henbos · 2024-11-22T09:38:01Z

Codec wizard @aboba, can you do another review?

henbos · 2024-11-22T11:00:24Z

Btw I had said during the meeting that I thought all instances of "codec matching" could ignore level, but upon a second look I realized that we don't need to be that "loose" in most cases. For example if you addTransceiver, the only valid input is from getCapabilities since there is no chance that anything else has been negotiated for that transceiver yet. It might not hurt to be more loose here, but it does not seem to help either. Ultimately we only need to "ignoreLevels=true" at a few places:

When negotiation completes, the check to see if the codec was negotiated away and for maybe clearing setParameters's codec value, this should not remove the codec because of a level mismatch.
When setParameters is called, this should not throw due to level mismatch (= "Proposal A").
In addition I clarified that the "RTCRtpEncodingParameters.codec" picks codec based on "ignoreLevels=true" for the same reason that setParameters is supposed to work here, but this was never called out before.

In all other cases we can "ignoreLevels=false", which the PR reflects now.

webrtc.html

Co-authored-by: Harald Alvestrand <hta+github@alvestrand.no>

webrtc.html

Add test coverage for w3c/webrtc-pc#3023 which unblocks merging the PR (it has "editors can integrate"). Specifically it should be possible to negotiate H265 even if the level-id is downgraded in the SDP answer (not throwing on level-id mismatch). - H265 is behind flags so a virtual test suite is added. - If bot lacks HW capabilities to do H265, the tests will PRECONDITION_FAILED. To avoid reverting tests we will allow the bots to both pass and fail, I filed crbug.com/388299759. Some of the tests FAIL even when they run: passing these tests will be covered by crbug.com/381407888. Bug: chromium:381407888, webrtc:41480904, chromium:388299759 Change-Id: Ie017560b4310418a4c9ed854dcb09136b9b446e7

Add test coverage for w3c/webrtc-pc#3023 which unblocks merging the PR (it has "editors can integrate"). Specifically it should be possible to negotiate H265 even if the level-id is downgraded in the SDP answer (not throwing on level-id mismatch). - H265 is behind flags so a virtual test suite is added. - If bot lacks HW capabilities to do H265, the tests will PRECONDITION_FAILED. To avoid reverting tests we will allow the bots to both pass and fail, I filed crbug.com/388299759. Some of the tests FAIL even when they run: passing these tests will be covered by crbug.com/381407888. Bug: chromium:381407888, webrtc:41480904, chromium:388299759 Change-Id: Ie017560b4310418a4c9ed854dcb09136b9b446e7 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6148192 Reviewed-by: David Baron <dbaron@chromium.org> Commit-Queue: Henrik Boström <hbos@chromium.org> Reviewed-by: Evan Shrubsole <eshr@google.com> Cr-Commit-Position: refs/heads/main@{#1404052}

henbos · 2025-01-09T11:08:01Z

WPTs added and PR updated with link + addressed remaining comments.

henbos · 2025-01-09T11:08:25Z

Merging based on Editors can integrate

henbos · 2025-01-09T11:08:57Z

Removing needs test label since tests now exist

…al level-id in SDP answers., a=testonly Automatic update from web-platform-tests Add WPTs for negotiating H265 with minimal level-id in SDP answers. Add test coverage for w3c/webrtc-pc#3023 which unblocks merging the PR (it has "editors can integrate"). Specifically it should be possible to negotiate H265 even if the level-id is downgraded in the SDP answer (not throwing on level-id mismatch). - H265 is behind flags so a virtual test suite is added. - If bot lacks HW capabilities to do H265, the tests will PRECONDITION_FAILED. To avoid reverting tests we will allow the bots to both pass and fail, I filed crbug.com/388299759. Some of the tests FAIL even when they run: passing these tests will be covered by crbug.com/381407888. Bug: chromium:381407888, webrtc:41480904, chromium:388299759 Change-Id: Ie017560b4310418a4c9ed854dcb09136b9b446e7 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6148192 Reviewed-by: David Baron <dbaron@chromium.org> Commit-Queue: Henrik Boström <hbos@chromium.org> Reviewed-by: Evan Shrubsole <eshr@google.com> Cr-Commit-Position: refs/heads/main@{#1404052} -- wpt-commits: 545a2ed81a38330f024fac8c0b139739a7329097 wpt-pr: 49990

Add test coverage for w3c/webrtc-pc#3023 which unblocks merging the PR (it has "editors can integrate"). Specifically it should be possible to negotiate H265 even if the level-id is downgraded in the SDP answer (not throwing on level-id mismatch). - H265 is behind flags so a virtual test suite is added. - If bot lacks HW capabilities to do H265, the tests will PRECONDITION_FAILED. To avoid reverting tests we will allow the bots to both pass and fail, I filed crbug.com/388299759. Some of the tests FAIL even when they run: passing these tests will be covered by crbug.com/381407888. Bug: chromium:381407888, webrtc:41480904, chromium:388299759 Change-Id: Ie017560b4310418a4c9ed854dcb09136b9b446e7 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6148192 Reviewed-by: David Baron <dbaron@chromium.org> Commit-Queue: Henrik Boström <hbos@chromium.org> Reviewed-by: Evan Shrubsole <eshr@google.com> Cr-Commit-Position: refs/heads/main@{#1404052}

…al level-id in SDP answers., a=testonly Automatic update from web-platform-tests Add WPTs for negotiating H265 with minimal level-id in SDP answers. Add test coverage for w3c/webrtc-pc#3023 which unblocks merging the PR (it has "editors can integrate"). Specifically it should be possible to negotiate H265 even if the level-id is downgraded in the SDP answer (not throwing on level-id mismatch). - H265 is behind flags so a virtual test suite is added. - If bot lacks HW capabilities to do H265, the tests will PRECONDITION_FAILED. To avoid reverting tests we will allow the bots to both pass and fail, I filed crbug.com/388299759. Some of the tests FAIL even when they run: passing these tests will be covered by crbug.com/381407888. Bug: chromium:381407888, webrtc:41480904, chromium:388299759 Change-Id: Ie017560b4310418a4c9ed854dcb09136b9b446e7 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6148192 Reviewed-by: David Baron <dbaron@chromium.org> Commit-Queue: Henrik Boström <hbos@chromium.org> Reviewed-by: Evan Shrubsole <eshr@google.com> Cr-Commit-Position: refs/heads/main@{#1404052} -- wpt-commits: 545a2ed81a38330f024fac8c0b139739a7329097 wpt-pr: 49990

…al level-id in SDP answers., a=testonly Automatic update from web-platform-tests Add WPTs for negotiating H265 with minimal level-id in SDP answers. Add test coverage for w3c/webrtc-pc#3023 which unblocks merging the PR (it has "editors can integrate"). Specifically it should be possible to negotiate H265 even if the level-id is downgraded in the SDP answer (not throwing on level-id mismatch). - H265 is behind flags so a virtual test suite is added. - If bot lacks HW capabilities to do H265, the tests will PRECONDITION_FAILED. To avoid reverting tests we will allow the bots to both pass and fail, I filed crbug.com/388299759. Some of the tests FAIL even when they run: passing these tests will be covered by crbug.com/381407888. Bug: chromium:381407888, webrtc:41480904, chromium:388299759 Change-Id: Ie017560b4310418a4c9ed854dcb09136b9b446e7 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6148192 Reviewed-by: David Baron <dbaronchromium.org> Commit-Queue: Henrik Boström <hboschromium.org> Reviewed-by: Evan Shrubsole <eshrgoogle.com> Cr-Commit-Position: refs/heads/main{#1404052} -- wpt-commits: 545a2ed81a38330f024fac8c0b139739a7329097 wpt-pr: 49990 UltraBlame original commit: 86ca1c880fa3a95d616df4db1fae65eb4e24e60e

This CL implements allowing sendonly codecs in setCodecPreferences(), i.e. this spec PR: w3c/webrtc-pc#3018. It also makes the setCodecPreferences() ignore level IDs in the filtering algorithm (but not in the sCP method call) as per this spec PR: w3c/webrtc-pc#3023. In short, before this CL, setCodecPreferences() threw an exception if a codec was preferred that is not present in receiver codec capabilities. After this CL, setCodecPreferences() allows you to prefer codecs that are *either* in the sender capabilities *or* the receiver capabilities. - This allows you to "offer to send", i.e. prefer sendonly codecs on a sendonly transceiver. - The filtering on direction is handled by RtpTransceiver::filtered_codec_preferences() which is called during SDP offer/answer (sdp_offer_answer.cc). Also as per spec changes, if this filtering results in not having any codecs to offer or answer then this results in not having any codec preferences as opposed to throwing an exception (old behavior). - Two old peer_connection_media_unittest.cc tests are updated to reflect the API failing less. This CL adds both unit tests (rtp_transceiver_unittest.cc) and full stack integration tests (peer_connection_encodings_integrationtest.cc). It also makes us pass the following Web Platform Tests in Chrome: https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/webrtc/protocol/h265-level-id.https.html Bug: chromium:381407888 Change-Id: I98a5ad1acccb56db0538e4d47975b8a725102c33 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/374520 Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org> Commit-Queue: Henrik Boström <hbos@webrtc.org> Reviewed-by: Harald Alvestrand <hta@webrtc.org> Reviewed-by: Evan Shrubsole <eshr@webrtc.org> Cr-Commit-Position: refs/heads/main@{#43788}

Upstream commit: https://webrtc.googlesource.com/src/+/9f68535e68bbb4505fe2897952202ff20f682b9d Fix setParameters() throwing when level-id does not match. In order to align with this PR[1], setParameters() should not throw if the H265 level ID we're trying to send does not match what was negotiated. This was believed to be fixed by [2] but we were still throwing due to a check on a different layer (media_engine.cc). In order to reproduce the issue despite WebRTC lacking SW encoder/decoder for H265, peer_connection_encodings_integrationtest.cc gets a new test with real stack but fake encoder/decoder factory. This allows negotiating H265 and doing SetParameters() even though the codec is not processing any frames. - Basic test coverage is added for singlecast and simulcast H265. - Test coverage for the bug being fixed added. - In Chrome the equivalent WPTs exists for when real HW is available here[3]. Those tests PASS with this CL (currently FAIL). [1] w3c/webrtc-pc#3023 [2] https://webrtc-review.googlesource.com/c/src/+/368781 [3] https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/webrtc/protocol/h265-level-id.https.html Bug: chromium:381407888 Change-Id: I3619a124586b8b26d3695cfad8890cf40bd475db Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/374164 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Henrik Boström <hbos@webrtc.org> Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org> Reviewed-by: Jianlin Qiu <jianlin.qiu@intel.com> Cr-Commit-Position: refs/heads/main@{#43759}

Upstream commit: https://webrtc.googlesource.com/src/+/79e5e721b54b3821f33be96bda3f1be69429cd53 Add unidirectional codec support ("offer to send" use case). This CL implements allowing sendonly codecs in setCodecPreferences(), i.e. this spec PR: w3c/webrtc-pc#3018. It also makes the setCodecPreferences() ignore level IDs in the filtering algorithm (but not in the sCP method call) as per this spec PR: w3c/webrtc-pc#3023. In short, before this CL, setCodecPreferences() threw an exception if a codec was preferred that is not present in receiver codec capabilities. After this CL, setCodecPreferences() allows you to prefer codecs that are *either* in the sender capabilities *or* the receiver capabilities. - This allows you to "offer to send", i.e. prefer sendonly codecs on a sendonly transceiver. - The filtering on direction is handled by RtpTransceiver::filtered_codec_preferences() which is called during SDP offer/answer (sdp_offer_answer.cc). Also as per spec changes, if this filtering results in not having any codecs to offer or answer then this results in not having any codec preferences as opposed to throwing an exception (old behavior). - Two old peer_connection_media_unittest.cc tests are updated to reflect the API failing less. This CL adds both unit tests (rtp_transceiver_unittest.cc) and full stack integration tests (peer_connection_encodings_integrationtest.cc). It also makes us pass the following Web Platform Tests in Chrome: https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/webrtc/protocol/h265-level-id.https.html Bug: chromium:381407888 Change-Id: I98a5ad1acccb56db0538e4d47975b8a725102c33 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/374520 Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org> Commit-Queue: Henrik Boström <hbos@webrtc.org> Reviewed-by: Harald Alvestrand <hta@webrtc.org> Reviewed-by: Evan Shrubsole <eshr@webrtc.org> Cr-Commit-Position: refs/heads/main@{#43788}

Upstream commit: https://webrtc.googlesource.com/src/+/9f68535e68bbb4505fe2897952202ff20f682b9d Fix setParameters() throwing when level-id does not match. In order to align with this PR[1], setParameters() should not throw if the H265 level ID we're trying to send does not match what was negotiated. This was believed to be fixed by [2] but we were still throwing due to a check on a different layer (media_engine.cc). In order to reproduce the issue despite WebRTC lacking SW encoder/decoder for H265, peer_connection_encodings_integrationtest.cc gets a new test with real stack but fake encoder/decoder factory. This allows negotiating H265 and doing SetParameters() even though the codec is not processing any frames. - Basic test coverage is added for singlecast and simulcast H265. - Test coverage for the bug being fixed added. - In Chrome the equivalent WPTs exists for when real HW is available here[3]. Those tests PASS with this CL (currently FAIL). [1] w3c/webrtc-pc#3023 [2] https://webrtc-review.googlesource.com/c/src/+/368781 [3] https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/webrtc/protocol/h265-level-id.https.html Bug: chromium:381407888 Change-Id: I3619a124586b8b26d3695cfad8890cf40bd475db Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/374164 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Henrik Boström <hbos@webrtc.org> Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org> Reviewed-by: Jianlin Qiu <jianlin.qiu@intel.com> Cr-Commit-Position: refs/heads/main@{#43759}

Upstream commit: https://webrtc.googlesource.com/src/+/79e5e721b54b3821f33be96bda3f1be69429cd53 Add unidirectional codec support ("offer to send" use case). This CL implements allowing sendonly codecs in setCodecPreferences(), i.e. this spec PR: w3c/webrtc-pc#3018. It also makes the setCodecPreferences() ignore level IDs in the filtering algorithm (but not in the sCP method call) as per this spec PR: w3c/webrtc-pc#3023. In short, before this CL, setCodecPreferences() threw an exception if a codec was preferred that is not present in receiver codec capabilities. After this CL, setCodecPreferences() allows you to prefer codecs that are *either* in the sender capabilities *or* the receiver capabilities. - This allows you to "offer to send", i.e. prefer sendonly codecs on a sendonly transceiver. - The filtering on direction is handled by RtpTransceiver::filtered_codec_preferences() which is called during SDP offer/answer (sdp_offer_answer.cc). Also as per spec changes, if this filtering results in not having any codecs to offer or answer then this results in not having any codec preferences as opposed to throwing an exception (old behavior). - Two old peer_connection_media_unittest.cc tests are updated to reflect the API failing less. This CL adds both unit tests (rtp_transceiver_unittest.cc) and full stack integration tests (peer_connection_encodings_integrationtest.cc). It also makes us pass the following Web Platform Tests in Chrome: https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/webrtc/protocol/h265-level-id.https.html Bug: chromium:381407888 Change-Id: I98a5ad1acccb56db0538e4d47975b8a725102c33 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/374520 Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org> Commit-Queue: Henrik Boström <hbos@webrtc.org> Reviewed-by: Harald Alvestrand <hta@webrtc.org> Reviewed-by: Evan Shrubsole <eshr@webrtc.org> Cr-Commit-Position: refs/heads/main@{#43788}

Upstream commit: https://webrtc.googlesource.com/src/+/9f68535e68bbb4505fe2897952202ff20f682b9d Fix setParameters() throwing when level-id does not match. In order to align with this PR[1], setParameters() should not throw if the H265 level ID we're trying to send does not match what was negotiated. This was believed to be fixed by [2] but we were still throwing due to a check on a different layer (media_engine.cc). In order to reproduce the issue despite WebRTC lacking SW encoder/decoder for H265, peer_connection_encodings_integrationtest.cc gets a new test with real stack but fake encoder/decoder factory. This allows negotiating H265 and doing SetParameters() even though the codec is not processing any frames. - Basic test coverage is added for singlecast and simulcast H265. - Test coverage for the bug being fixed added. - In Chrome the equivalent WPTs exists for when real HW is available here[3]. Those tests PASS with this CL (currently FAIL). [1] w3c/webrtc-pc#3023 [2] https://webrtc-review.googlesource.com/c/src/+/368781 [3] https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/webrtc/protocol/h265-level-id.https.html Bug: chromium:381407888 Change-Id: I3619a124586b8b26d3695cfad8890cf40bd475db Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/374164 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Henrik Boström <hbos@webrtc.org> Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org> Reviewed-by: Jianlin Qiu <jianlin.qiu@intel.com> Cr-Commit-Position: refs/heads/main@{#43759}

Upstream commit: https://webrtc.googlesource.com/src/+/79e5e721b54b3821f33be96bda3f1be69429cd53 Add unidirectional codec support ("offer to send" use case). This CL implements allowing sendonly codecs in setCodecPreferences(), i.e. this spec PR: w3c/webrtc-pc#3018. It also makes the setCodecPreferences() ignore level IDs in the filtering algorithm (but not in the sCP method call) as per this spec PR: w3c/webrtc-pc#3023. In short, before this CL, setCodecPreferences() threw an exception if a codec was preferred that is not present in receiver codec capabilities. After this CL, setCodecPreferences() allows you to prefer codecs that are *either* in the sender capabilities *or* the receiver capabilities. - This allows you to "offer to send", i.e. prefer sendonly codecs on a sendonly transceiver. - The filtering on direction is handled by RtpTransceiver::filtered_codec_preferences() which is called during SDP offer/answer (sdp_offer_answer.cc). Also as per spec changes, if this filtering results in not having any codecs to offer or answer then this results in not having any codec preferences as opposed to throwing an exception (old behavior). - Two old peer_connection_media_unittest.cc tests are updated to reflect the API failing less. This CL adds both unit tests (rtp_transceiver_unittest.cc) and full stack integration tests (peer_connection_encodings_integrationtest.cc). It also makes us pass the following Web Platform Tests in Chrome: https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/webrtc/protocol/h265-level-id.https.html Bug: chromium:381407888 Change-Id: I98a5ad1acccb56db0538e4d47975b8a725102c33 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/374520 Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org> Commit-Queue: Henrik Boström <hbos@webrtc.org> Reviewed-by: Harald Alvestrand <hta@webrtc.org> Reviewed-by: Evan Shrubsole <eshr@webrtc.org> Cr-Commit-Position: refs/heads/main@{#43788}

In order to align with this PR[1], setParameters() should not throw if the H265 level ID we're trying to send does not match what was negotiated. This was believed to be fixed by [2] but we were still throwing due to a check on a different layer (media_engine.cc). In order to reproduce the issue despite WebRTC lacking SW encoder/decoder for H265, peer_connection_encodings_integrationtest.cc gets a new test with real stack but fake encoder/decoder factory. This allows negotiating H265 and doing SetParameters() even though the codec is not processing any frames. - Basic test coverage is added for singlecast and simulcast H265. - Test coverage for the bug being fixed added. - In Chrome the equivalent WPTs exists for when real HW is available here[3]. Those tests PASS with this CL (currently FAIL). [1] w3c/webrtc-pc#3023 [2] https://webrtc-review.googlesource.com/c/src/+/368781 [3] https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/webrtc/protocol/h265-level-id.https.html Bug: chromium:381407888 Change-Id: I3619a124586b8b26d3695cfad8890cf40bd475db Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/374164 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Henrik Boström <hbos@webrtc.org> Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org> Reviewed-by: Jianlin Qiu <jianlin.qiu@intel.com> Cr-Commit-Position: refs/heads/main@{#43759}

…al level-id in SDP answers., a=testonly Automatic update from web-platform-tests Add WPTs for negotiating H265 with minimal level-id in SDP answers. Add test coverage for w3c/webrtc-pc#3023 which unblocks merging the PR (it has "editors can integrate"). Specifically it should be possible to negotiate H265 even if the level-id is downgraded in the SDP answer (not throwing on level-id mismatch). - H265 is behind flags so a virtual test suite is added. - If bot lacks HW capabilities to do H265, the tests will PRECONDITION_FAILED. To avoid reverting tests we will allow the bots to both pass and fail, I filed crbug.com/388299759. Some of the tests FAIL even when they run: passing these tests will be covered by crbug.com/381407888. Bug: chromium:381407888, webrtc:41480904, chromium:388299759 Change-Id: Ie017560b4310418a4c9ed854dcb09136b9b446e7 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6148192 Reviewed-by: David Baron <dbaron@chromium.org> Commit-Queue: Henrik Boström <hbos@chromium.org> Reviewed-by: Evan Shrubsole <eshr@google.com> Cr-Commit-Position: refs/heads/main@{#1404052} -- wpt-commits: 545a2ed81a38330f024fac8c0b139739a7329097 wpt-pr: 49990

Allow level-id to be different in codec match

c757b5f

henbos requested a review from aboba November 21, 2024 11:51

henbos added 4 commits November 21, 2024 12:52

grammar

2473be4

Update amendments

68f15e1

Not testable?

d137450

Trial and error

0aea1b3

taste1981 reviewed Nov 21, 2024

View reviewed changes

webrtc.html Show resolved Hide resolved

henbos added 2 commits November 21, 2024 13:10

..

7197ba0

Order and default

5fb5525

alvestrand reviewed Nov 21, 2024

View reviewed changes

webrtc.html Outdated Show resolved Hide resolved

henbos added 2 commits November 21, 2024 15:44

Rewording and grammar fix

a81bd7e

nit

46142bd

henbos commented Nov 21, 2024

View reviewed changes

webrtc.html Outdated Show resolved Hide resolved

henbos commented Nov 21, 2024

View reviewed changes

amendments.json Outdated Show resolved Hide resolved

henbos added 2 commits November 22, 2024 10:34

Significant rework of PR

3636bc6

...

adc8a46

aboba mentioned this pull request Nov 22, 2024

Codec negotiation and level IDs #3020

Closed

aboba requested changes Nov 22, 2024

View reviewed changes

webrtc.html Show resolved Hide resolved

webrtc.html Outdated Show resolved Hide resolved

henbos added 2 commits November 28, 2024 15:32

Merge branch 'main' into 241121_LevelId

38b106c

Update wording

0cc5068

alvestrand reviewed Nov 28, 2024

View reviewed changes

webrtc.html Show resolved Hide resolved

Update webrtc.html

d0e97ad

Co-authored-by: Harald Alvestrand <hta+github@alvestrand.no>

alvestrand approved these changes Nov 28, 2024

View reviewed changes

henbos commented Dec 2, 2024

View reviewed changes

webrtc.html Show resolved Hide resolved

jan-ivar approved these changes Dec 5, 2024

View reviewed changes

webrtc.html Show resolved Hide resolved

jan-ivar added Needs Test Needs a WPT test Editors can integrate labels Dec 5, 2024

henbos commented Dec 11, 2024

View reviewed changes

webrtc.html Outdated Show resolved Hide resolved

chromium-wpt-export-bot mentioned this pull request Jan 9, 2025

Add WPTs for negotiating H265 with minimal level-id in SDP answers. web-platform-tests/wpt#49990

Merged

Add WPT reference and address comments

fa63f7e

henbos merged commit 23d37fc into w3c:main Jan 9, 2025
3 checks passed

henbos removed the Needs Test Needs a WPT test label Jan 9, 2025

Allow level-id to be different in codec match #3023

Allow level-id to be different in codec match #3023

Uh oh!

Conversation

henbos commented Nov 21, 2024 • edited by pr-preview bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

henbos commented Nov 21, 2024

Uh oh!

Uh oh!

Uh oh!

fippo commented Nov 21, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

henbos commented Nov 21, 2024

Uh oh!

henbos commented Nov 21, 2024

Uh oh!

Uh oh!

Uh oh!

henbos commented Nov 22, 2024

Uh oh!

henbos commented Nov 22, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

henbos commented Jan 9, 2025

Uh oh!

henbos commented Jan 9, 2025

Uh oh!

Uh oh!

henbos commented Jan 9, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

henbos commented Nov 21, 2024 •

edited by pr-preview bot

Loading

fippo commented Nov 21, 2024 •

edited

Loading

henbos commented Nov 22, 2024 •

edited

Loading