x265 HEVC Encoder [Archive] - Page 133

benwaggoner

7th January 2019, 17:45

Well, just did a test encode and it appears to be true

x265 [warning]: hevc-aq enabled, disabling other aq-modes

This is confusing syntax. We really should have aq-mode 4 and 5. aq-mode 4 would be HEVC-AQ, and 5 would be HEVC-AQ with low luma bias (like aq-mode 3 versus 2). The need for low-luma bias is content dependent, and we shouldn't be locked into one or another.

Also I am getting VBV violations multiple times a second. From the first two seconds of my test clip:

x265 [warning]: poc:0, VBV underflow (-2596808 bits)

x265 [warning]: poc:8, VBV underflow (-13025705 bits):06:32

x265 [warning]: poc:4, VBV underflow (-13047849 bits):38:49

x265 [warning]: poc:16, VBV underflow (-12824903 bits)11:58

x265 [warning]: poc:12, VBV underflow (-12960465 bits):23:11

x265 [warning]: poc:24, VBV underflow (-12939991 bits)27:49

x265 [warning]: poc:20, VBV underflow (-13441281 bits):34:43

x265 [warning]: poc:32, VBV underflow (-12651471 bits)23:47

x265 [warning]: poc:28, VBV underflow (-12985385 bits):28:15

x265 [warning]: poc:40, VBV underflow (-12559455 bits)20:36

x265 [warning]: poc:36, VBV underflow (-13122593 bits)24:13

Was the Experimental Feature tag left off for HEVC-AQ? I love the idea of improved AQ, but it would be good to have a clear indication in the help text about how close to production ready this feature is.

In talking with MCW, they confirmed that

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

MonoS

8th January 2019, 20:28

benwaggoner

8th January 2019, 22:30

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?.
I am not sure what you are trying to do, but I am doubtful it would work :). Can you clearly define what your sources and desired outputs are? If you don’t already have an RPU file previously generated, you can’t do Profile 8.1. and there aren’t low-cost tools to generate one. ColorFront Transkoder is the most accesssble option I’m aware of.

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.

Forteen88

9th January 2019, 19:08

I created a version for Windows 2.9+8. I almost doesn't change anything. Codec hasn't only 'threads' for VMAF as I wrote earlier.
https://www.sendspace.com/file/r90y0d
Probably it can also be created in MSVC.Could you please make a x265-VMAF version for the latest x265 (v3.0 RC4)?

K.i.N.G

9th January 2019, 20:30

x265 v3.0_RC+4-8aebc58efe5c (https://www.mediafire.com/file/l6e0rrj4q1c2r3c/) (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (32bit : GCC 7.4.0 / 64bit : GCC 8.2.1)

https://bitbucket.org/multicoreware/x265/commits/branch/default

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

MonoS

9th January 2019, 21:21

I am not sure what you are trying to do, but I am doubtful it would work :). Can you clearly define what your sources and desired outputs are?

sure i can, my apologies for not being clear from the start :)
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

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

New --preset slower == old --preset veryslow and new --preset veryslow is really new and really veryslow. See https://bitbucket.org/multicoreware/x265/commits/537bba0b7fdcbfc56ab4eb5315909c7a5cdb5a23?at=default

To exact compare please use in new version command line '--preset slower' instead of old '--preset veryslow'

agressiv

10th January 2019, 02:22

sure i can, my apologies for not being clear from the start :)
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?

MKV doesn't support Dolby Vision (at least, not yet) - it won't work. Your best bet is to use the Dolby MP4 muxer and use ac3 audio.

benwaggoner

10th January 2019, 05:33

MKV doesn't support Dolby Vision (at least, not yet) - it won't work. Your best bet is to use the Dolby MP4 muxer and use ac3 audio.
Yeah, .mkv isn’t a professional format. Pretty much all professional development around containers these days is around mp4, and to a lesser and declining degree, MPEG transport streams.

Barough

10th January 2019, 13:41

x265 v3.0_RC+10-672ce0547e97 (https://www.mediafire.com/file/no3410zfz9ar6bo/) (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (32bit : GCC 7.4.0 / 64bit : GCC 8.2.1)

https://bitbucket.org/multicoreware/x265/commits/branch/default

MonoS

10th January 2019, 20:13

MKV doesn't support Dolby Vision (at least, not yet) - it won't work. Your best bet is to use the Dolby MP4 muxer and use ac3 audio.

So what's the purpose of the --dolby-vision-rpu option?
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?

agressiv

10th January 2019, 23:41

So what's the purpose of the --dolby-vision-rpu option?
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?

DV metadata for x265, but not necessarily the elementary h265 stream from a blu-ray.

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.

LigH

11th January 2019, 00:29

:o DV is still "Digital Video" for me, not "Dolby Vision", so I keep wondering about metadata...

excellentswordfight

11th January 2019, 10:42

@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?

MonoS

11th January 2019, 20:11

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.

I thought that the Dolby Video Enhancement Layer available in commercially available BDs where the RPU information, if i'm understanding correctly this is not the case, but x265 wasn't giving me any error (like you can see here https://bitbucket.org/multicoreware/x265/commits/e50f803e26fb3926dc695e0aeea39681fe1eacbd#Lsource/x265.cppT587 ) so i expected to be doing things right.

:o DV is still "Digital Video" for me, not "Dolby Vision", so I keep wondering about metadata...

It won't happen again ;)

benwaggoner

11th January 2019, 20:27

I thought that the Dolby Video Enhancement Layer available in commercially available BDs where the RPU information, if i'm understanding correctly this is not the case, but x265 wasn't giving me any error (like you can see here https://bitbucket.org/multicoreware/x265/commits/e50f803e26fb3926dc695e0aeea39681fe1eacbd#Lsource/x265.cppT587 ) so i expected to be doing things right.
I think the older discs were mainly Profile 5, where the enhancement layer includes both quarter-scale video and metadata. x265 doesn't support that. Newer discs would be Profile 5, where the enhancement layer is just RPU metadata. But that requires a properly "shaped" base layer specific to the source and metadata, which is Y'CtCp and dynamically adjusts to the currently-used subset of the PQ curve for greater precision.

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!

MonoS

11th January 2019, 20:43

I think the older discs were mainly Profile 5, where the enhancement layer includes both quarter-scale video and metadata. x265 doesn't support that. Newer discs would be Profile 5, where the enhancement layer is just RPU metadata. But that requires a properly "shaped" base layer specific to the source and metadata, which is Y'CtCp and dynamically adjusts to the currently-used subset of the PQ curve for greater precision.

I think that what i'm talking about it's BDs with DoVi 7.6 (as per this document https://www.dolby.com/us/en/technologies/dolby-vision/dolby-vision-profiles-levels.pdf ) so standard 4k video content and additional enhancement layer

11th January 2019, 23:20

Motenai Yoda

12th January 2019, 04:41

@Ma can you make results about --ctu 64 --qg-size 32 and --ctu 32 --qg-size 16 too?
maybe just for --merange 40 only

jlpsvk

12th January 2019, 12:17

why the hell was default aq-mode changed to 2 from 1???? my all encodes are bad now. :(

nevcairiel

12th January 2019, 12:24

If you rely on a specific setting that strongly, you should not rely on it being the default, and just specify it. Or as an alternative, not blindly update your encode pipeline without verifying that it still produces expected results.
For the record, the default was changed from 1 to 2 (https://bitbucket.org/multicoreware/x265/commits/b14834a9d1c1864ea7e94d9cfed4e33f37e767c6), not the other way around.

Boulder

12th January 2019, 12:35

nevcairiel

12th January 2019, 12:48

Personally I like the second option. Not blindly update, but validate new versions first.

Selur

12th January 2019, 12:56

Still waiting for them to update the documentation https://x265.readthedocs.io/en/latest/presets.html,..
Opened an issue entry for it (https://bitbucket.org/multicoreware/x265/issues/460/update-documentation) at the end of last year.
I get it that they change the defaults(/presets/tune) from time to time, but not updating the documentation do represent such fundamental changes is really annoying,...

Boulder

12th January 2019, 13:10

And a funny thing is that --no-rskip is supposed to be a default in --preset veryslow (and also --slower) but it's not according to the code. I reported the issue a long time ago but no one fixed it :) Doesn't matter to me though, I use --rskip all the time anyway.

Selur

12th January 2019, 13:26

@Boulder: yeah, looking at https://bitbucket.org/multicoreware/x265/src/default/source/common/param.cpp?at=default rskip is only disabled in placebo,
but the documentation:
- https://x265.readthedocs.io/en/latest/presets.html reports that is is disabled starting with slower.
- https://x265.readthedocs.io/en/default/presets.html reports that is is disabled starting with very slow.
-> wrong documentation is even worse than missing documentation :(
(same for https://bitbucket.org/multicoreware/x265/src/default/source/common/param.cpp?at=latest)

jlpsvk

12th January 2019, 14:29

ok... can you tell me why aq mode 2 is better? i noticed rapid lower bitrate with aq-mode 2... any impact on picture quality and fine detail retention? i am encoding with crf18

Boulder

12th January 2019, 14:44

ok... can you tell me why aq mode 2 is better? i noticed rapid lower bitrate with aq-mode 2... any impact on picture quality and fine detail retention? i am encoding with crf18

I didn't find mode 2 better than 1 in my test cases (reported earlier here in this thread) so I'm still using mode 1 with the default strength.

I think you need to find a new sweet spot for CRF since the bitrate demand is indeed quite different compared to mode 1, and I also think it depends heavily on the content.

12th January 2019, 15:35

@Ma can you make results about --ctu 64 --qg-size 32 and --ctu 32 --qg-size 16 too?
maybe just for --merange 40 only

Results in attachment -- it is a bit faster encoding but quality is worse (at the same bitrate).

excellentswordfight

12th January 2019, 17:57

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)):

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

When --merange grows, the quality increases regardless of the size of --ctu (it may depend on the source movie).

For CPU with only 12 logical cores (6 physical) --ctu 64 is just better in preset slower for 1080p encoding.
I see, thanks for sharing.

I think you are correct, since the biggest benefit of reducing it only appears when going above arround 8C/16T (I was testing with 12/24 and went from 7fps to 11fps cause of the less thread utilization at CTU 64, and I would say that it was definitely was worth the trade off), it does makes since to keep it as an manual setting.

I would say though that it might be worth consideration to lower the merange for those fastets presets, since it doesnt seem to benefit quality that much.

LigH

13th January 2019, 14:40

I like DoVi as the short way to type it.

That might sound stupid to a German (Doofi ~ retarded kid) :sly:

a couple decades later!

:eek: I am old!
_

Some on-topic:

Support for Dolby Vision is announced, and immediately people believe that applications for decoding, possibly even encoding, for consumer PCs are available too ... which is doubtful. I wonder how "homeopathic" its additional features will be in a generic furnished living room, where average people can hardly tell the difference between DD AC3 and dts on a DVD Video, not to mention HD Audio formats.

To me, it seems that supporting such data is mainly for professional content producers. Might be a field where hobbyists can't help the developers much.

sneaker_ger

13th January 2019, 14:55

Support for Dolby Vision is announced, and immediately people believe that applications for decoding, possibly even encoding, for consumer PCs are available too ... which is doubtful. I wonder how "homeopathic" its additional features will be in a generic furnished living room, where average people can hardly tell the difference between DD AC3 and dts on a DVD Video, not to mention HD Audio formats.
Oh, I'm sure the difference will be noticable to consumers. Simply because authors will make it so, not because it's superior. Just like in the past authors used different mixes for AC3 and DTS tracks on the same DVD. It's all about marketing. :devil:

jd17

13th January 2019, 17:39

Oh, I'm sure the difference will be noticable to consumers. Simply because authors will make it so, not because it's superior.

That.

Lucius Snow

15th January 2019, 00:31

Hello all,

There's still no GPU support to speed up the encoding?

Thanks.

LigH

15th January 2019, 03:00

jlpsvk

15th January 2019, 09:55

Ok. Did a test. 3840x2160 res., same x265 settings. One with aq-mode 1 crf18 and second aq-mode 2 (which is now new default) with crf16. aq-mode 2 with crf16 still gives lower bitrate. which one "should" be better in terms of detail retention?

whole CLI (HDR parameters are added automatically by RipBot264):
-preset slow --profile main10 --level-idc 5.1 --output-depth 10 --ctu 32 --aq-mode 1 --amp --no-rskip --qg-size 8 --vbv-bufsize 160000 --vbv-maxrate 160000 --bframes 8
--rc-lookahead 48 --gop-lookahead 30 --hdr --hdr-opt --repeat-headers --no-info --no-deblock --no-sao --allow-non-conformance --no-strong-intra-smoothing --high-tier --asm avx512 --crf 18

-preset slow --profile main10 --level-idc 5.1 --output-depth 10 --ctu 32 --aq-mode 2 --amp --no-rskip --qg-size 8 --vbv-bufsize 160000 --vbv-maxrate 160000 --bframes 8
--rc-lookahead 48 --gop-lookahead 30 --hdr --hdr-opt --repeat-headers --no-info --no-deblock --no-sao --allow-non-conformance --no-strong-intra-smoothing --high-tier --asm avx512 --crf 16

asarian

15th January 2019, 10:10

Oh, I'm sure the difference will be noticable to consumers. Simply because authors will make it so, not because it's superior. Just like in the past authors used different mixes for AC3 and DTS tracks on the same DVD. It's all about marketing. :devil:

Having an HD Amp myself, trust me, you can hear de difference! :) Try listening to Blade Runner, the Final Cut, with full HD audio, or the same movie, just with DD5.1, and I guarantee you that everything below HD audio will sound crap from there on in. :)

jd17

15th January 2019, 10:53

Having an HD Amp myself, trust me, you can hear de difference! :) Try listening to Blade Runner, the Final Cut, with full HD audio, or the same movie, just with DD5.1, and I guarantee you that everything below HD audio will sound crap from there on in. :)

That is not a very good argument against what sneaker said.

How do you know both mixes are based on the same mastering?
How do you know the DD-mix is not willingly different/worse than the HD mix?
Are you comparing identical speaker layouts (both just 5.1)?
Are you sure there is no dynamic compression in the DD-mix?
Are the volume levels identical?
Is the DD-mix limited in bitrate (384/448) or does it use the full 640kbit/s potential?

If you want a comparison of codec audio quality only, try encoding your own DD-mix from the HD-audio stream, considering all the factors above.
Even then, you cannot be sure in case of AC-3, because people claim that the original, commercial encoder is superior to those available freely... ;)

asarian

15th January 2019, 11:01

That is not a very good argument against what sneaker said.

How do you know both mixes are based on the same mastering?
How do you know the DD-mix is not willingly different/worse than the HD mix?
Are you comparing identical speaker layouts (both just 5.1)?
Are you sure there is no dynamic compression in the DD-mix?
Are the volume levels identical?
Is the DD-mix limited in bitrate (384/448) or does it use the full 640kbit/s potential?

If you want a comparison of codec audio quality only, try encoding your own DD-mix from the HD-audio stream, considering all the factors above.
Even then, you cannot be sure in case of AC-3, because people claim that the original, commercial encoder is superior to those available freely... ;)

Blade Runner is just one example. Let's not derail this thread too much, but I can assure you, that once you go HD audio, you'll never want to go back, ever. And why should that surprise anyone?! A typical DTS-MA/TrueHD track is often larger in size than an entire DVD! With bitrates around 10x higher as regular DTS, the superiority of HD audio is a no-brainer, far as I'm concerned.

excellentswordfight

15th January 2019, 12:12

And why should that surprise anyone?!
Cause 48Khz 16bit audio is very much sufficient for human hearing, and if you have enough experience of audio compression you know that there is several codecs that can achive very close to transperent audio with say 64kbps per channel (and most formats are above that!). I've encoded several surround tracks form lossless to multiple formats, you be surprised how little it affects hearable fidelity.

With that said, I'm sure that the HD-track sounds better for you, but most of that doesnt come from the higher specs (sample rate, bit depth and losslessness)

jd17

15th January 2019, 14:37

With bitrates around 10x higher as regular DTS, the superiority of HD audio is a no-brainer, far as I'm concerned.

Nobody questions that lossless - in theory, or better measurably - is always better.
However, this is a forum that pretty much evolves around compression efficiency, i.e. saving bits where we don't see or hear it.

This is why I (and plenty others here too) take these lossless audio streams and compress them to 200-600kbit/s AAC or opus.

And while these codecs are obviously far superior to the ancient AC-3, you'd be surprised how good 640kbit/s Dolby Digital really is.
Accordingly, if the same master (and volume) is used, you would most likely fail in telling TrueHD apart from Dolby Digital, if you don't know which is playing. ;)

asarian

15th January 2019, 15:31

Nobody questions that lossless - in theory, or better measurably - is always better.
However, this is a forum that pretty much evolves around compression efficiency, i.e. saving bits where we don't see or hear it.

This is why I (and plenty others here too) take these lossless audio streams and compress them to 200-600kbit/s AAC or opus.

And while these codecs are obviously far superior to the ancient AC-3, you'd be surprised how good 640kbit/s Dolby Digital really is.
Accordingly, if the same master (and volume) is used, you would most likely fail in telling TrueHD apart from Dolby Digital, if you don't know which is playing. ;)

'CD Quality' is 44.1 KHz/16 bit audio, generally considered 'very good' for music. Movies are a different thing, though. AC3 (aka DD 5.1) yields reasonable results at (almost always) 640kbps. But the difference between DTS-MA/TrueHD vs. AC3 is, well, unimaginably high. Believe me, I was in the same camp as you, one day, thinking you wouldn't be able to tell the difference... until I got an actual HD Amp. :) The fullness of the track when you switch to HD audio is staggering -- to the point where I can barely bear to listen to AC3 any more. In fact, for every Blu-ray I order (unless it's some sort of vintage deal), I first check to see whether it comes with HD Audio. If not, I simply don't buy it.

I'm not familiar with compressing audio 'to 200-600kbit/s AAC or opus' myself, so I'll take your word on those codecs.

nevcairiel

15th January 2019, 15:46

But the difference between DTS-MA/TrueHD vs. AC3 is, well, unimaginably high.

Except on a technical level it really is not.

At least DTS has a "core" you can use for a direct comparison, since it has to be from the same master. If you were to decode both the core and the full HD stream to PCM and send that PCM to your "HD Amp", I'm positive that in most cases you wouldn't even be able to tell the difference. What these devices do is cheat you by playing with volume and EQ settings that play towards how people perceive audio. Just a slight bit more volume for HD, and most people already perceive it as "better", and there is more such tricks.

Or take a HD track and re-encode it as AC3, just to ensure its the same master, and then decode both back to PCM and send that to the Amp so the Amp does not know what the original format was.

There is a lot of trickery to try to sell you on "HD" stuff, because they had to sell you something, and in fact the audio quality difference have been minimal for years. If one really goes deep into it on a technical level, you'll eventually find that out. If you just blindly trust the Amp, then sure, HD probably sounds better to you, but not because its HD audio, but because the Amp cheats you.

Atak_Snajpera

15th January 2019, 16:28

Except on a technical level it really is not.

At least DTS has a "core" you can use for a direct comparison, since it has to be from the same master. If you were to decode both the core and the full HD stream to PCM and send that PCM to your "HD Amp", I'm positive that in most cases you wouldn't even be able to tell the difference. What these devices do is cheat you by playing with volume and EQ settings that play towards how people perceive audio. Just a slight bit more volume for HD, and most people already perceive it as "better", and there is more such tricks.

Or take a HD track and re-encode it as AC3, just to ensure its the same master, and then decode both back to PCM and send that to the Amp so the Amp does not know what the original format was.

There is a lot of trickery to try to sell you on "HD" stuff, because they had to sell you something, and in fact the audio quality difference have been minimal for years. If one really goes deep into it on a technical level, you'll eventually find that out. If you just blindly trust the Amp, then sure, HD probably sounds better to you, but not because its HD audio, but because the Amp cheats you.

That whole TrueHD/Lossless audio topic reminds of 192KHz 24bit bullshit promoted by some well known companies. (Super Audio-CD , DVD-Audio and others). Facts are simple. 48Khz 16bit is more than enough for humans. Adults have hearing range up to ~18KHz ,so it still below 24Khz. The same story with bit depth.
TrueHD can sounds better than AC3 640kbps only if was encoded from better source or your amp is doing some tricks boosting artificially volume for some frequencies. (bass/trebles). If 128kbps OPUS/AAC is transparent for 2.0 then I see no reason why 320kbps wouldn't be enough for 5.1.

jd17

15th January 2019, 17:10

Believe me, I was in the same camp as you, one day, thinking you wouldn't be able to tell the difference... until I got an actual HD Amp. :) The fullness of the track when you switch to HD audio is staggering -- to the point where I can barely bear to listen to AC3 any more.

I get the feeling that you do not really understand where we are coming from...
We don't doubt you hear a difference!
But that difference is not based on codec superiority, but mastering, volume, dynamic compression and so forth.

However, we are turning in circles here, it's all been said already. You either do some legwork yourself and compare apples with apples, or you keep believing. :)

BTW, lossless-capable AVRs have been around for at least 10 years... Do you really think you are the only person here who owns one?

Sorry for the off-topic loop, let's get back to x265. :)

benwaggoner

15th January 2019, 22:57

No. I believe because GPU features would not speed x265 up. At least not without risking a loss of quality or losing the independence from hardware and software platforms (portability).

GPU features are not magical general speed-ups for every case of use, sometimes they just don't match the requirements.
I could see a 20-25% speedup for high quality encoding using GPU and fixed-function encoder features with the new, deeper Intel encoder/decoder APIs for preanalysis and such. Not because it would natively produce high quality output, but because it could help determine some optimal encoding parameters.

benwaggoner

15th January 2019, 23:07

Nobody questions that lossless - in theory, or better measurably - is always better.
I'll exactly argue against that. Information is a difference that makes a difference. A difference people can't discriminate in a proper double-blind test isn't a difference that matters.

Lossless or near lossless for sources makes sense, to the degree the extra information can eventually result in a detectable difference in derived content. Lossless, if used at all, is only used for archiving deep in studios.