Bug Crash WindowsVideoTextureOutput::ReleaseDrawnSamples(bool)

Hello, I have unity-crash on a video-player release (?) in my game.


This was on
Unity 2020.3.44f1
- UnityPlayer_Win64_mono_x64.pdb,
Attaching crash.dmp and Player.log.

A built player without dev-build, no specific settings:


I have some TV screens used in the game for various reasons, on which I use the video player to play videos on them.

 

Not consistent, but this is the second time it has happened.

-> I have three video players;
2 of which are loaded all the time, and should never be destroyed/deleted.
They are playing in the background on low quality at all times, being displayed on different TVs in different rooms, and sharing the same material/texture.

1 of which is within a prefab that contains a specific room in the game.
Like this:
Scene 1:
-> Room Loader (script)
-> Map Pool (game object)
-> -> Room A (prefab instantiated from RoomLoader on scene load)
-> -> -> Lights
-> -> -> Objects
-> -> -> etc, etc.
-> -> Room B (prefab instantiated from RoomLoader on scene load) <----- (Contains a video player)
-> -> Room C (prefab instantiated from RoomLoader on scene load)

I'm simply reloading the scene on death, which is what I did, and then slightly after, the game crashed, like 10 seconds into playing the scene for a second time. So I would guess it's something to do with this video player instance.

> The "Cannot Play a disabled VideoPlayer" log is when you run: Videplayer.Play() on a disabled game object. I don't think it's related?

> Is it only happening in a build or in the Editor too?
I have only gotten this two times, and it's in the build (so far).
I've had the editor crash on me, but I have not investigated, so it could've been happening without me knowing it.

 

It's happening every time... Sometimes it takes just a bit longer (5 sec -> 60 sec) after reloading after death.

 

https://issuetracker.unity3d.com/is...518.39787500.1675532425-1024917989.1621288872

> Reworked order of execution
probably come from here

 

I don't know, I'm just thinking reworking the order of execution often breaks things.
And it matches the versions for the bug you sent, and my version.

 

I wish I could see the code, it's a null ptr error. It should not require a reproducible project to be fixed, a unit test should be possible to trigger this crash.

 

Any news on this?

 

Just saw this, we have the same problem in Windows builds on Unity 2022.2.6. We have multiple video players with low quality video on background tvs in the game, which are set to loop and are rendering into a render texture.
During the 2022.2 beta, having multiple video players running simultaneously was crippling the framerate and it was fixed I think close to the RC. The build we made after didn’t have the same problems, so I think it must be something that changed in the last 1,5 months or so.

This only happens in builds by the way, and in our case its a debug build. The scene the videos are in crashes every single time after a couple of seconds to one minute after loading it.

Disabling the video players stops the crashes. (I mean that one is kinda obvious, but it's clear that it's an issue with the video player)

Edit: I attached the minidump & Player log

 

Awesome!

 

Any news on this? (Sorry for bugging you, but I have a demo coming up soon )

 

Thank you for the suggestion, for some reason, that didn't enter my mind. Thank you!
It didn't trigger now during a full playthrough on 2020.3.42f1.

EDIT: still not triggering after multiple runthroughs

 

I'm also having this issue in Unity 2021.3.14f1, only ever happens in a build not in the editor.

If I'm correct, the "Rework" was deployed to 2021.3.16f1 so I'm not sure if this is the cause?

 

We now also had a crash (using latest 2022.2.8f). Windows PC, Development Build.

 

We now also had a crash (using latest 20221.3.19f1). Windows PC, IL2CCP Build.

========== OUTPUTTING STACK TRACE ==================
0x00007FFDFDBF8CA1 (UnityPlayer) [C:\build\output\unity\unity\Modules\Video\Public\Media\WindowsMedia\WindowsVideoTextureOutput.cpp:1761] WindowsVideoTextureOutput::ReleaseDrawnSamples
0x00007FFDFDBF406E (UnityPlayer) [C:\build\output\unity\unity\Modules\Video\Public\Media\WindowsMedia\WindowsVideoMedia.cpp:3278] WindowsVideoMedia::GetFirstReadyTextureTime
0x00007FFDFDE9ED26 (UnityPlayer) [C:\build\output\unity\unity\Modules\Video\Public\Base\VideoMediaOutput.cpp:1206] VideoMediaTextureOutput::ConsumeFrame
0x00007FFDFDBE44D2 (UnityPlayer) [C:\build\output\unity\unity\Modules\Video\Public\Base\VideoMediaPlayback.cpp:1724] VideoClipPlayback::GetTextureAtTimeInternal
0x00007FFDFDBE8FC1 (UnityPlayer) [C:\build\output\unity\unity\Modules\Video\Public\Base\MediaComponent.cpp:316] VideoPlayback::GetTexture
0x00007FFDFDBE164B (UnityPlayer) [C:\build\output\unity\unity\Modules\Video\Public\VideoPlayer.cpp:1730] VideoPlayer::VideoUpdate
0x00007FFDFDBE152D (UnityPlayer) [C:\build\output\unity\unity\Modules\Video\Public\VideoManager.cpp:370] VideoManager::VideoUpdate
0x00007FFDFD3D4F1A (UnityPlayer) [C:\build\output\unity\unity\Runtime\Misc\PlayerLoop.cpp:384] ExecutePlayerLoop
0x00007FFDFD3D4FC0 (UnityPlayer) [C:\build\output\unity\unity\Runtime\Misc\PlayerLoop.cpp:408] ExecutePlayerLoop
0x00007FFDFD3D78E8 (UnityPlayer) [C:\build\output\unity\unity\Runtime\Misc\PlayerLoop.cpp:514] PlayerLoop
0x00007FFDFD5CC92A (UnityPlayer) [C:\build\output\unity\unity\PlatformDependent\WinPlayer\WinMain.cpp:329] PerformMainLoop
0x00007FFDFD5CB65B (UnityPlayer) [C:\build\output\unity\unity\PlatformDependent\WinPlayer\WinMain.cpp:1260] MainMessageLoop
0x00007FFDFD5CFE37 (UnityPlayer) [C:\build\output\unity\unity\PlatformDependent\WinPlayer\WinMain.cpp:1777] UnityMainImpl
0x00007FFDFD5D199B (UnityPlayer) [C:\build\output\unity\unity\PlatformDependent\WinPlayer\WinMain.cpp:1817] UnityMain
0x00007FF7285211F2 (FA) [d:\agent\_work\63\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288] __scrt_common_main_seh
0x00007FFE53937614 (KERNEL32) BaseThreadInitThunk
0x00007FFE54C226A1 (ntdll) RtlUserThreadStart
========== END OF STACKTRACE ===========

 

Any updates on this?

 

Just reporting that I get the same crash when testing a build of my game using the latest Unity 2020.3.45f1 on Win 10 v1909.

The game has a full screen background video running on repeat, with another video running for the game logo overlaid on the background. This is all in the home scene menu (i.e. UI stuff only).

Stack trace:

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

0x00007FFC8B38D071 (UnityPlayer) WindowsVideoTextureOutput::ReleaseDrawnSamples
0x00007FFC8B38889E (UnityPlayer) WindowsVideoMedia::GetFirstReadyTextureTime
0x00007FFC8B646F52 (UnityPlayer) VideoMediaTextureOutput::GetFirstReadyPresentationTime
0x00007FFC8B37B0F4 (UnityPlayer) VideoClipPlayback::GetTextureNoSkipInternal
0x00007FFC8B37EF9A (UnityPlayer) VideoPlayback::GetTexture
0x00007FFC8B3A214B (UnityPlayer) VideoPlayer::VideoUpdate
0x00007FFC8B3A202D (UnityPlayer) VideoManager::VideoUpdate
0x00007FFC8AE0516A (UnityPlayer) ExecutePlayerLoop
0x00007FFC8AE05210 (UnityPlayer) ExecutePlayerLoop
0x00007FFC8AE094A8 (UnityPlayer) PlayerLoop
0x00007FFC8ABC69DA (UnityPlayer) PerformMainLoop
0x00007FFC8ABC4EAB (UnityPlayer) MainMessageLoop
0x00007FFC8ABC9F02 (UnityPlayer) UnityMainImpl
0x00007FFC8ABCB0AB (UnityPlayer) UnityMain
0x00007FF669A911F2 (Drone Warfare) __scrt_common_main_seh
0x00007FFCCB547C24 (KERNEL32) BaseThreadInitThunk
0x00007FFCCC98D721 (ntdll) RtlUserThreadStart

========== END OF STACKTRACE ===========

Alternative stack trace after fiddling around with video formats (changed from VP8 to Auto - source videos are H264 Baseline Profile) but still crashes:

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

0x00007FFF901A7AEA (UnityPlayer) WindowsVideoTextureOutput::Flush
0x00007FFF901ADF68 (UnityPlayer) WindowsVideoMedia::SetSecPosition
0x00007FFF9019A880 (UnityPlayer) VideoClipPlayback::ExecuteLoop
0x00007FFF8FBF2DD6 (UnityPlayer) JobQueue::Exec
0x00007FFF8FBF2FFE (UnityPlayer) JobQueue::ExecuteJobFromHighPriorityStack
0x00007FFF8FBF3496 (UnityPlayer) JobQueue:rocessJobs
0x00007FFF8FBF4B40 (UnityPlayer) JobQueue::WorkLoop
0x00007FFF8FCECA08 (UnityPlayer) Thread::RunThreadWrapper
0x00007FFFF5E57C24 (KERNEL32) BaseThreadInitThunk
0x00007FFFF78AD721 (ntdll) RtlUserThreadStart

========== END OF STACKTRACE ===========

 

Can you confirm that this issue is being worked on? This is a ship-killer for us, and it has been more than a month. Thank you

 

We downgraded to Unity 2020.3.42f1 as a temporary fix and we haven't seen this issue since.

Does anyone know if there is a bug report for this?

 

We are on 2022.2, and while downgrading helps regarding that issue, several other issues we had were fixed in the past couple releases and it's unfortunately not an option for us... I don't know regarding the bug report.

 

Great! Thank you!

 

Hi, that issue tracker states this bug isn't reproducible with 2020.3.43, and there's no mention of upcoming fixes for the 2020 branch, but I have this issue (shown a few posts above) with 2020.3.45.

In fact your above advice to downgrade to the 2020.3.42 version infers that the issue started with version 2020.3.43 and has needed fixing since then.

I know that 2020 LTS is planned to end soon, but this is pretty much a show-stopping bug that negates all improvements and fixes since the 2020.3.42 release, so please can you consider looking at fixing this for the 2020 LTS branch too?.

Thanks!

 

That's brilliant news thanks!

 

I think I'm seeing this on a major project we're delivering imminently. It's a major museum exhibit that opens to the public 31st March, and they've sold tens of thousands of tickets already, so I can't just wait for this to be fixed. Talk about stress.

We're using 2022.2.5f1 and have two VideoPlayers that are rendering to two different RenderTextures. They are looping. Occasionally we set the .time to make them loop using custom loop points (rather than allowing the video player to loop, this won't work for us).

We can't downgrade to 2020 due to project requirements elsewhere. The RenderTextures are R8G8B8A8_UNORM. I've disabled depth stencils as we don't need them. I've tried endless different video formats and encoding baselines, transcoding to different codecs. I haven't yet tried peeing into the wind.

Has anyone found any kind of workaround that works?

 

Just to add that I don't think changing the format to VP8 will fix this as all videos in my project were set to VP8 initially and I received this error.

As mentioned in my crash log post above, I then changed the video format from VP8 to Auto as a test, and this still crashed but with a slightly different error (also in my post above).

This is all with Unity 2020.3.45 though so if changing to VP8 makes a difference in other Unity versions I can't say.

 

I think you don't have to downgrade all the way back to 2020, using an earlier 2022.2 version should do it. Unfortunately I can't really remember when the regression appeared first. The_Island might know more about it. I think it might have been 2022.2.3 or so.

 

I remember that during the 2022.2 beta and the release canditate, we didn't have this issue. (Our game was in a 2 week QA pass and we didn't have any crashes, so 2022.2.1 should be safe)

 

I didn't try again with your test video, however I converted all my video files (MP4s) back to VP8 and two of the files reported errors during the conversion:
- "Unexpected timestamp values detected. This can occur in H.264 videos not encoded with the baseline profile."
- "First video frame not zero: 4 (0.133333s). Result may be out of sync. Please make sure tracks all start at 0"

Sure enough those 2 files were not H264 Baseline encoded, which I quickly fixed using Handbrake. These I then transcoded to VP8 again and the conversion errors no longer showed. After building and leaving it to run for the best part of an hour, I think I can say the CTD no longer happens!

Even though the videos were set to transcode with VP8, I assume the lack of baseline encoding for the source MP4s was still causing the CTD to happen.

However, I would still like MP4 file support to be fixed as the build size is 200MB greater with VP8 videos over MP4, but this is a good temporary fix for now! Thanks.

 

Definitely the bug I was looking for. Had the same problem here, the version number is too big of a coincidence, including the similar crash report (of course)
https://forum.unity.com/threads/nat...r-starting-unity-2020-3-43f1-onwards.1421486/

 

After 3 full days we finally located and fixed this as well. We had a mix of dynamically loaded videos (via URL) and unity-internal VideoClips. Both mp4s as well as vp8s. We had to
a) Transcode all external mp4s to vp8
b) Transcode all internal mp4s to vp8

But also the following -- and this I do not really understand:

c) We had to move all internal VideoClips entirely to StreamingAssets and load them by URL. Because even though they were vp8 they got decoded through Media Foundation and this still caused crashes!

Hope this gets fixed with the next version around the corner.

 

Getting this crash as well for some users. I tried switching to VP8 encoding which did not fix the problem on its own. I guess we'll try cp-'s fix and load from streaming assets.

 

@slims you can also try upgrading your editor. For 2021 the fix is live since a few days.

 

Also make sure the MP4s are baseline encoded before setting them to VP8. I had a problem (detailed above) where the MP4s I had didn't transcode to VP8 properly as the source videos were not H264 baseline encoded. Once I reencoded them (using Handbrake), and then set them to VP8 transcoding in Unity, I no longer had the crash.

 

jumping in here with same issue on unity version 2021.3.19f1. Works fine in editor, but crashes on build with videoplayers and MP4s.

Switching encoding to VP8 worked.