Fix H.264 codec matching

[ladvoc]

Addresses an issue with H.264 streams using packetization-mode=0. This affects tracks published between two cloud regions and all video tracks published by the ESP32 SDK.

Root cause: the platform hardware decoder is not recognized as supporting H.264 streams with packetization-mode=0 because the codec matching logic treats different packetization modes as entirely distinct codecs. As a result, no compatible decoder is found and none is created. Packets are received but have no decoder to process them, so no frames are ever emitted to the user. Other SDKs (Swift, web, etc.) did not have the same issue.

[theomonnom]

Ok to ignore packetization-mode, but I don't think we should ignore profile-level-id

[theomonnom]

mmh actually are we sure about that: https://datatracker.ietf.org/doc/html/rfc6184#section-5.4

[xianshijing-lk]

I might miss some logic consideration here.
Just want to make sure, should it be
factory->Create(env, adjusted);
rather than
return factory->Create(env, format);

[boks1971]

AFAIU, packetization-mode=1 should be able to decode packetization-mode=0 also. So, it should be okay to search for a match as long as the decoder is capable of decoding packetization-mode=1. However, if supported formats does not have packetization-mode, erasing it and searching without it might be risky, i. e. if the supported formats only supports mode=0 (implicit default), searching for match after erasing would match mode=1 also and that would not work. In that case, I am thinking packetization-mode=0 should be used for search.

[boks1971]

AFAIU, packetization-mode=1 should be able to decode packetization-mode=0 also. So, it should be okay to search for a match as long as the decoder is capable of decoding packetization-mode=1. However, if supported formats does not have packetization-mode, erasing it and searching without it might be risky, i. e. if the supported formats only supports mode=0 (implicit default), searching for match after erasing would match mode=1 also and that would not work. In that case, I am thinking packetization-mode=0 should be used for search.

Would be good to test in case there are decoders who support only mode=1 exist, but maybe hard to find.

[ladvoc]

I added end-to-end testing for video streaming in #937 to give us more confidence in this change and future changes affecting the video layer. However, as noted in that PR, only VP8 and VP9 can currently be tested in CI, so I will run manually on different platforms to verify the H.264 and H.265 paths.