9f68535e68
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] https://github.com/w3c/webrtc-pc/pull/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}