So, if I understand you correctly, it is advisable to remove the BT2020 flag, usin the @The Coolest build?
Already removed in today’s nightly.
You can press Ctrl+O (or open the player info with something like Yatse), you’ll see all the output details from CE. For a more expanded information, you can type cat /sys/devices/virtual/amhdmitx/amhdmitx0/config in SSH.
1 Like
I haven’t tested it thoroughly yet. I just looked a little, it’s interesting that for FEL video, RPU data is transmitted in two lines for Am6b, but for Oppo only one line changes, and the second is always just a strip. There is an assumption that Oppo for the EL layer does not send RPU data. But we need to study this issue. How is it right and how is it wrong. But so far, the difference in RPU between Oppo and am6b is big.
2 Likes
Hello, I ve encountered a movie, that has problems with playback. I am on CPM’s build at the moment. Movie is The Three Musketeers: D’Artagnan 2023, its a FEL title. It had some hiccups, but there is a consistant lag around 33 minutes. Here are logs: https://paste.coreelec.org/jKY6dj
I think it boils down to the order these are called, the set needs to come first and then auto will be fine - basically it is “auto” working out the HDMI connection from what has been set - along with the capabilities of the connected device.
I.e. there are two scenarios:
- The OK scenario:
08:24:58.339316 CoreELEC kernel: hdmitx: hdmitx_set_vsif_pkt: type=5, tunnel_mode=1, signal_sdr=0
08:24:58.640595 CoreELEC kernel: hdmitx: hdmitx: display colour subsampling is auto set to YUV444 (VIC: 93)
08:24:58.640766 CoreELEC kernel: hdmitx: hdmitx: display colourdepth is auto set to 8 bits (VIC: 93)
- The Problem scenario
08:28:40.108426 CoreELEC kernel: hdmitx: hdmitx: display colour subsampling is auto set to YUV444 (VIC: 93)
08:28:40.108542 CoreELEC kernel: hdmitx: hdmitx: display colourdepth is auto set to 12 bits (VIC: 93)
08:28:42.691680 CoreELEC kernel: hdmitx: hdmitx_set_vsif_pkt: type=5, tunnel_mode=1, signal_sdr=0
In the 2nd problem scenario the set is too late for some reason (or the auto to early) - note: auto is not called again.
I tried to force auto again after the set - but that just causes the kernel to crash out 
So need to understand which of the many places auto is referenced in the code that is being called in this case, and then why it sometimes gets called first - it is a race condition of sorts - but my take is both are needed a set and then auto.
(the plug out - is likely a big hint, in my setup it does feel like someone has unplugged and plugged back in the HDMI each time DV is played - with the TV going no-signal - my money is on the DV Engine enablement)
The original MEL detection was exacerbating the situation by necessitating a restart of the DV Engine which on close down sent things back to SDR, and then back again to DV - with the change to figure out MEL upfront before the DV Engine starts I think it should clear out a lot of the problems - but I still see the issue now and again.
FYI the MEL change is making it’s way into the nightly build.
I think the wait delay may still be 16 in those builds need to check the next one - if so can change to 2 in script until that is changed back as well.
7 Likes
Yes, the changes should be included with 20240321 nightly.
This wait delay is not used anymore with nightly 20240321: https://relkai.coreelec.org/
Thx again @cpm for his new approach for FEL/MEL detection!
As there was really heavy development ongoing on DV it is essential for everyone to upgrade to minimum nightly 20240321 before report or make any new logs.
9 Likes
Maybe autoset needs to somehow be triggered after a plugout event? Or has it crashed the kernel even after a plugout event?
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