MEL with dual layer? What should be the sense of it?
MEL have no EL layer data. So FEL is default.
I don’t think you understood, or I couldn’t explain. For some reason the box tries to play the MEl layer
instead of BL, hence the green video. I wish I could get you a sample.
The UHD I have (Munsil test discs) have Mel dv in them.
@Portisch The thing is, a blu-ray M2TS file with MEL also has two video tracks: BL + EL.
The difference between MEL and FEL is that the MEL layer only contains RPU data while FEL contains extra video data as well (at least that’s what I read on the internet 
)
So if you look into an M2TS file with a MEL layer, you will see two separate video tracks, same as FEL.
I have created a new MEL_Test.iso from the demo video that is present on the Spears & Munsil test disc. You can find it in my Google Drive again if you want to test with it.
If I run this ISO on my Chinoppo clone, it displays as Dolby Vision. On the current CoreELEC build it displays as HDR10.
I guess such file have another stream pid. Please run ffprobe on such m2ts and show the output.
EDIT:
It’s same pid 0x1015, so it should work…
Duration: 00:07:48.61, start: 600.000000, bitrate: 100132 kb/s
Program 1
Stream #0:0[0x1011]: Video: hevc (Main 10) (HDMV / 0x564D4448), yuv420p10le(tv, bt2020nc/bt2020/smpte2084), 3840x2160 [SAR 1:1 DAR 16:9], 23.98 fps, 23.98 tbr, 90k tbn, 23.98 tbc
Stream #0:1[0x1015]: Video: hevc (Main 10) (HDMV / 0x564D4448), yuv420p10le(tv, bt2020nc/bt2020/smpte2084), 1920x1080 [SAR 1:1 DAR 16:9], 23.98 fps, 23.98 tbr, 90k tbn, 23.98 tbc
Stream #0:2[0x1100]: Audio: truehd (AC-3 / 0x332D4341), 48000 Hz, 7.1, s32 (24 bit)
Stream #0:3[0x1100]: Audio: ac3 (AC-3 / 0x332D4341), 48000 Hz, 5.1(side), fltp, 640 kb/s
EDIT:
It do run as DV when dovi lib convert it to P8.1. So there is some condition missing I guess.
@MauriceW67 please try with this test image again on MEL and FEL:
Please enable Kodi debug logging and enable also the video component. Then play each iso only for a few seconds and then share Kodi.log.
@Portisch First of all let me apologize for any confusion. My remark about the MEL_Test playing in HDR10 was based on build 20240501, because yesterday 20240504 was not released yet.
Anyway, I just upgraded to 20240504 and for me, the MEL_Test plays perfectly in DV even with the DV setting set to “Lossless”.
So I am not sure why @Kaan is getting green video.
I found a issue as it was always type FEL set. But with tomorrow nightly it will set FEL or MEL correctly, like the test image above.
I installed your test build and opened a FEL and MEL ISO. Debug log is here:
https://paste.kodi.tv/eqobomifej.kodi
Both files played fine in DV with Lossless set. But like I said, the 20240504 nightly also worked for me
Thanks for those links.
I’ve now made some progress, by setting double_write_mode to 1 (seems to result in a canvas format of NV21 that I understand), I’ve been able to print out pixel values that are expected from a pointer (obtained using phys_to_virt()) inside of the vh265_vf_put function that is called by post_video_frame.
I’ve also added code to write values using this pointer, and can read back the changed values. These changes though don’t seem to be making their way to the screen.
Is there anyone familiar enough with this part of the code and amlogic canvas’s that could help me with why these writes don’t seem to be making their way to the screen?
I think I know where @Kaan saw the green screen. If you enable full BD-J menus using the JRE addon and then play disc 2 of the Spears & Munsil set, playing the DV demonstration video will give you a green screen.
I’ve also see strange behavior with that 60 GB ISO that I shared with you when BD-J menus are enabled by the way. But if I use the “Play main movie” setting it works just fine.
Not sure if it’s worth looking into this, but if you want a debug log, let me know.
Thanks for clarifying. I just tried another MEL bd (Abyss) without menu and it was working.
Menus generally are really unstable and slow on Kodi/Ugoos, but they are necessary with those test discs.
Edit: Made a new build and MEL with menus are working fine now.
If you made a new build and MEL is working now with menus, that means @Portisch is changing things in the source as we speak I guess?
Yes, it’s hard to follow though, there are multiple repositories. So I make a build when they say it’ll be in the tomorrow’s nightly.
That change should also be in the test build above that’s uploaded to MEGA. But when I use that build I still get a green screen with the S&M disc. So something more must have changed in the mean time
Probaby. Second disc with Skin Tones work fine now.
It’s weird. Skin tones work for me also, but the large demo video doesn’t.
Also while playing the skin tones, if I press skip to next chapter a few times, Kodi crashes and restarts.
So far I’ve tested with two discs. Spears & Munsil and Abyss. Both were folders and not iso’s though.
Same with Abyss.
So I’ve finally found a particularly ugly, hacky, poor quality way to embed the DV metadata on the fly and have tested it using a preformed bit sequence.
Anyway, I’d like to make a proof-of-concept using an actual DV file and use that dynamic metadata - but I must be missing something obvious because I can’t seem to find where the metadata decoded by the dovi_tool lives. Any pointers on where that is in the code / suggestions of how I can get that into in the vframe_s struct that is passed throughout the code?
@DMDreview Could you share a capture and the original file for a profile 5 file in the 8-bit DV tunnel?
I’m trying to work out how the 10-bit file is sent over the 12-bit tunnel - I think that is an important factor in what ways could possibly work for embedding the DV metadata into the top pixels to allow playback on all devices.
Compared to the two samples you have already provided (P7 FEL and P8), I think a profile 5 sample should avoid a color space conversion to IPT. I think that conversion is where 10-bit P8 file was changed to 12-bit. I want to find out what is transmitted when that doesn’t happen
@ anyone with suggestions
For me, it is proving difficult / impossible / I can’t work how to embed the metadata into the transmitted hdmi signal stream to make DV work on all devices. I’ve worked out one way of doing embedding the data - but it only works on 16:9 video and by outputting all video in a 8-bit format (with double_write set to 1) - works for testing concepts, but not practical for actual use.
The 16:9 requirement is because the part of the code I am using to embed the metadata only has access to the decoded video stream - and the metadata needs to be embedded in the top pixels that are transmitted over the hdmi regardless of the aspect ratio of the video file.
The 8-bit format is because that results in a video signal of type NV21, this format is documented and a pointer is available to the pixel data - easy to read and modify.
In normal 10-bit mode, the video stream is a type flagged as VIDTYPE_COMPRESS, VIDTYPE_SCATTER, and VIDTYPE_VIU_FIELD. Best I’ve been able to work out, this format is required for amlogic devices to play 10-bit content, VIDTYPE_COMPRESS refers to the data being in an undocumented lossless compressed form, and VIDTYPE_SCATTER refers to the data being somehow scattered in memory. Does anyone have any idea on how a video signal in this format can be read / written to?
To avoid issues in having to understand the 10-bit format, I had the idea of instead overlaying the pixel sequence in either the osd layer or the secondary video layer. But I have no idea how to go about trying that - any suggestions from others on how to do this?
I’m also making this post as a call out for any others who could help with embedding the pixel sequence into the 12-bit 422 signal that is sent over the hdmi.
I’m running out of ideas, out of my depth with the code, not really getting anywhere, and I will likely stop trying soon unless a breakthrough happens through the help of others.
Given embedding the pixel sequence does appear to be the only remaining hurdle to make DV work for all devices in all formats but FEL, I am making this post to see if there is interest from anyone that has the time and thinks they could be helpful in actually pulling this off first though.