dolby_vision: Support persisted state RPU parsing

[quietvoid]

This is required for parsing compressed RPUs. It probably would imply using a crate like once_cell, and setting it behind a feature.

So API users can choose to use the extra allocations to preserve the state.

Then, in vdr_dm_data_payload, that state can either be updated or fetched from to get the proper attributes. For the DM data, the RPU is compressed when RpuDataHeader::reserved_zero_3bits is set to 1.

Todo:

• [ ] Figure out what affected_dm_metadata_id and current_dm_metadata_id mean.
• [ ] Use them to update the state or restore metadata from a previous RPU.
• [ ] Find out how to handle RpuDataHeader::use_prev_vdr_rpu_flag

[HoffmannTom]

@quietvoid Maybe this PDF sheds some lights on it: https://www.etsi.org/deliver/etsi_gs/CCM/001_099/001/01.01.01_60/gs_ccm001v010101p.pdf It is explained in 6.3.2 HDR DM metadata (= HDR display management metadata) It seems to create a reference between the metadata and the picture it refers to and to the current transmitted frame.

About use_prev_vdr_rpu_flag I found this explanation: https://patents.google.com/patent/US10701399B2/en "use_prev_vdr_rpu_flag specifies whether the current Dolby Vision reference processing unit is predicted from a previously sent reference processing unit. The following values are supported. 1: A previously sent Dolby Vision reference processing unit is used to generate the interlayer prediction for the current picture 0: The current Dolby Vision reference processing unit is transmitted explicitly, and a vdr_rpu_id is assigned to the current Dolby Vision reference processing unit. When the BL picture is an instantaneous refresh picture, the value of use_prev_vdr_rpu_flag must be 0."

I hope some of these information helps.

[quietvoid]

Dolby kinda seems to have abandoned the compressed RPU concept, but I might still add support for it.