You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This logic here is not quite right. Whenever dealing with Audio and Video it will always return VideoStream when reached here even if the ssrc belongs actually to some AudioStream. This causes the VideoStream to receive RTPPacket which is not a video packet and it reaches to a point where RemoteEndPoint is adjusted and (Video) RemoteTrack.Ssrc will be set to hdr.SyncSource (Audio) which causes audio packets to be treated by VideoEncoder and having warnings all over the place: "Video depacketisation logic for codec PCMU has not been implemented, PR's welcome!".
I guess it is safe to return AudioStream when only HasAudio is true, return VideoStream in the else statement as it was before the change. Because when GetMediaStream (by ssrc) return null it's okay, because right after that it will try to get GetMediaStreamFromPayloadType which has found the correct stream in my cases.
The original code was giving me repeating errors about being unable to find a media stream
Could we not just remove this logic entirely? It seems pretty hacky - just let GetMediaStreamFromPayloadType sort it out if that's the fallback?
I would not mind removing it entirely. Since for RTPPackets there is a fallback as you mentioned as well using GetMediaStreamFromPayloadType and for RTCPPackets the fallback should be GetMediaStream (by RTCPCompoundPacket).
Do you mean removing the block below? That would make sense to me. I'd say the only exception would be if there is only a single media stream it should be returned but then that could be the first check without any need for ssrc matching attempts.
if (HasAudio)
{
if (!HasVideo)
{
return AudioStream;
}
}
if (HasVideo)
{
return VideoStream;
}
Originally posted by @xBasov in 09555fb
The text was updated successfully, but these errors were encountered: