I can confirm I experience the same issue at about 33:20.
https://paste.coreelec.org/DQxy8f
Tested with both truehd and the eac3 compatibility track. Same skip. Will try a 2nd release just to be sure.
I installed 21 nightly build, seemed to work, but haven’t tested more then that single moment and on cpm’s build the whole movie was buggy to the point I had to switch conversion to 8.1.
I tried 2x different remuxes of this film and both have the same skip near 33:20.
Don’t know which release you guys tried but It didn’t skip on latest nightly here.
The original code actually didn’t even set CD/cs in the disp auto mode call. It appears it was just resolution and refresh rates. As mentioned earlier I think this is the issue. I tried stripping this code out. To my surprise TV-led is perfect, but hdr10 and LLDV miss the bitrate somewhere. After careful inspection seems it’s doing in the DV pkt method.
I think it will be better to restore this logic and move the CD/CS into the individual Mode functions (the three dv,hdr10 and hdr10+ ones). Then finally find out where to add the code to set the CD for hdr10.
In my experience, Omega_nightly_20240320 fixes a lot of skipping and stallings for me. I tried with Dune - Part 1 and MEG2 - both were next to impossible to play on 20240320. It now plays near smoothly after the update. Well done!!!
Could you share the raw captured data from a known sample video from a device running in true tv-led mode that sends changing RPU data?
I’d like to take the idea from your RPU transmission video further, extract the RPU data from the captured data, and see if any of it can be matched up to metadata extracted from the original sample using the dovi_tool
@djnice You also seem to have the equipment needed to capture the data. Could you share some captured data?
1 Like
I can confirm that issue, too. (Les.Trois.Mousquetaires.D.Artagnan.2023, 33min 20sec)
I tried with monsoon android build but no issue, so it seems that the remux itself is not the cause of this issue.
Something for your investigation.
I am wondering maybe the 2nd line is a CRC of the metadata for the sink to check, I think it can be sent as clear or CRC, and the oppo not sending the CRC?
Seems to work on latest CE21 nightly build, checked a few other problematic moments in this movie. So good job team CoreElec.
no, then a regular video with 8 profiles and MEL would also have this stripe, but it’s not there. I will study the issue.
I was thinking about it, there’s binary code, in theory it’s possible to match, but it needs to be done a lot of captures, in which only one of the parameters will change. It is quite possible that encryption or encoding is also used there. but I will provide you with some screenshots in dpx. you can pull the RPU string from them
1 Like
I double-checked the rpu, everything is fine, there is no difference. Apparently, for the first time, I compared different frames by accident. But the fact that there is a second line, it turned out, depends on the video, in some there is, and in some there is not. And judging by the location, this is not the second line, but a continuation of the first, because the second one ends approximately in the middle of the frame.
In general, we can now say with confidence that there is no difference, either in FEL or in the 8 profile of the difference between Aro and am6b in the transmission of RPU data. They are identical. The only difference is in the different color interpolation methods.
Addition. No, I was not mistaken, there is a difference in the RPU data if the video is from Cm4.0. Last time I tested on the Weird science UHD bd remux movie, the video has Cm4.0. Here on it, there is a difference between Oppo and Am6b. But there is no difference in the video from CM2.9. apparently due to the fact that Oppo cannot read CM4.0
5 Likes
Some thing very much wrong - I cannot play any DV material anu more. Tried 3 of the Matrix and True Lies - no video on the screen at all:
https://paste.coreelec.org/Ihs9zM
my inexperienced eye cannot catch anything obvious in the log but can anyone spot anything? I’m really very interested to know what’s going on.
Sorry if this is a silly quesiton, but is @cpm’s patch now included in both the latest 20.5 and 21.0 nightlies? I’ve installed ng-20.5-20240320 on my new AM6B+ and dropped the (64-bit) dovi.ko in my /storage/ directory. Am I good to go?
0321 nightlies according to this post:
It’s either line 6070 or line 5586 where the auto gets called. Might be useful to add a kernel pr_info statement to determine. I’m hopeful it’s happening on line 6070.
cpm’s original patches are already in, new Mel detection build still isn’t out though.
Here is the latest patent I could find from Dolby - that looks like the CRC is always transmitted (would swear I saw somewhere it could be optional) - anyway this maybe useful to understand the RPU more.
US10701399.pdf (2.6 MB)
This may be more helpful in first trying to extract valid packets. It’s not quite as straightforward as the lower bit of the chroma channel