use case:disable A/V sync for remote control or online gaming

[bdrtc]

sometimes online cloud gaming or remote control need very low video latency, they may need playout delay video extension in sender side , and set the min/max delay to 0 as describe in playout-delay draft

but it only control video delay and is best effort, it will also be affected by audio and video synchronization, in this case, user need disable A/V sync for low interactive delay of video.

[fippo]

I don't think there is action needed, it is already possible to not enable AV sync.

[bdrtc]

yes, it's possible by change sdp, i do't think it's a good way, most users may do't kown how to achive this by default and even do't kown disable A/V sync will optimaze such use cases.

[henbos]

The A/V sync group is controlled by the stream group though, so if you don't want the two tracks to be synced and don't want to SDP munge, can you not simply not put them in the same stream? E.g.

pc.addTrack(audioTrack, new MediaStream([audioTrack]);
pc.addTrack(videoTrack, new MediaStream([videoTrack]);

Or simply omit the optional stream argument

[bdrtc]

The A/V sync group is controlled by the stream group though, so if you don't want the two tracks to be synced and don't want to SDP munge, can you not simply not put them in the same stream? E.g.

pc.addTrack(audioTrack, new MediaStream([audioTrack]);
pc.addTrack(videoTrack, new MediaStream([videoTrack]);

Or simply omit the optional stream argument

great, that make sence, summarize it here for those may have such requirement for low interactive delay scenario

1. use playout-delay extension in sender end.
2. disable A/V sync in receiver end.

[henbos]

I may lack context but I don't think the receiver should be the one to disable A/V sync, if the sender sets the sync group up correctly (=meaning no sync group) then the receiver can just accept what they are offered, no need for special logic or having different stream groups on different endoints.

[bdrtc]

I may lack context but I don't think the receiver should be the one to disable A/V sync, if the sender sets the sync group up correctly (=meaning no sync group) then the receiver can just accept what they are offered, no need for special logic or having different stream groups on different endoints.

in p2p mode this is ok, but in sfu mode it's hop by hop not end2end negotiation. perform it in receiver maybe more suitable

[fippo]

on the receive side this is controlled by what the values of the msid field in the SDP are. What a SFU (or another server) puts there is not controllable via a browser API.

[bdrtc]

Yes, both ways are possible, depending on implementation preference, since there is already solution for this, close this issue， Thanks @henbos @fippo 🥇 .