Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Video Encoding > High Efficiency Video Coding (HEVC)

Reply
 
Thread Tools Search this Thread Display Modes
Old 9th October 2021, 18:06   #1  |  Link
topjes
Registered User
 
Join Date: Sep 2018
Posts: 2
x265 Dolby Vision encoding with EL

Hi guys,

Quick question. I can extract BL from UHD Remux then re-encode BL with x265.

Then I can do either:
1.) "remux" it with dovi_tool inject-rpu (ver 8) into Dolby Vision Profile 8 with Re-encoded BL + original RPU. Plays in Shield 2019 Pro like a charm.
2.) "remux" it with mkvtoolnix with original EL+RPU (extracted from UHD Remux) into dual track dual layer Dolby Vision Profile 7. Then I can also put this file into MakeMKV and create single track dual layer Re-encoded BL + original EL + original RPU Dolby Vision Profile 4.

Questions

I played the file #2 (MakeMKV Profile 4) for 5 mins and it works like charm. Is it a "proper" approach? I'm a bit surprised that re-encoded BL + original EL was remuxed so flawlessly.

Why the Profile 4 from MakeMKV is about 25 GB and the Profile 7 from mkvtoolnix is about 28 GB. Why after "remuxing" in MakeMKV the file is getting 3 GB smaller coming from Profile 7 MKV into Profile 4 MKV?

Was anyone trying the same? Can you see the difference between file #1 (Profile 8 re-encoded BL + RPU) and file #2 (Profile 4 re-encoded BL + original EL + RPU)? Honestly I can not see any visual difference. Sometimes I think file #2 is "better" but I'm not sure if this is only auto-suggestion.

PS. The EL is FEL ("Hereditary") (size about 6 GB)

Cheers
topjes is offline   Reply With Quote
Old 13th December 2021, 03:10   #2  |  Link
CHP
Registered User
 
Join Date: Sep 2006
Posts: 13
I also have the same question, but it should be noted that when playing this video on my Sony 7500g, the Dolby vision flag is normally lit and played normally. When dragging or positioning to a certain time point, the picture starts to flash. I think this is that the Dolby vision EL layer does not correspond perfectly to the time axis of BL video. This can be seen from the makemkv synthesis process. There is a prompt that the timeline is not synchronized, and a lot of El data will be lost after the synthesis, resulting in the final finished product file capacity being several GB less than the normal capacity

However, if the original Blu ray BL layer is used to make this video, the above problems will not occur.

Sorry, English is not good! Will experts help analyze it?

Last edited by CHP; 13th December 2021 at 03:14.
CHP is offline   Reply With Quote
Old 13th December 2021, 16:17   #3  |  Link
von Suppé
Registered User
 
von Suppé's Avatar
 
Join Date: Dec 2013
Posts: 629
As for using a dual track dual layer mkv as intermediate:
Eventhough MKVToolnix accepts importing BL and EL as separate videotracks, officially it does not support muxing "dual track/dual layer Dolby Vision". Therefor I can imagine issues.

With re-encoded BL, I tend to let tsMuxer mux it with EL+RPU and proper audio & sups into intermediate UHDBD iso. Import that result into MakeMKV and create single track dual layer BL+EL+RPU mkv. Maybe you want to try it out.
von Suppé is offline   Reply With Quote
Old 14th December 2021, 04:44   #4  |  Link
CHP
Registered User
 
Join Date: Sep 2006
Posts: 13
Quote:
Originally Posted by von Suppé View Post
As for using a dual track dual layer mkv as intermediate:
Eventhough MKVToolnix accepts importing BL and EL as separate videotracks, officially it does not support muxing "dual track/dual layer Dolby Vision". Therefor I can imagine issues.

With re-encoded BL, I tend to let tsMuxer mux it with EL+RPU and proper audio & sups into intermediate UHDBD iso. Import that result into MakeMKV and create single track dual layer BL+EL+RPU mkv. Maybe you want to try it out.
Thank you for your reply. I have also tested the scheme you mentioned. After the combination of BL layer video after x265 recoding and EL layer of uhd-bd, there will still be the problem of losing EL layer data during makemka output.

It is worth noting that if the original BL layer main video and El + RPU enhancement layer extracted directly from uhd-bd use mkvtoolnix to synthesize dual tracks, and then use makemkv to compose single track and double-layer video BL + El + RPU, there will be no complete video file losing any data, which is perfect! Dolby vision can also be played normally in Sony 9500g Only in the intermediate process, RPU needs to be converted into profile 8 and then synthesized into EL layer for subsequent D

Last edited by CHP; 14th December 2021 at 04:48.
CHP is offline   Reply With Quote
Old 14th December 2021, 05:02   #5  |  Link
CHP
Registered User
 
Join Date: Sep 2006
Posts: 13
Now a good result is that Sony 9500g can perfectly support the playback of 4K Dolby vision single track and double-layer video encapsulated in MP4 format (BL + FEL (MEL) + RPU, but it is only limited to BL + El extracted losslessly in uhd-bd. RPU metadata needs to be converted into profile 8, pro 7 can not normally light up Dolby vision, and other encapsulated formats such as ts and MKV do not support it.

However, the result is that the utilization rate of hard disk space is too large. We want to use x265 to recode the BL layer of uhd-bd to reduce the video capacity, but it is not perfect.
CHP is offline   Reply With Quote
Old 14th December 2021, 11:24   #6  |  Link
von Suppé
Registered User
 
von Suppé's Avatar
 
Join Date: Dec 2013
Posts: 629
Quote:
Originally Posted by CHP View Post
...and a lot of El data will be lost after the synthesis, resulting in the final finished product file capacity being several GB less than the normal capacity
Would you care to elaborate on that? How can you tell EL data goes lost, other than because of decrease in total filesize? I mean, can't this decrease have to do with the fact that MakeMKV will merge two separate videotracks into one?
von Suppé is offline   Reply With Quote
Old 14th December 2021, 15:08   #7  |  Link
CHP
Registered User
 
Join Date: Sep 2006
Posts: 13
Quote:
Originally Posted by von Suppé View Post
Would you care to elaborate on that? How can you tell EL data goes lost, other than because of decrease in total filesize? I mean, can't this decrease have to do with the fact that MakeMKV will merge two separate videotracks into one?
The video output by makemkv has no problem in normal playback, Dolby vision can be activated normally, and there are no problems in color, definition and other indicators. However, when dragging and positioning to a certain time point, the picture will flicker irregularly, and the color and brightness will continue to beat. This should be the result of the EL layer discarding data.

And when outputting in makemkv, there will be an obvious circular error prompt:

AV synchronization issues were found in file 'L://ok_t00.mkv' (title #1)
AV sync issue in stream 0 at 0:00:02.544 : secondary stream video frame timecode differs by -125.208ms
AV sync issue in stream 0 at 0:00:02.544 : secondary stream video frame timecode differs by -83.208ms
AV sync issue in stream 0 at 0:00:02.711 : secondary stream video frame timecode differs by +41.958ms
AV sync issue in stream 0 at 0:00:02.711 : secondary stream video frame timecode differs by -42.041ms
AV sync issue in stream 0 at 0:00:02.836 : secondary stream video frame timecode differs by -208.166ms
AV sync issue in stream 0 at 0:00:02.836 : secondary stream video frame timecode differs by -125.166ms
AV sync issue in stream 0 at 0:00:02.836 : secondary stream video frame timecode differs by +124.833ms
AV sync issue in stream 0 at 0:00:02.919 : secondary stream video frame timecode differs by -125.583ms
AV sync issue in stream 0 at 0:00:02.919 : secondary stream video frame timecode differs by -83.583ms
AV sync issue in stream 0 at 0:00:03.044 : secondary stream video frame timecode differs by +167.291ms
AV sync issue in stream 0 at 0:00:03.086 : secondary stream video frame timecode differs by -83.416ms
AV sync issue in stream 0 at 0:00:03.169 : secondary stream video frame timecode differs by -124.833ms
AV sync issue in stream 0 at 0:00:03.169 : secondary stream video frame timecode differs by -83.833ms
AV sync issue in stream 0 at 0:00:03.336 : secondary stream video frame timecode differs by +41.333ms
AV sync issue in stream 0 at 0:00:03.336 : secondary stream video frame timecode differs by -41.666ms
AV sync issue in stream 0 at 0:00:03.461 : secondary stream video frame timecode differs by -208.791ms
AV sync issue in stream 0 at 0:00:03.461 : secondary stream video frame timecode differs by -124.791ms
AV sync issue in stream 0 at 0:00:03.461 : secondary stream video frame timecode differs by +125.208ms
AV sync issue in stream 0 at 0:00:03.545 : secondary stream video frame timecode differs by -125.208ms
AV sync issue in stream 0 at 0:00:03.545 : secondary stream video frame timecode differs by -83.208ms
AV sync issue in stream 0 at 0:00:03.712 : secondary stream video frame timecode differs by +82.958ms
AV sync issue in stream 0 at 0:00:03.795 : secondary stream video frame timecode differs by +166.541ms
AV sync issue in stream 0 at 0:00:03.837 : secondary stream video frame timecode differs by -83.166ms
AV sync issue in stream 0 at 0:00:03.920 : secondary stream video frame timecode differs by -83.583ms
AV sync issue in stream 0 at 0:00:04.045 : secondary stream video frame timecode differs by +167.291ms
AV sync issue in stream 0 at 0:00:04.087 : secondary stream video frame timecode differs by -83.416ms
AV sync issue in stream 0 at 0:00:04.170 : secondary stream video frame timecode differs by -124.833ms
AV sync issue in stream 0 at 0:00:04.170 : secondary stream video frame timecode differs by -83.833ms
AV sync issue in stream 0 at 0:00:04.254 : secondary stream video frame timecode differs by +41.75ms
AV sync issue in stream 0 at 0:00:04.379 : secondary stream video frame timecode differs by +41.625ms
AV sync issue in stream 0 at 0:00:04.462 : secondary stream video frame timecode differs by -208.791ms
AV sync issue in stream 0 at 0:00:04.587 : secondary stream video frame timecode differs by -208.916ms
AV sync issue in stream 0 at 0:00:04.587 : secondary stream video frame timecode differs by +83.083ms
AV sync issue in stream 0 at 0:00:04.671 : secondary stream video frame timecode differs by +208.666ms
AV sync issue in stream 0 at 0:00:04.713 : secondary stream video frame timecode differs by -83.041ms
AV sync issue in stream 0 at 0:00:04.921 : secondary stream video frame timecode differs by -125.583ms
AV sync issue in stream 0 at 0:00:04.921 : secondary stream video frame timecode differs by -208.583ms
AV sync issue in stream 0 at 0:00:04.921 : secondary stream video frame timecode differs by -166.583ms
AV sync issue in stream 0 at 0:00:04.921 : secondary stream video frame timecode differs by -83.583ms
AV sync issue in stream 0 at 0:00:04.921 : secondary stream video frame timecode differs by +41.416ms
AV sync issue in stream 0 at 0:00:04.921 : too many video frames with invalid timecodes, future messages will be suppressed
CHP is offline   Reply With Quote
Old 14th December 2021, 15:15   #8  |  Link
CHP
Registered User
 
Join Date: Sep 2006
Posts: 13
Quote:
Originally Posted by CHP View Post
The video output by makemkv has no problem in normal playback, Dolby vision can be activated normally, and there are no problems in color, definition and other indicators. However, when dragging and positioning to a certain time point, the picture will flicker irregularly, and the color and brightness will continue to beat. This should be the result of the EL layer discarding data.

And when outputting in makemkv, there will be an obvious circular error prompt:

AV synchronization issues were found in file 'L://ok_t00.mkv' (title #1)
AV sync issue in stream 0 at 0:00:02.544 : secondary stream video frame timecode differs by -125.208ms
AV sync issue in stream 0 at 0:00:02.544 : secondary stream video frame timecode differs by -83.208ms
AV sync issue in stream 0 at 0:00:02.711 : secondary stream video frame timecode differs by +41.958ms
AV sync issue in stream 0 at 0:00:02.711 : secondary stream video frame timecode differs by -42.041ms
AV sync issue in stream 0 at 0:00:02.836 : secondary stream video frame timecode differs by -208.166ms
AV sync issue in stream 0 at 0:00:02.836 : secondary stream video frame timecode differs by -125.166ms
AV sync issue in stream 0 at 0:00:02.836 : secondary stream video frame timecode differs by +124.833ms
AV sync issue in stream 0 at 0:00:02.919 : secondary stream video frame timecode differs by -125.583ms
AV sync issue in stream 0 at 0:00:02.919 : secondary stream video frame timecode differs by -83.583ms
AV sync issue in stream 0 at 0:00:03.044 : secondary stream video frame timecode differs by +167.291ms
AV sync issue in stream 0 at 0:00:03.086 : secondary stream video frame timecode differs by -83.416ms
AV sync issue in stream 0 at 0:00:03.169 : secondary stream video frame timecode differs by -124.833ms
AV sync issue in stream 0 at 0:00:03.169 : secondary stream video frame timecode differs by -83.833ms
AV sync issue in stream 0 at 0:00:03.336 : secondary stream video frame timecode differs by +41.333ms
AV sync issue in stream 0 at 0:00:03.336 : secondary stream video frame timecode differs by -41.666ms
AV sync issue in stream 0 at 0:00:03.461 : secondary stream video frame timecode differs by -208.791ms
AV sync issue in stream 0 at 0:00:03.461 : secondary stream video frame timecode differs by -124.791ms
AV sync issue in stream 0 at 0:00:03.461 : secondary stream video frame timecode differs by +125.208ms
AV sync issue in stream 0 at 0:00:03.545 : secondary stream video frame timecode differs by -125.208ms
AV sync issue in stream 0 at 0:00:03.545 : secondary stream video frame timecode differs by -83.208ms
AV sync issue in stream 0 at 0:00:03.712 : secondary stream video frame timecode differs by +82.958ms
AV sync issue in stream 0 at 0:00:03.795 : secondary stream video frame timecode differs by +166.541ms
AV sync issue in stream 0 at 0:00:03.837 : secondary stream video frame timecode differs by -83.166ms
AV sync issue in stream 0 at 0:00:03.920 : secondary stream video frame timecode differs by -83.583ms
AV sync issue in stream 0 at 0:00:04.045 : secondary stream video frame timecode differs by +167.291ms
AV sync issue in stream 0 at 0:00:04.087 : secondary stream video frame timecode differs by -83.416ms
AV sync issue in stream 0 at 0:00:04.170 : secondary stream video frame timecode differs by -124.833ms
AV sync issue in stream 0 at 0:00:04.170 : secondary stream video frame timecode differs by -83.833ms
AV sync issue in stream 0 at 0:00:04.254 : secondary stream video frame timecode differs by +41.75ms
AV sync issue in stream 0 at 0:00:04.379 : secondary stream video frame timecode differs by +41.625ms
AV sync issue in stream 0 at 0:00:04.462 : secondary stream video frame timecode differs by -208.791ms
AV sync issue in stream 0 at 0:00:04.587 : secondary stream video frame timecode differs by -208.916ms
AV sync issue in stream 0 at 0:00:04.587 : secondary stream video frame timecode differs by +83.083ms
AV sync issue in stream 0 at 0:00:04.671 : secondary stream video frame timecode differs by +208.666ms
AV sync issue in stream 0 at 0:00:04.713 : secondary stream video frame timecode differs by -83.041ms
AV sync issue in stream 0 at 0:00:04.921 : secondary stream video frame timecode differs by -125.583ms
AV sync issue in stream 0 at 0:00:04.921 : secondary stream video frame timecode differs by -208.583ms
AV sync issue in stream 0 at 0:00:04.921 : secondary stream video frame timecode differs by -166.583ms
AV sync issue in stream 0 at 0:00:04.921 : secondary stream video frame timecode differs by -83.583ms
AV sync issue in stream 0 at 0:00:04.921 : secondary stream video frame timecode differs by +41.416ms
AV sync issue in stream 0 at 0:00:04.921 : too many video frames with invalid timecodes, future messages will be suppressed

If hdr10 extracted losslessly from UHD BD is used The BL layer and Dolby vision EL layer perform all operations to generate the finished video without any error, and the final capacity is the same as the video file synthesized in mkvtoolnix.

I think this is a bug in makemkv?
CHP is offline   Reply With Quote
Old 14th December 2021, 17:00   #9  |  Link
von Suppé
Registered User
 
von Suppé's Avatar
 
Join Date: Dec 2013
Posts: 629
These AV sync issues in MakeMKV don't look good indeed. I can imagine them causing issues. I don't know why they show up, and why with the recurring values. Seems a certain cadence is at play here. Maybe other people recognize this and could tell you. I wouldn't think it's a bug in MakeMKV.
Only thing I can think of is rewriting the timestamps of the re-encoded BL with ffmpeg and mux that into your intermediate file. You may try to see if it solves the issue.

I'm still having a very hard time to get why a re-encoded BL that's bugged with wrong timestamps would cause MakeMKV drop EL data and thus introduce increase in filesize. If I understand you correctly, that is.
von Suppé is offline   Reply With Quote
Old 15th December 2021, 01:14   #10  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,344
I would assume that the frame structure of BL and EL needs to match, so that decode delay does not introduce latency between them (which would be shown in the timestamps of the encoded video already, hence sync issues). Which means wherever the original BL had I/P/B frames, the resulting stream should as well. Re-encoding the BL without taking extreme care (to a level I'm not sure you easily can), would disrupt this and cause such issues.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders
nevcairiel is offline   Reply With Quote
Old 15th December 2021, 03:44   #11  |  Link
CHP
Registered User
 
Join Date: Sep 2006
Posts: 13
Quote:
Originally Posted by von Suppé View Post
These AV sync issues in MakeMKV don't look good indeed. I can imagine them causing issues. I don't know why they show up, and why with the recurring values. Seems a certain cadence is at play here. Maybe other people recognize this and could tell you. I wouldn't think it's a bug in MakeMKV.
Only thing I can think of is rewriting the timestamps of the re-encoded BL with ffmpeg and mux that into your intermediate file. You may try to see if it solves the issue.

I'm still having a very hard time to get why a re-encoded BL that's bugged with wrong timestamps would cause MakeMKV drop EL data and thus introduce increase in filesize. If I understand you correctly, that is.
OK, thank you very much for your analysis and reply. I will try the scheme you said to test. Thank you!
CHP is offline   Reply With Quote
Old 15th December 2021, 03:53   #12  |  Link
CHP
Registered User
 
Join Date: Sep 2006
Posts: 13
Quote:
Originally Posted by nevcairiel View Post
I would assume that the frame structure of BL and EL needs to match, so that decode delay does not introduce latency between them (which would be shown in the timestamps of the encoded video already, hence sync issues). Which means wherever the original BL had I/P/B frames, the resulting stream should as well. Re-encoding the BL without taking extreme care (to a level I'm not sure you easily can), would disrupt this and cause such issues.
I think your analysis is very reasonable. It is speculated that the time stamps of the possibly re-encoded BL and the original El are misaligned and mismatched. When synthesizing in makemkv, the relevant frames of the El are discarded in order to match the time stamps, resulting in the reduction of the final capacity and normal playback, but you can't arbitrarily locate the time point for drag playback, which will lead to the problem of unpredictability.

Now the key point is to use what method or re-encode parameters to re-encoding BL, which can maintain the same I / P / B structure and original timestamp information as the original BL. I think this can match the original el

Now we are discussing what solutions and schemes can be found. Thank you for reply!

Last edited by CHP; 15th December 2021 at 04:02.
CHP is offline   Reply With Quote
Old 15th December 2021, 04:57   #13  |  Link
quietvoid
Registered User
 
Join Date: Jan 2019
Location: Canada
Posts: 570
This has been attempted, with seemingly no success: https://github.com/quietvoid/dovi_tool/issues/44
__________________
LG C2 OLED | GitHub Projects
quietvoid is offline   Reply With Quote
Old 15th December 2021, 05:20   #14  |  Link
CHP
Registered User
 
Join Date: Sep 2006
Posts: 13
Quote:
Originally Posted by quietvoid View Post
This has been attempted, with seemingly no success: https://github.com/quietvoid/dovi_tool/issues/44


Thank you for your reminder and help. I'll go to that post and take a closer look at it.

The Dolby and hdr10 + tools you provide are great!
CHP is offline   Reply With Quote
Old 15th December 2021, 06:14   #15  |  Link
CHP
Registered User
 
Join Date: Sep 2006
Posts: 13
Quote:
Originally Posted by quietvoid View Post
This has been attempted, with seemingly no success: https://github.com/quietvoid/dovi_tool/issues/44
After reading that post, things have become more complicated.

At present, it seems that there is no particularly good scheme to recode BL and perfectly match the original EL layer video frame type.

You said use your Dovi_ Tool converts the RPU from the original profile 7 to profile 8 and injects it. Even if the recoded BL and the original El are successfully matched and combined into a single track double layer, the player only uses the RPU part and automatically ignores the EL layer. In fact, what we can see is the effect of BL + RPU. Is that right?

Thank you again for your efforts and good tools!

Last edited by CHP; 15th December 2021 at 06:16.
CHP is offline   Reply With Quote
Old 15th December 2021, 13:27   #16  |  Link
quietvoid
Registered User
 
Join Date: Jan 2019
Location: Canada
Posts: 570
Quote:
Originally Posted by CHP View Post
...the player only uses the RPU part and automatically ignores the EL layer. In fact, what we can see is the effect of BL + RPU. Is that right?
In most cases, yes the player ignores the EL.
MEL is equivalent to profile 8.1.
__________________
LG C2 OLED | GitHub Projects
quietvoid is offline   Reply With Quote
Old 15th December 2021, 14:00   #17  |  Link
CHP
Registered User
 
Join Date: Sep 2006
Posts: 13
Quote:
Originally Posted by quietvoid View Post
In most cases, yes the player ignores the EL.
MEL is equivalent to profile 8.1.
OK, I see. Thank you very much for your answer!

If this is the case, there is no need to make a complete recoding version of BL + el (MEL /FEL) + RPU. Now it's good to use your Dolby tool to get the BL + RPU version of profile 8.1, and the effect is satisfactory. If necessary, a lossless BL + El + RPU version can be made for viewing.
CHP is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 08:52.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.