x265 3.0 Dolby Vision encoding

[telemO]

Thanks a lot, dear quietvoid, for having replied quickly to me.
I'm trying again to post you a reply - few days after my first attempt failed (supposedly due to moderation filtering?)

Originally Posted by quietvoid

There's no simple way to use the tool for cropped video, you have to edit the code.

Erf... That is a matter for me: I'm not competent in programming neither compiling (and a bit allergic to it actually).
Is it abusive to ask you, theweasley or anyone else able to compile with this cargo thing, a "crop able" version of your DoVi tool?

Originally Posted by quietvoid

Also, using the RPU with x265 to transcode might end up with some desyncs due to the way x265 is inserting the metadata back.
See https://github.com/quietvoid/dovi_to...ment-803652617

I'm also having similar issues as your topic above, with "red flash" insertion before a fade out during the start credits (I'm working with a 2600 frames extract of a movie remux).
I've also detected a magenta flash on a white area (a reflection zone) during a real movie part.

Originally Posted by quietvoid

Unfortunately I don't think there is a solution for that, other than inserting the metadata after transcoding.

What do you mean by that exactly ?
To mux it with the yusesope tool or via mkvmerge + MakeMKV ? But how would you mux a RPU.bin with an hevc file ?

Originally Posted by quietvoid

For HDR10+ the same desync issue is present.
For cropped video, the metadata is supposedly resolution agnostic and hopefully the analysis is done on the active image area only.
So it should work in theory,

From an article I found about Metadata Levels on the Dolby Professional Support Knowledge, it is written "Ratio of canvas and image (active area)" as part of the Level 0.
This would mean the same as you mentionned for the HDR10+ theorical implementation, on the active area... and therefore no need to have a "crop-able" version?

Originally Posted by quietvoid

I'm curious to know how streaming services make use of x265's RPU insertion. There has to be some predicting the transcode's decoding order somehow, to make sure the RPU is synced throughout.
Though I've had artifacts with Dolby Vision on Netflix as well, so maybe they don't bother syncing either.

Probably someone knowledgeable in the video streaming domain, such as benwaggoner, would give you answer or at least some hints.

[quietvoid]

Originally Posted by telemO

What do you mean by that exactly ?
To mux it with the yusesope tool or via mkvmerge + MakeMKV ? But how would you mux a RPU.bin with an hevc file ?

I mean parsing the final HEVC and interleaving the metadata NAL units directly, it's still a raw bitstream.
Implies correctly decoding the frames in the right order though.

Originally Posted by telemO

This would mean the same as you mentionned for the HDR10+ theorical implementation, on the active area... and therefore no need to have a "crop-able" version?

Analysis for both metadata should be assumed to be done on the active area only, according to docs.
The only difference with Dolby Vision is that the active area is also present in the final metadata, while it's not in HDR10+.

As for a "croppable" version, I just have a Windows binary: https://mega.nz/file/dZ1mXQga#ve0Dwl...HweAXRg-BEXG7U
Maybe this is a feature I can add, since a lot of people have asked for it..

[telemO]

quietvoid, you're the boss, man !
You're again replying quickly, and with a "croppable" release of your tool under Windows, perfectly suitable with my need as an end-user encoder.
I'm gonna try this within the coming days and let you know my result, as soon as possible, as I think I have a good sample to know if this croppable option would work.

I have to see how and where to share some samples for the community to test and tell about the syncs / artifacts issues.
And then to share my experience for the others to be able to do the same, as for the HDR10+ case.

[telemO]

Originally Posted by quietvoid

As for a "croppable" version, I just have a Windows binary: https://mega.nz/file/dZ1mXQga#ve0Dwl...HweAXRg-BEXG7U
Maybe this is a feature I can add, since a lot of people have asked for it..

Thanks a lot again for delivering so quickly this croppable version, and of course, I would encourage you to publish an updated version of the dovi_tool with this feature, whenever you've get the time to do it.

As mentionned before, a first return on the sample I tought about testing cropping:

• cropped at 1632 instead of original 2160p, which is a FEL DoVi UHD-BD base material,
• transcoded with x265 v3.4 Mod version from Staxrip 2.1.7.0 in DV profile 8.1, inputing the RPU converted to 8.1 by the quietvoid's dovi_tool,
• encapsuled as a MP4 file, with mp4muxer, in order to test with the internal player of my Panasonic TV,

the DoVi logo is showing on as well as the picture menus and parameters related to it are activated (such as Dolby IQ):

1. with the RPU extracted by the github version 0.1.2 of dovi_tool, the TV displays the cropped sample with black bars lapping over the 1632-high area, i.e. it is like "over-cropping" the already cropped picture.
2. with the RPU extracted by the unofficial "crop-able" version of dovi_tool, the TV displays the cropped sample with black bars as expected.

To mitigate this test case, I tried with another DoVi FEL UHD-BD base material, and whatever I use the "crop-able" or not version of dovi_tool, both of my cropped test samples are displayed correctly the same by my TV.
I deduce that the metadata where containing some information of an higher area on the first sample material and not on this other one.

I'm now thinking that I read something about subtitles mattering, and that I should have a look at the consequences of cropping for diplaying these.


For information about artifact or sync pbs, I also notice a "red flashy" insertion on a text animation just before a fade out (as for the first sample).
I've tried many x265 parameters change, such as chromaloc=0 or 2, ref=6 (as you mentionned), scenecut=0, hrd-concat, no-open-gop, uhd-bd : none of these solved the issues.

[quietvoid]

I just released 0.2.0 with metadata reordering according to the frames display output order instead of decoded order.
As well as adding the --crop flag for setting active area offsets to zero.

[telemO]

Originally Posted by quietvoid

I just released 0.2.0 with metadata reordering according to the frames display output order instead of decoded order.
As well as adding the --crop flag for setting active area offsets to zero.

Thanks a lot again for taking your time to update and improve the tool.

I'll have to test if this new parsing method removes the artifact/sync issues I've noticed on my test sample.

Few questions to you, quietvoid :
- I'm confused for some time now with the convert option FEL to MEL: what is the use case? To encode in DV profile 5 ?
- What is the use case(s) of the new command "inject-rpu"? Would it mean that I can inject the RPU into my transcoded hevc file afterwards and not during the x265 process anymore (with the --dolby-vision-rpu command)?

[quietvoid]

Originally Posted by telemO

- I'm confused for some time now with the convert option FEL to MEL: what is the use case? To encode in DV profile 5 ?

No, the profile 7 stays except compatibility is better for devices that cannot play FEL files.

Originally Posted by telemO

- What is the use case(s) of the new command "inject-rpu"? Would it mean that I can inject the RPU into my transcoded hevc file afterwards and not during the x265 process anymore (with the --dolby-vision-rpu command)?

It's still experimental, but the basic of it is to be able to add Dolby Vision metadata to an existing HDR10 file.
However I'd still suggest using the RPU with x265 instead.
YMMV.

[telemO]

I made a test with one of my samples that was displaying artifacts, i.e. wrong color inserts ("flashes") in some areas : there are all gone with your last tool revision.
Wonderful !!!
I still have to test with another sample that such artifacts are gone as well, and then I'll become very confident using your parsing tool (which I did use anyway to share already some content in DoVi 8.1)

Originally Posted by quietvoid

No, the profile 7 stays except compatibility is better for devices that cannot play FEL files.

Am I understanding correctly that the file will still be made of BL+FEL as profile 7 but the FEL will contain an MEL type RPU so that the devices which cannot handle FEL would decode in MEL mode?

Originally Posted by quietvoid

It's still experimental, but the basic of it is to be able to add Dolby Vision metadata to an existing HDR10 file.
However I'd still suggest using the RPU with x265 instead.
YMMV.

Oh, that would be great ! I don't have the time to test in the coming weeks to make some mileage but it would worth some tries.

[quietvoid]

Originally Posted by telemO

Am I understanding correctly that the file will still be made of BL+FEL as profile 7 but the FEL will contain an MEL type RPU so that the devices which cannot handle FEL would decode in MEL mode?

Yes that's how it should work.

[Lucius Snow]

Hi all,

Is there a way to convert plain-text XML (from DaVinci) to binary RPU file metadatas without using the expensive Dolby Encoding Engine software?

Or maybe a way to convert a JSON file from HDR10+ to this binary RPU?

Thanks.

[quietvoid]

No way currently, but it could be possible with reference XML and binary RPU.
Sol Levante only comes with one of those, since Netflix doesn't openly distribute the transcoded files.

Same answer for HDR10+, but that's more complicated.

I'm not sure how your usecase has Dolby Vision support in Resolve (requiring a license), but not the DEE.
Maybe they come separately.

[Blue_MiSfit]

You could use a public cloud offering like AWS MediaConvert or Hybrik to do this indirectly. Either would produce final Dolby Vision Profile 5 elementary streams (with the RPU included). You could dump that data if you just wanted the RPU.

[quietvoid]

Actually, Netflix does make some of their experiments available as both XML and encoded metadata.
So it could be done pretty simply, if someone does the work.

[Balling]

Originally Posted by quietvoid

Actually, Netflix does make some of their experiments available as both XML and encoded metadata.
So it could be done pretty simply, if someone does the work.

Yeah, for that this patch should be applied, but the speed of the devs, oogh! https://patchwork.ffmpeg.org/project...ail.gmail.com/

[Blue_MiSfit]

This patch is so important I can't even ^^

[quietvoid]

Originally Posted by Lucius Snow

Hi all,

Is there a way to convert plain-text XML (from DaVinci) to binary RPU file metadatas without using the expensive Dolby Encoding Engine software?

Or maybe a way to convert a JSON file from HDR10+ to this binary RPU?

Thanks.

I've started working on this, you can find a test build here: https://github.com/quietvoid/dovi_tool/pull/43
edit: Feature is in 0.5.0: https://github.com/quietvoid/dovi_to...ases/tag/0.5.0

So far L2 trim values seem to be different for Netflix's Sparks encoded RPU.
I don't really know why.

Also, I recently added partial generation from HDR10+, essentially just using the analysed L1 metadata.

Edit: now supports both CMv2.9 and CMv4.0 for L1/L2/L3/L6 metadata.

[Balling]

Patch applied: https://github.com/FFmpeg/FFmpeg/com...ac24dabc2095d9 and previous.

[Lucius Snow]

Great news! I'll give it a try.

[Balling]

Vimeo turned on HLG Dolby Vision.

https://www.engadget.com/vimeo-dolby...171019651.html
https://vimeo.zendesk.com/hc/en-us/a...ing-HDR-Videos


Our HDR playback files are created using the HEVC (H.265) video codec, so make sure that you are using a supported video player and HDR10 supported viewing hardware. We recommend using the nightly build of VLC (https://nightlies.videolan.org/) or mpv (https://mpv.io/installation/).

Only apple devices are supported and Youtube-dl

код выделить копировать
youtube-dl.exe -F https://vimeo[.]com/601088734
[vimeo] 601088734: Downloading webpage
[vimeo] 601088734: Downloading JSON metadata
[vimeo] 601088734: Downloading JSON metadata
WARNING: Unable to download JSON metadata: HTTP Error 403: Forbidden
[vimeo] 601088734: Downloading fastly_skyfire m3u8 information
[vimeo] 601088734: Downloading fastly_skyfire m3u8 information
[vimeo] 601088734: Downloading akfire_interconnect_quic m3u8 information
[vimeo] 601088734: Downloading akfire_interconnect_quic m3u8 information
[vimeo] 601088734: Downloading fastly_skyfire MPD information
WARNING: Unknown codec dvh1.08.01
WARNING: Unknown codec dvh1.08.01
WARNING: Unknown codec dvh1.08.03
WARNING: Unknown codec dvh1.08.01



In practice you can open https://player.vimeo.com/video/60109...6af_1631451035

config in F12 dev tools of Crome and extract URL of DV.
ffmpeg.exe -i "https://skyfire.vimeocdn.com/1631354504-0xbd668e04dbe3ae33c2a16af5d504a6b185427992/168ed075-c7e9-49d2-a58a-ae0f4e22cc38/sep/video/76a4dc18,9806faf5,4cb30f17,6daf3a1d,641ee4b5,609c3410,cf77e251/audio/100781af,8fd81468/master.m3u8?query_string_ranges=1&f=dash" -strict unofficial -c copy dv85.mp4

It will work. strict unofficial needed to write DoVi sidedata. FFmpeg/FFmpeg@b8243b3