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. |
7th January 2019, 17:45 | #6601 | Link | |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,770
|
Quote:
A) The new HEVC-aq is in fact experimental, ala AQ-motion B) It does override the specified AQ-mode, and there is no way to get low-luma bias ala AQ-mode 3 yet. C) Rate control should be working. I used a high-grain clip with some atypical properties in my initial test (because AQ was messing up on it before), so if anything was going to give it pause, it was that one. Sent from my iPad using Tapatalk |
|
8th January 2019, 20:28 | #6602 | Link |
Registered User
Join Date: Aug 2012
Posts: 203
|
i'm trying to encode a 4k hevc file using an DV Enhancement Layer, i have a few question in this regard:
Can i crop the input frame? Can i see from a MediaInfo log that the DV Layer got muxed inside the stream? Can i mux the resulting h265 file into a mkv container? Do i need to set DV Profile 8.1 to mux the additional layer? Regards. |
8th January 2019, 22:30 | #6603 | Link | |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,770
|
Quote:
Also, Profile 8.1 support isn’t common yet; the majority of existing Dolby Vision TVs in consumer hands today don’t support it. Profile 5 is what is universally supported. The actual compression part is a relatively small and relatively straightforward part of making Dolby Vision content. Getting a properly shaped non-backwards compatible Y’CtCp source file and it’s metadata is the new and complex part. Dolby Vision is a ways away from being something a consumer can make. It is totally feasible technically, but the tools just aren’t broadly available at this point. |
|
9th January 2019, 19:08 | #6604 | Link | |
Herr
Join Date: Apr 2009
Location: North Europe
Posts: 556
|
Quote:
|
|
9th January 2019, 20:30 | #6605 | Link | |
Registered User
Join Date: Aug 2009
Posts: 90
|
Quote:
Is quite a bit slower than current version i'm using (2.9.9) Test Settings: 1080p source --crf 18 --preset veryslow --profile main10 --level-idc 4 --output-depth 10 --ctu 32 --psy-rdoq 2.5 --tskip --aq-mode 3 --qcomp 0.7 --vbv-bufsize 20000 --vbv-maxrate 20000 --ipratio 1.35 --pbratio 1.25 --subme 7 --merange 64 --colormatrix bt709 --deblock -1:-1 --no-sao x265 2.9.9 (64bit GCC 8.2.0) avg. speed: 0.66fps x265 3.0 RC4 (64bit GCC 8.2.1) avg. speed: 0.40fps Last edited by K.i.N.G; 9th January 2019 at 20:50. |
|
9th January 2019, 21:21 | #6606 | Link | |
Registered User
Join Date: Aug 2012
Posts: 203
|
Quote:
I have a standard 4k bluray and i've extracted the tracks using the latest eac3to, so i have a source.mkv and dv_layer.h265 and i want to encode video and mux the additional Dolby Vision layer using the --dolby-vision-rpu option, but i don't know if the process is successful because i can't see any additional information when i generate a MediaInfo report. I would like to crop the video stream as I'm encoding it then mux the resulting video into a mkv file. TL;DR: how do i check that the muxing of the layer went fine? can i crop the picture? can i mux the resulting video stream to MKV? |
|
9th January 2019, 21:29 | #6607 | Link | |
Registered User
Join Date: Feb 2015
Posts: 326
|
Quote:
To exact compare please use in new version command line '--preset slower' instead of old '--preset veryslow' |
|
10th January 2019, 02:22 | #6608 | Link | |
Registered Loser
Join Date: Dec 2004
Posts: 117
|
Quote:
|
|
10th January 2019, 13:41 | #6610 | Link |
Registered User
Join Date: Feb 2007
Location: Sweden
Posts: 483
|
x265 v3.0_RC+10-672ce0547e97 (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (32bit : GCC 7.4.0 / 64bit : GCC 8.2.1)
Code:
https://bitbucket.org/multicoreware/x265/commits/branch/default Last edited by Barough; 10th January 2019 at 16:27. |
10th January 2019, 20:13 | #6611 | Link | |
Registered User
Join Date: Aug 2012
Posts: 203
|
Quote:
If i understood correctly it should mux the DV metadate directly inside the h265 stream (and studying the relevant commit it seems to include such information inside an 0x3E NAL unit) so why i shouldn't be able to mux the resulting stream inside an mkv? |
|
10th January 2019, 23:41 | #6612 | Link | |
Registered Loser
Join Date: Dec 2004
Posts: 117
|
Quote:
We have yet to see a clip which works with --dolby-vision-rpu. And once we get it, we can only use .ts or .mp4, not .mkv. If you have one, we're all ears, but nothing from a UHD blu-ray works with that parameter with x265. |
|
11th January 2019, 10:42 | #6614 | Link |
Lost my old account :(
Join Date: Jul 2017
Posts: 325
|
@Ma
I asked some questions regarding mereange a while ago but didnt get a reply, so I thought that I give it another shot. I've seen discussions here and in other threads that CTU 64 is overkill for resolutions bellow 4k, and I've seen from my own testing that lowering CTU from 64 to 32 on systems with plenty of threads gives an speed improvment of up to 50% for 1080p video, and lowering merange gives another 10%. And this is with a very minor compression hit. This behavior is also stated in this document https://media.readthedocs.org/pdf/x265/default/x265.pdf when it comes to threading performance. What I find a bit odd is that this is stated in the document: "Given these considerations, you can understand why the faster presets lower the max CTU size to 32x32 (making twice as many CTU rows available for WPP and for finer grained frame parallelism) and reduce --merange" and this: "The default is derived from the default CTU size (64) minus the luma interpolation half-length (4) minus maximum subpel distance (2) minus one extra pixel just in case the hex search method is used." But I cant see that any preset changes the merange value of 57, even the two fastes ones that do lower the CTU value to 32. How come? And since lowering CTU (and merange), can have such massive influence on speed, wouldn't be a good idea to have these values set based on resolution? And giving the explanation of the default merange value, would the same calculation stand when lowering CTU to say 32? I.e. would that give an "best practice" value of 26 if me star is used? Last edited by excellentswordfight; 11th January 2019 at 10:50. |
11th January 2019, 20:11 | #6615 | Link | |
Registered User
Join Date: Aug 2012
Posts: 203
|
Quote:
It won't happen again |
|
11th January 2019, 20:27 | #6616 | Link | |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,770
|
Quote:
It won't happen again [/QUOTE] I like DoVi as the short way to type it. I am an old fellow, and I hear DV I start thinking "Ah, 25 Mbps with 720x480 4:1:1 color in its NTSC variant." It's amazing what we can do with 25 Mbps a couple decades later! |
|
11th January 2019, 20:43 | #6617 | Link | |
Registered User
Join Date: Aug 2012
Posts: 203
|
Quote:
|
|
11th January 2019, 23:20 | #6618 | Link |
Registered User
Join Date: Feb 2015
Posts: 326
|
--ctu 64 vs. 32 && --merange 12 vs. 26 vs. 40 vs. 57 vs. 74 vs. 92
I've made a test with --merange 12/26/40/57/74/92 for --ctu 64 --qg-size 64 vs. --ctu 32 --qg-size 32
Command line: for %m in (12 26 40 57 74 92) do ( x265 -p7 --bitrate 500 -f3333 --psnr --ssim --qg-size 64 --merange %m ../big_buck_bunny_1080p24.y4m w64-%m.hevc x265 -p7 --bitrate 500 -f3333 --psnr --ssim --ctu 32 --merange %m ../big_buck_bunny_1080p24.y4m w32-%m.hevc ) Results (in ctu block: speed (fps), PSNR, SSIM (dB)): Code:
ctu merange | 64 | 32 12 | 6.93 39.980 12.996 | 6.44 39.565 12.742 26 | 6.69 40.303 13.599 | 6.21 39.903 13.345 40 | 6.46 40.393 13.746 | 6.07 39.999 13.499 57 | 6.13 40.404 13.757 | 5.90 40.019 13.512 74 | 5.85 40.409 13.757 | 5.67 40.024 13.515 92 | 5.58 40.413 13.760 | 5.47 40.026 13.514 For CPU with only 12 logical cores (6 physical) --ctu 64 is just better in preset slower for 1080p encoding. |
Thread Tools | Search this Thread |
Display Modes | |
|
|