HDR fractional 30 FPS to DV not showing.

[cpm-code]

So, believe this is the same issue you all are talking about... I get a black screen, followed up my AM6B+ locking up (must unplug & power back on), when I have 'on demand' enabled, with HDR to DV conversion on. When I let HDR be processed as HDR, it's fine.

Please try playing this HDR video with 'on demand' for DV, and HDR to DV conversion on. Thanks.

Originally posted by @htfan8atic in https://github.com/cpm-code/xbmc/discussions/116#discussioncomment-12475318

[cpm-code]

This one I can replicate - using the sample linked above.

It is not locking up just not showing for me, can remote in and restart kodi or use alternative access etc. also if good muscle memory can just go through the remote to stop.

FYI I have vc-1 hw decode working, but somewhere along the line on my build the buffering/frame pipeline is broken so looking into that over the next week or so.

[cpm-code]

but somewhere along the line on my build the buffering/frame pipeline is broken so looking into that over the next week or so.

LOL - turns out it was a switch on my network dropping the link to 100Mb from 1000Mb.

[cpm-code]

Don't know why the HDR does not play with VS10.

I see it is a recompression and has a large NAL with user_data_unregistered(2514) containing details of the recompression, the payload type is 5 followed by 9x 0xFF bytes which is not familiar to me - but no expert here, can you redo it without that data?

[cpm-code]

I see it is a recompression and has a large NAL with user_data_unregistered(2514) containing details of the recompression, the payload type is 5 followed by 9x 0xFF bytes which is not familiar to me - but no expert here, can you redo it without that data?

OK not that SEI NAL but another one - type 4.

There is additional logic that looks to cater for ATSC (Advanced Television Systems Committee) and DV metadata.

The logic looks for two specific NAL SEI being present:

A NAL SEI for type MASTERING_DISP_COLOUR_VOLUME (137), which there is in this file, and would be for HDR content.

Mar 15 10:34:35.570862 CoreELEC kernel: DOLBY: nal_type: 39
Mar 15 10:34:35.570956 CoreELEC kernel: DOLBY: type 137, size 24

And A NAL SEI for type USERDATA_REGISTERED_ITUT_T35 (4), which again there is in this file:

Mar 15 10:34:35.576857 CoreELEC kernel: DOLBY: nal_type: 39
Mar 15 10:34:35.576950 CoreELEC kernel: DOLBY: type 4, size 71

If the USERDATA_REGISTERED_ITUT_T35 is found it assumes this must be ATSC DV Metadata, and use the dovi.ko to parse, but the reset of the dovi.ko throws it out saying not supported:

Mar 15 10:34:35.577011 CoreELEC kernel: Creating Dolby Vision metadata parser instance success
Mar 15 10:34:35.577070 CoreELEC kernel: Not supported
Mar 15 10:34:35.577124 CoreELEC kernel: dv_md_parser_process 476:00,00 (rc='Not supported') failed
Mar 15 10:34:35.577179 CoreELEC kernel: DOLBY ERROR: meta(544), pts(0)->parser process fail
Mar 15 10:34:35.577235 CoreELEC kernel: DOLBY ERROR: meta(544), pts(0) -> metadata parser process fail

Looks like the dovi.ko reset is thrown out because it does not support atsc:

reset_flag = 2; /*flag: bit0 flag, bit1 0->dv, 1->atsc*/

i.e. bit 1 is set when passed in for reset:
p_funcs_stb->metadata_parser_reset(reset_flag | 1);

@htfan8atic
Unless we find a dovi.ko which can parse this type then need to switch it off, luckily there is a parameter to do just that already:

echo 0 > /sys/module/amdolby_vision/parameters/atsc_sei

After doing that the file will play ok with VS10.

So begs the question is there really 'atsc' DV metadata in that file.
The code just checks the presence of the above two SEI NAL, and assumes it must be - but seems fragile as USERDATA_REGISTERED_ITUT_T35 is used for different things and cannot assume that.

Anyway will change the code to default atsc_sei to 0.

[cpm-code]

Had a peak at the latest AMLogic kernel code, and they now do check the USERDATA_REGISTERED_ITUT_T35 specific payload details and the one in the file would not have passed that, so it is not DV metadata.

Kinda moot point as the dovi.ko would not process it anyway if it was DV metadata, but FYI for anyone wondering across this in the future.

[quietvoid]

So begs the question is there really 'atsc' DV metadata in that file.

It's closed captioning, CEA-608/708 in SEI.
https://en.wikipedia.org/wiki/CTA-708#Picture_User_Data

user_data_type_code is 0x03

[cpm-code]

thanks - was searching around for what the 0x03 meant.

From the latest kernel code 0x09 would mean DV metadata either from atsc or dvb

if (country_code == 0xB5 &&
	    ((provider_code == ATSC_T35_PROV_CODE && user_id == ATSC_USER_ID_CODE) ||
	     (provider_code == DVB_T35_PROV_CODE && user_id == DVB_USER_ID_CODE)) 
         &&
	    user_type_code == DM_MD_USER_TYPE_CODE 0x09)
		return true;