quietvoid/dovi_tool

Some questions about DV and encoding

berrywhite96 opened this issue · 4 comments

Sorry in the first place for asking again for DV and encoding. I invested time learning about DV and encoding as I have not the space for all my UHDs non-reencoded. But there are some questions in my mind.

My current workflow:

  1. Export UHD with MakeMKV
  2. Encode hevc with ffmpeg from exported mkv
  3. Export RPU as profile 7 with dovi_tool from untouched hevc
  4. Inject RPU into encoded hevc
  5. Mux everything together into a mkv again with MKVToolNix

When I am playing the mkv with my Shield everything works fine. But everybody is talking about encoded profile 5 or 8.1, do I discard anything from the metadata or I am the only one who wants encoded profile 7 DV?
Second question, can I crop the BL and inject the untouched RPU later? On my Shield it works fine again, but if I am muxing it into a ts file with tsMuxer and watch it on my LG webos directly the file is cropped twice and looks like the video has suddenly a resolution of 3840x804.

Thank you for your tool and your time!

There's no point in keeping the RPU profile 7 if you reencode and don't keep the original enhancement layer.
It's equivalent to converting to profile 8.1.

If you want to merge back the enhancement layer, you're restricted to not cropping when reencoding.

If you crop the BL, you must either use the --crop flag or edit the RPU before injecting again, to edit the active area.
There are a bunch of issues and discussions about this in the repo.

Following up on this question, to make sure I understand. I was under the impression there is no way to keep dual layer profile 7 if you reencode. X265 can't do the EL, and dovi_tool just extracts the RPU, so we have to do profile 5 or 8.1 right (BL + RPU)?
Is there a workflow where x265 can reencode the video stream and DV profile 7 (EL + RPU) can be pulled from the original and added to the new encoded file?

No, because there's no way to sync the reencoded and enhancement layers.

See comments from this issue: #44