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. |
9th October 2021, 18:06
|
#1 | Link |
|
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 |
|
|
|
13th December 2021, 03:10
|
#2 | Link |
|
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. |
|
|
|
|
13th December 2021, 16:17
|
#3 | Link |
|
Registered User
Join Date: Dec 2013
Posts: 646
|
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. |
|
|
|
|
14th December 2021, 04:44
|
#4 | Link | |
|
Registered User
Join Date: Sep 2006
Posts: 13
|
Quote:
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. |
|
|
|
|
|
14th December 2021, 05:02
|
#5 | Link |
|
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. |
|
|
|
|
14th December 2021, 11:24
|
#6 | Link | |
|
Registered User
Join Date: Dec 2013
Posts: 646
|
Quote:
|
|
|
|
|
|
14th December 2021, 15:08
|
#7 | Link | |
|
Registered User
Join Date: Sep 2006
Posts: 13
|
Quote:
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 |
|
|
|
|
|
14th December 2021, 15:15
|
#8 | Link | |
|
Registered User
Join Date: Sep 2006
Posts: 13
|
Quote:
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? |
|
|
|
|
|
14th December 2021, 17:00
|
#9 | Link |
|
Registered User
Join Date: Dec 2013
Posts: 646
|
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. |
|
|
|
|
15th December 2021, 01:14
|
#10 | Link |
|
Registered Developer
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,375
|
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 |
|
|
|
|
15th December 2021, 03:44
|
#11 | Link | |
|
Registered User
Join Date: Sep 2006
Posts: 13
|
Quote:
|
|
|
|
|
|
15th December 2021, 03:53
|
#12 | Link | |
|
Registered User
Join Date: Sep 2006
Posts: 13
|
Quote:
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. |
|
|
|
|
|
15th December 2021, 04:57
|
#13 | Link |
|
Registered User
Join Date: Jan 2019
Location: Canada
Posts: 577
|
This has been attempted, with seemingly no success: https://github.com/quietvoid/dovi_tool/issues/44
__________________
LG C2 OLED | GitHub Projects |
|
|
|
|
15th December 2021, 05:20
|
#14 | Link | |
|
Registered User
Join Date: Sep 2006
Posts: 13
|
Quote:
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! |
|
|
|
|
|
15th December 2021, 06:14
|
#15 | Link | |
|
Registered User
Join Date: Sep 2006
Posts: 13
|
Quote:
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. |
|
|
|
|
|
15th December 2021, 13:27
|
#16 | Link | |
|
Registered User
Join Date: Jan 2019
Location: Canada
Posts: 577
|
Quote:
MEL is equivalent to profile 8.1.
__________________
LG C2 OLED | GitHub Projects |
|
|
|
|
|
15th December 2021, 14:00
|
#17 | Link | |
|
Registered User
Join Date: Sep 2006
Posts: 13
|
Quote:
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. |
|
|
|
|
 |
| Thread Tools | Search this Thread |
| Display Modes | |
|
|
Linear Mode
