Learning about Dolby Vision and CoreELEC development

I haven’t done anything with audio. Far as I know, CE doesn’t have any dependence Android for the audio and it should just work.

The point i was trying to convey was

From the onset you have been using amlogic
S905X3-B for testing.
Suffix - B is Dolby Digital Audio certified SoC

So it is most difficult for user(tester) to replicate your results.

Without the same amlogic S905X3-B board.

Iam going to Test anyway ,after work tonight!!

Think I’ve found a bug that would cause any device with a hdmi 2.1 port to crash on the latest build.

@xmlcom This would include your gs king-x. I would have thought the code wouldn’t have reached the bug with the debugging commands I gave you, so you still doing the test in Learning about Dolby Vision and CoreELEC development - #302 by doppingkoala is still useful.

1 Like

Wow!!!
Glad i decided to test.

Testing on Tanix Tx5 Plus Deluxe S905X3




Who needs a suffix anyways !!!

Most Excellent!!

Forgot to add this

1 Like

Looks like your TV didn’t go into DV mode for the EL.mkv, and the colors look like what happens on my TV when valid metadata is not included in the top pixels.

Is EL.mkv a valid DV file that works on other devices? Can you see the metadata being embedded in the top pixels of the screen?

Only profile 5 playback so far with your build

Yes the el test file came from cpm.

It is the infamous women in grey cloak/ face covering/ binoculars or camera.

It plays on Kinhank G1, but is converted to 8.1

Still find this is impossible what you have done.!!!

And on 5.15.119 kernel…

Yes in top left corner what appears metedata.

That doesn’t actually work properly, the polynomial reshaping isn’t done. Much more obvious on some videos than others, but still wrong on all.

The reshaping isn’t something that will be able to, generally, be done by only playing with the metadata. Handling the reshaping in some edges cases may be possible - but this situation doesn’t appear to occur for actual content, just some samples.

Have a link to the sample? I know the original FEL video, but given the variety of ways the EL could be extracted the sample you tested with would be best to look at. Seeing the metadata would indicate that DV metadata has been found, but the TV not triggering seems like it may not be valid

Is that why it is dv bt 709?

I only tested some samples quickly.

Ill post some more screen shots from your test files
Google drive.

Your profile 8.1 nits etc…

It seems like my TV is trying to default to HDR10
On all other profile playback.

Link for cpm ill try to find
It was a random post ,during all the updates

Think this is link to cpm test files

Probably can ignore that. What is displayed on the kodi gui doesn’t really make much sense or seem to link back to what is actually happening

1 Like

Try entering

 echo Y > /sys/module/aml_media/parameters/DV_vsif_send_in_hdmi_packet

before playing a profile 8.1 video. Should stop the hdr10 packet being sent.

Seem to work for me. Think it’s related to the profile 8.1 not working for you. I suspect if both a DV and a HDR10 packet is sent your TV ignores the DV one.

Been busy but finally here are all 8 output. Had to put in text file as too big to paste here.
New file.txt (38.2 KB)

Doesn’t look like you did

There are also some other differences. Also try

echo 0x1c > /sys/module/aml_media/parameters/canvas_to_read
echo 2 > /sys/module/aml_media/parameters/dv_injection_log_level
echo N > /sys/module/aml_media/parameters/always_send_vsif

then play a DV file and post dmesg. It won’t play in DV, but let me know if you can see the metadata in the top row.

Echo command works !!!

It is not stable/if you pause or hit info,or the letter o on keyboard = black screen

Still all profile 8.1 testfile will playback
Also cpm enhanced layer

Of course once you reboot/restart/Switch to Android and back
Must input command again

You can definitely see script/Metadata across top of the screen, both left n right top.

1 Like

I must have a very tolerant TV for receiving DV. I just get a brief black flicker, but it stays it stays in DV with a image after that.

In any case, this should all be able to be resolved by tying it into the existing DV code better, that code clearly does send the right packets at the right times.

edit: @freddy Out of interest, what is your TV? And the output of

cat /sys/devices/virtual/amhdmitx/amhdmitx0/dv_cap

Can anyone explain in simple terms what this project is trying to achieve? DV works well with the correct equipment.

Getting DV working for non licenced devices.

This is Not currently in the stable or nightly builds but I’m sure the CE developer will incorporate it at some point.

Fair enough. I would’ve thought there are enough licensed devices available now that it’s not worth the trouble. Personally I’d also worry about legal ramifications from Dolby. Anyway, good luck! It’s good there are smart people out there giving it a crack.

You make an interesting point about legalities. Hopefully this does not stop the CE team from adopting this exciting breakthrough.