Investigate AV1 issues with downlink packet loss

[jmillan]

When applying downlink packet loss on the consuming endpoint (ie: 10%), there are a lot of video freezes.

Setting the Dependency Description extension to recvonly seems to fix the problem. However, setting recvonly direction does not allow properly handling AV1 SVC within pipe transports.

STR:

• Set sendrecv direction for the extension header in supportedRtpCapabilities.ts.
• Start a chrome tab sending a AV1 stream (in mediasoup demo: ?forceAV1=true).
• Start another chrome tab (in another machine) receiving such AV1 stream.
• Apply download network packet loss on the machine receiving the AV1 stream (ie: 10%).

Related webrtc issue.

Due to this issue, the header extension must for now be set as recvonly and hence pipe producer won't receive it. This means that AV1 won't work properly within pipe transports.

We need to discard whether the indicated is a Chrome issue or it's somehow? related to us.

[jiyeyuran]

What's the difference between our AV1 implementation and LiveKit's? LiveKit doesn't seem to have this issue: livekit/livekit#942

[ibc]

LiveKit doesn't seem to have this issue

LiveKit probably has the very same issue but they don't know it, or they haven't tested how it works when there is packet loss, or they haven't documented the problem in that PR.

[jiyeyuran]

LiveKit doesn't seem to have this issue

LiveKit probably has the very same issue but they don't know it, or they haven't tested how it works when there is packet loss, or they haven't documented the problem in that PR.

I just tested using LiveKit's demo. With a 20% packet loss setting, there is a bit of video freezes, but it won't get stuck. Test address: https://meet.livekit.io/rooms/whln-z760?codec=av1

[ibc]

I just tested using LiveKit's demo. With a 20% packet loss setting, there is a bit of video freezes, but it won't get stuck. Test address: https://meet.livekit.io/rooms/whln-z760?codec=av1

Thanks. We will come back to this after summer.