Open neilyoung opened 2 years ago
A possible fix would be to alter the convertToCodecDefinition function:
if (!r[codec.toUpperCase()])
r[codec.toUpperCase()] = {
num: typeNum,
codec: codec
}
This would always keep the FIRST appearance of the codec, not the LAST
Updated my PR
Well, it is not a good style to abuse a PR for a completely unrelated project for stalking, just out of curiosity: Why would you like to know my eMail?
...if the m= line contains multiple codecs of the same kind. In this case the last is found by convertToCodecDefinition, which is especially w.r.t. H.264 not always the best choice.
Ex.
m=video 9 UDP/TLS/RTP/SAVPF 96 97 98 99 100 101 102 121 127 120 125 107 108 109 35 36 124 119 123 118 114 115 116
The only VP8 codec here is 96, hence it will be found if VP8 is perferred.
But - 102, 127, 125, 108, 124, 123 are all H.264 codecs, with very different profile-level-ids and modes. In this case not the first one is chosen, but the last one in the m list, which is 123, which is a very uncommon H.264 format. Even though it is advertised by chrome like so, the video connection cannot be established, if 123 is favoured.
a=fmtp:123 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=640032