[BUG]: Unity is crashing when receiving a video

[theomonnom]

Package version

2.4.0-exp.5

Environment

* OS: Windows 11
* Unity version: Unity 2020.3

Steps To Reproduce

The following code displays the video on the screen but sometimes crashes for no reason

peer.OnTrack = e => {
    if (e.Track.Kind == TrackKind.Video)
    {
        (e.Track as VideoStreamTrack).OnVideoReceived += tex => 
        {
            rawImage.texture = tex;
        };
    }
};

Current Behavior

The thread tried to read from or write to a virtual address for which it does not have the appropriate access.

========== OUTPUTTING STACK TRACE ==================

0x00007FF8F8D4FC90 (nvwgf2umx) OpenAdapter12
0x00007FF8F7F39221 (nvwgf2umx) NVENCODEAPI_Thunk
0x00007FF8F876EDE1 (nvwgf2umx) cask::SafeEnum<cask::md::Algorithm_ENUMCLASS_SCOPEWRAPPER>::operator=
0x00007FF8F875DE97 (nvwgf2umx) cask::SafeEnum<cask::md::Algorithm_ENUMCLASS_SCOPEWRAPPER>::operator=
0x00007FF96DF8FEC0 (d3d11) CreateDirect3D11SurfaceFromDXGISurface
0x00007FF753485CE9 (Unity) GfxDeviceD3D11Base::InsertPluginTextureUpdateCallback
0x00007FF75547C3BE (Unity) GfxDeviceWorker::RunCommand
0x00007FF755482BED (Unity) GfxDeviceWorker::RunExt
0x00007FF755482D08 (Unity) GfxDeviceWorker::RunGfxDeviceWorker
0x00007FF753B1F335 (Unity) Thread::RunThreadWrapper
0x00007FF976C254E0 (KERNEL32) BaseThreadInitThunk
0x00007FF97810485B (ntdll) RtlUserThreadStart

Expected Behavior

No response

Anything else?

No response

EDIT: The bug isn't there in 2.4.0-exp.4 when using VideoStreamTrack.InitializeReceiver(w, h) EDIT x2: The bug isn't there when Hardware decoder is enabled

[azable]

Same issue here (sporadic crashes on video receive)

Not sure if this is related, but incidentally I noticed the height of the received texture is much larger than the actual sent video height, while the width is correct. In one example on my end the sent video size is 1280 x 360, and the received texture size is 1280 x 129600 (!!). This value also happens to be the square of the height, but that could be a coincidence.

[karasusan]

@FeepsDev @alzab Hardware decoder is not supported on Windows yet. How do you reproduce the issue?

[azable]

In my case I was just using the software decoder (and also software encoder on the sender side).

I realised what seems to trigger it is "reconnecting" with a different size video stream on the same RTCPeerConnection. I worked around it by creating a new RTCPeerConnection every time there is a reconnection with a new sender, which might be the preferable way to handle this situation anyway in terms of WebRTC protocols.

Edit: and also, don't worry about the strange height I reported, that was my mistake (accidentally had *360 in the debug log outputs)

[karasusan]

Edit: and also, don't worry about the strange height I reported, that was my mistake (accidentally had *360 in the debug log outputs)

It was a big surprise to me. 😅

I realised what seems to trigger it is "reconnecting" with a different size video stream on the same RTCPeerConnection. I worked around it by creating a new RTCPeerConnection every time there is a reconnection with a new sender, which might be the preferable way to handle this situation anyway in terms of WebRTC protocols.

Got it. The use case as you said we haven't tested. I will test it.

[kannan-xiao4]

memo: WRS-236