Ghost in a Shell also started okay, but it was one of those hybrid DV ones. Will try more files tonight across DV and HDR10 and see if I notice something break. At least for starting playback, it’s been solid on those few files (granted if there are problems far into playback, I haven’t been watching through to notice those).
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.
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.
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.
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.
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.
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?
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.
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?
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
