between release A LOT of things changed maybe the fix behind L5 is an issue but I don't think so I need to investigate. I think you already sent me a log when your screen is frozen, if it's not the case yes please send me a log and the best is to use the Beta 5 Debug for your log
I did not send any logs no so here is one with a lot of freezing and talking in a scene. Beta5-Debug log.
Welcome to my world, AMD and Intel are very different, an optimizarion for intel can be a regression for AMD. And in each brand you have a lot of different GPU with their own issue.
CroqueMr , if it can help find the issue, I went back from beta5 to beta4 and the freeze when PGS subtitles + any GUI is on the screen at the same time4 was still there. Then I went back to Beta3 before the L5 fix with the cutted out GUI and the freeze is not there anymore. Maybe it has something to do with L5? Do you want a log of when it freezes?
It's weird you don't seem to have the image freeze when a subtitle and GUI is present on the screen at the same time like I do. I am on AMD 8845S and AMD 780M.
Hi CroqueMr , I tested Beta5 and the DV DT file does not play correctly still, it seems to just display nothing or some vague wavy stuff, I think I was seeing my purple kodi theme in the back or something, like see-though? Not a big deal as nothing is in DT in MKV.
I found a bad bug for me, if I put PGS subtitles ON, if any GUI is on, may it be the standard kodi gui, or my plexmod gui, etc. everytime there is a subtitle on screen, the video freezes and then plays correct when the subtitle disappears.
It seems to be fine with SRT subtitles though and there is no freeze on those, only on PGS.
Can you reproduce that and find a fix please?
Thanks to you and hadesdevls for your work!
Since there are discussions about picture quality differences and you guys seems to know a lot about this I will ask the question I am still wondering about today: is there a picture quality difference between VAAPI and ffmpeg software decoding of the codecs (HEVC, H264, etc)?
I had both yes and no told to me but in my testing I think software looks better but it's close so it's hard to say. Also, the logic that says that the softwatre ffmpeg decoders are probably constantly fine tuned whereas the hardware decoders from vaapi are static in the gpu leans towards software probably got better with time?
So what's the truth on this?
I know that VAAPI with the DV builds look super nice to me and I am unsure I see a difference compared to software but I can't test software for DV because DV doesn't work in software. I mainly compared HDR10 or SDR.
I also know back in the older days software decoding was always better picture quality but it's not that easy to see anymore. For encoding I see the differences easily and still use cpu software encoding.
Yes I am a purist so I hope DV Master Reference will stay in the builds especially since my mini pc is powerful and only uses about 50% of the rendering engine in master reference.
Last note, I compared the DV picture between my AM6B+ and my mini PC and I think the AM6B+ is a little brighter than the mini pc with CroqueMR's build but I don't know which is right? When I say brighter I mean in all the picture, like more elevated but it's very minor or I imagine it maybe since I need to switch between two inputs to try and compare and there's 2-3 seconds of switch delay. I also think the Highlights are higher on CroqueMR's build which makes everything more popping, again slightly.
If there is a difference, can it be due to the HDMI Full versus Limited setting that you need to put to limited by force in that LibreElec build?
Also, why do we need to put that setting forced to limited so that everything is not overdark? I never had to do that on other LibreElec or CoreElec builds?
I also disabled DV once and then all the DV modes became unavailable until I rebooted. I did the same later and I did not have that problem.
MKVs yes, I saw a lot of issues with VAAPI and FEL thanks to this issue report : https://github.com/CroqueMr/libreelec-x86-DV/issues/29 , I think I already fixed it in my internal build, I need to clean my code before pushing an update of the debug version.
The issue is wider than MKV, it impacts also MP4, M2TS, everything has been fixed.
According to the issue report, the person cannot playback DT DV. I have the DT test file of "This Device Can Play DV" but for the DT test file specifically, it only displays black screen on my AM6B+ on CoreElec NG AND on your builds same thing. I thought this was normal and unsupported by ffmpeg or something. If you fixed that too that's pretty neat.
Display MoreNice good news
To be 100% honest I don't know
but here is the explanation of my buddy GPT 6 Astra that find the fix :
"It was a VAAPI context-identity bug between the BL and FEL decoders. FFmpeg can recreate the BL decoder’s AVHWDeviceContext while keeping the same underlying VADisplay. The previous check compared the context identity, so it could reject a valid device renewal and block EL processing.
Your file appears to trigger that reinitialisation path, explaining why other FEL files worked. The exact bitstream trigger hasn’t been identified, but this doesn’t mean the file is faulty.
The fix compares the underlying VADisplay, while still rejecting actual device changes. Reconstruction and image processing remain unchanged."
Edit : I saw your edit, I will check. I actually fixed a widespread bug this morning affecting FEL playback across several formats (MP4, MKV, M2TS...). You might be running into that same issue. Could you tell me what your exact file format is? This fix hasn't been added to the debug pre-release yet.
The explanation is indeed complex. o.O;
All my files are MKVs. If you want the complete MediaInfo I can send it.
Could you please try the beta4 debug version and send me back the log even if it fixed your issue?
Hi CroqueMr , the DV freeze is FIXED! 
Thank you!
Here is the log requested with the bunch of "CB1 debug" lines added it seems? I played back the video for 3 minutes.
What was the problem exactly I am curious? You can be technical I am a programmer.
Thanks!
P.S. I tried resuming the file at 3 minutes just to test a resume and it froze after playing for 1 second but with the image freezed instead of black. It seems that's it's the audio renderer that didn't work though so not sure it's from your code or not? I attach the log for that too just in case and the line with the error is line 234. There's a Stalled=true on line 512 from your debug info.
I tried reproducing the freeze and it does not happen every time but it happened a second time now, I attach that log too, (2ndFreeze). Also, when the video plays correctly, I can scan in the file backwards and forward and all is working fine.
CroqueMr , here are the playback infos before and after the freeze and it's not really a freeze of the system because I can still popup the gui and choose the stop button. It's just doing "nothing" and a black screen forever.
It works fine on my AM6B+ in DV so I don't think it's my file that is corrupted.
BEFORE:
AFTER:
I tried the different DV modes, even DV to HDR10 (HDR10 conversion) and all the modes freeze. If I disable DV then it plays in HDR10 fine.
Also, happy to report that the GUI is now fine, it's not cutted in the black bars anymore thanks to the L5 fix! Thanks to you and dangerouslaser for this!
CroqueMr , here's the new log for the DV Freeze.
Unfortunately not so much. We can see the issue, but we can't identified the root cause. I ran an intensive AMD stress test on my 7430U and fixed a few minor issues, which might help with yours. In the meantime, I’ve adjusted the logs to capture more detailed information so we can pinpoint the root cause.
Do you want a test clip?
CroqueMr , did my log about the DV freeze and black screen help find the issue?
Was finally able to solve my own issue. Turns out changing the refresh rate to 120Hz messes up Libreelec recognising the TV's ability to play dolby vision. Switching it back to 60Hz and now all is well again. Funny enough if you switch to 120Hz within the Kodi it still works as long as you don't reboot
That's possibly the same "bug" that I saw in CoreElec NO when I was talking to Portisch. He pointed me to a line of code that checks if a certain bit in the Dolby Vision VSVDB (Vendor Specific Video Data Block) in the EDID of the display is not ON then this says that the display cannot do DV at 120Hz. I have an older TV that cannot do DV at 120Hz and one that can and the bit was different on both, that's how I found out about the bit.
The problem is, it seems that CoreELec NO is checking the GUI Hz wrongly and thinks the video that you are starting the playback is a 120Hz video even if it's the GUI that is 120Hz and not the video. Probably something about when the video starts the playback because I was seeing 2 or 3 times switching res and/or Hz in the kodi log.
I still have the picture of the bit it's this one:
It says "reserved" but it's in fact called "Parity" and it'S a 120Hz compatibility bit for DV for the display. That picture is just from an older DV Header when it didn't yet serve any purpose.
I said to Portisch maybe this should be fixed but he just said use 60Hz in GUI so I did that on my AM9 Pro. I also think it may be from LibreElec 13 since CoreElec NO is a fork of LibreElec 13 if I am not mistaking. So that's why we see it here too maybe?
On my AM6B+ with CoreElec NG I do NOT have that problem and am using 1080p 120Hz and DV works fine so they changed or added the check for this bit in CoreElec NO / LibreELec 13.
Portisch replied with the line of code for the check here:
The line of code is here:
I don't see "common_drivers" in LibreELec's git repos though... I will try to put 1080p 120Hz and see if I have the same problem.
...
tested and I do NOT have a problem playing back DV while my GUI is at 1080p 120Hz. This may be a CoreElec NO only problem and maybe this has nothing to do with bang gun 's problem? It sure looks like the same problem from what he his experiencing though but I don't experience that like I did on CoreElec NO. Also, if I do a search for "dv->parity" in LibreElec's repo I find nothing.
Which file were you trying to play bang gun ?
CroqueMr , here is the kodi log for the Stranger Things black screen freeze.
It played about 10 secs appx then did the black screen freeze forever. I then quitted the video back to Kodi.
CroqueMr Do you think you can implement HDR10+ to DV conversion like they did in CoreElec's custom builds? No rush, just wondering.
I tried a lot of videos of all codecs and DV and HDR, so far the only ones that have a problem is the UHD BR mkvs of the new Stranger Things UHD BR discs. If you try to resume it just show a black screen and just stay there no sound or image. If I start from the beginning I see the first 15 seconds approximately then it's a black screen frozen with no image or sound like when you resume.
Maybe others that have those can test to see if they have the same thing? I didn't see anything special in the metadata compared to other DV movies.
It is DV FEL though, but other DV FEL works flawlessly.
I can procure a short clip if wanted and also I'll try to get a kodi.log
CroqueMr and cinemaONE, can't thank you guys enough. Having full DV and full 3D working well on my AMD 5800H is amazing. Just tested a bunch of test clips and movies for both. Thanks to dangerouslaser as well. This is getting there in beating the best Amlogic solutions to date in terms of speed, power, and fluidity.
I second that! Being able to use my powerful mini pc and decode absolutely everything with one box is awesome and it's thanks to you guys!
