m-line ordering doesn't match order of added tracks #1476
Description
I am receiving an a/v stream from devices using a proprietary protocol and then restreaming via webrtc. The devices do not advertise anything about the audio and video they include upfront. The only way to determine is to wait until I get a video frame or audio from the stream and get the codec etc. from a special header on each frame. What I've been doing is when I see either audio or video for the first time I'm doing AddTrack.
My primary issue is that these devices usually send video first, and audio starts coming in later. When I add audio later and try to renegotiate sdp, doing RTCPeerConnection.createOffer is creating an SDP where the audio m-line is always first. That's resulting in the browser erroring during renegotiation with The order of m-lines in subsequent offer doesn't match order from previous offer/answer.. GetSessionDescription(List<MediaStream> mediaStreamList, IPAddress connectionAddress) in RTPSession always loops the audio tracks first when generating sdp and not the order in which tracks were added. Is there anyway to control this? In some cases, the devices also completely change audio or video codec / capabilities midstream, so ideally I'd just add a new audio or video track and deactivate the old ones, but adding a new audio track would still add in between the prior audio + video mlines.
Any suggestions? From what I can tell, listing audio m-lines after video m-lines in sdp should be valid, but the timing at which that information is available to me complicates things when the audio m-lines are always generated first in the sdp. I can't just wait until I receive audio to create the offer because in about 30% of cases, the device doesn't even have audio that will come in.