-
Notifications
You must be signed in to change notification settings - Fork 60
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support only AV_PIX_FMT_D3D11 for d3d11 #453
Conversation
I implemented this in my App, and it crashes. The crash happens also with the video widget example. Here is the output using the video widget example (fresh download today):
Reverting to the code before #453 has the effect that the crash does not happen, no error at all, very stable rendering (tested for hours and hours). I understand that this somehow means that
There have recently been many changes and fixes in Qt Multimedia code concerning textures and rendering, also for D3D11 decoding / rendering, to avoid crashes and to optimize rendering. This crash seems to have the effect that we cannot benefit from them yet. |
I tested qml_video/widget_video examples for many files for 6.6.2 and 6.7.0, but Nvidia graphics.
|
|
|
Yes, same. It wasn't the very latest, but I'll update to latest from today and retest. |
|
In the Qt bugreports there had been crashes reported with AMD GPUs, apparently there was or is an issue when you try to render ffmpeg d3d11 decoded textures directly. It seems to be fixed in latest Qt though. This is why I tested all, from Qt 6.6.1 over Qt 6.6.2 to latest Qt 6.6 dev, the coming 6.6.3. I had to setup a dev system recently, due to hardware crash, so currently I can develop only with Ryzen 7 and AMD GPU, and all old Qts are gone, too. I might be able to test on an Intel i7 system in about a week. |
Any h264/aac mp4 or .ts file or stream I tried. The same I use all the time, whioch work fine everywhere, Quicktime, ffplay, VLC, or packed as HLS in HLS players. |
I was always afraid that it was hard to control the rendering. So wondering if this is still relevant. |
To make sure that I understand correctly:
And if you do not see it, does it seem that we now have full zero copy rendering there? |
I can follow what you say, and understand the question, but cannot answer (yet). Possibly a deep check of the Qt code can show what they try to do. (Hoping they do it correctly by now in the latest code). |
I don't see any crashes
Nvidia
For QML it was true even for 5.15 when RHI was introduced. But for widgets, I would need to check the code to confirm. |
We could try to avoid rendering, and see if it crashes anyway. F.e. keeping
and confirm that it does not crash. |
I think I understand, and will test this. |
I used the BtbN ffmpeg from December 2023, and updated now to the download from today. And now the crash does not happen in the video widget example. In my app it is similar, not crashing, at least not yet in the short tests, but I can still provoke the DXGI_ERROR_DEVICE_HUNG device removal when I switch output windows. Not every time, but often. However now there are semi transparent color stripe overlays in the video output, in the video widget example and in my App, usually violet, but occasionally whitish. Sometimes ot looks like the complete picture is whitish. See attachements. In the Qt bugreports it was mentioned that the ffmpeg d3d11 decoding is using a texture array, and that they have difficulties to avoid that the same texture is read and written to. Looking at the pictures, this might be the issue. My guess is that a deep look into the very latest Qt source and how they fixed this (if they did indeed go zero copy) might be required to see if anything can be done about this. |
I did not test this anymore, because with the very latest ffmpag the crash did not happen yet, see comment above. |
Or could it be a format issue with the 2 NV12 textures which get returned? |
Possibly there is a hint there, about the ffmpeg texture handling: |
#456 @geminixdev could you please check it out? |
will test asap |
Wow, thanks, this is excellent! No crash, no error messages, no color stripes. The picture looks correct. Testing it also on a weak old Celeron PC with a 4K monitor, it plays smooth, it feels like zero copy rendering. I will do more testing in the next days, but it looks all good now. |
No description provided.