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 September 2017, 15:51   #5581  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
Knowing some of the efforts Multicoreware did to develop x265, I believe we can summarize already beforehand: Being both faster and better is a miracle...

Speed is an objective metric, you can measure it.

Quality is a subjective metric, you have to ask people for their opinions; the more people participate in giving their opinions, the better the result should cover a majority of opinions.

Better quality is usually preserved by more efforts, which require more time; or it requires more space. For a fair speed-vs-quality comparison, at least the size should be as similar as possible. If there is already a remarkable size difference, then you don't need to care about the algorithmic efforts taken for quality preservation anymore, the bitrate difference already makes the test unfair. (Just like comparing accelerating cars: Nothing substitutes cylinder capacity, except more cylinder capacity.)
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 9th September 2017, 17:31   #5582  |  Link
Atak_Snajpera
RipBot264 author
 
Atak_Snajpera's Avatar
 
Join Date: May 2006
Location: Poland
Posts: 7,806
Quote:
The tangible danger is that mainstream consumers will ultimately prefer to sacrifice quality for speed, which means that lower quality, faster encoders could pose a significant threat.
I already see this when people use crappy nVidia/Intel/AMD HEVC encoder instead of x264/x265.
Atak_Snajpera is offline   Reply With Quote
Old 9th September 2017, 17:44   #5583  |  Link
NikosD
Registered User
 
Join Date: Aug 2010
Location: Athens, Greece
Posts: 2,901
Intel's HW H.264 has a decent quality for its speed and it's perfect for easy transcoding, like DVD rip-to-H.264 file.

Easy, because the resolution and the quality of MPEG2 is low and the MKV DVD rip it's huge.

Using Intel's HW H.264 encoder you get 1/10 th of the size of the DVD rip in a few minutes with comparable (almost the same) quality.

No drawbacks at all.
__________________
Win 10 x64 (19042.572) - Core i5-2400 - Radeon RX 470 (20.10.1)
HEVC decoding benchmarks
H.264 DXVA Benchmarks for all
NikosD is offline   Reply With Quote
Old 9th September 2017, 18:17   #5584  |  Link
stax76
Registered User
 
stax76's Avatar
 
Join Date: Jun 2002
Location: On thin ice
Posts: 6,837
@Atak_Snajpera

Did you actually compare (probably not with your GUI ) with sufficient bitrate like 10 Mb/s?
stax76 is offline   Reply With Quote
Old 9th September 2017, 18:49   #5585  |  Link
Atak_Snajpera
RipBot264 author
 
Atak_Snajpera's Avatar
 
Join Date: May 2006
Location: Poland
Posts: 7,806
Quote:
Originally Posted by stax76 View Post
@Atak_Snajpera

Did you actually compare (probably not with your GUI ) with sufficient bitrate like 10 Mb/s?
10 Mbps? Why not 20Mbps? With 10 MBps budget even Xvid looks decent.
Atak_Snajpera is offline   Reply With Quote
Old 9th September 2017, 18:55   #5586  |  Link
stax76
Registered User
 
stax76's Avatar
 
Join Date: Jun 2002
Location: On thin ice
Posts: 6,837
Are you sure your storage and bandwidth budget is in balance with your CPU budget? Doesn't appear so.
stax76 is offline   Reply With Quote
Old 10th September 2017, 07:32   #5587  |  Link
x265_Project
Guest
 
Posts: n/a
Quote:
Originally Posted by LigH View Post
Knowing some of the efforts Multicoreware did to develop x265, I believe we can summarize already beforehand: Being both faster and better is a miracle...

Speed is an objective metric, you can measure it.

Quality is a subjective metric, you have to ask people for their opinions; the more people participate in giving their opinions, the better the result should cover a majority of opinions.

Better quality is usually preserved by more efforts, which require more time; or it requires more space. For a fair speed-vs-quality comparison, at least the size should be as similar as possible. If there is already a remarkable size difference, then you don't need to care about the algorithmic efforts taken for quality preservation anymore, the bitrate difference already makes the test unfair. (Just like comparing accelerating cars: Nothing substitutes cylinder capacity, except more cylinder capacity.)
Why didn't they compare speed when you give both encoders 16 threads or more? Why didn't they conduct this test on a Skylake, Skylake-X or Purley Xeon system, instead of a 4 year old Haswell system? Do you think they didn't test our other performance presets before they decided to show a comparison against Ultrafast, Medium and Veryslow? Why didn't they test 1080P or smaller picture sizes? Do you think that these were the only test sequences (videos) they tried?

Obviously, a competitor can run many tests to find some combination of conditions that enables their product to compare most favorably, and cherry-pick these results. We can't do the same because they won't provide their encoder to us, or to 3rd parties for a fair comparison.

But in the end, even with a cherry-picked test design, when I compare the video, I see nothing but a big win for x265.
  Reply With Quote
Old 10th September 2017, 11:55   #5588  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
Quote:
Originally Posted by x265_Project View Post
But in the end, even with a cherry-picked test design, when I compare the video, I see nothing but a big win for x265.
And it's hard to counter this test without a copy of their encoder to run the "flan case" tests on a large variety of machines and with a more equal selection of parameters. Even if you can find a machine very similar to their test environment, you could only run the freely available software.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 10th September 2017, 12:13   #5589  |  Link
Atak_Snajpera
RipBot264 author
 
Atak_Snajpera's Avatar
 
Join Date: May 2006
Location: Poland
Posts: 7,806
Quote:
Originally Posted by LigH View Post
And it's hard to counter this test without a copy of their encoder to run the "flan case" tests on a large variety of machines and with a more equal selection of parameters. Even if you can find a machine very similar to their test environment, you could only run the freely available software.
Exactly. It very fishy that they do not provide encoder for testing.
For me Beam "something" is just another rip-off company selling nothing but "fake news".
I'm 100% sure that their "superior" encoder would fall apart to tiny pieces in park_joy or crowd_run.

Last edited by Atak_Snajpera; 10th September 2017 at 12:15.
Atak_Snajpera is offline   Reply With Quote
Old 10th September 2017, 12:28   #5590  |  Link
NikosD
Registered User
 
Join Date: Aug 2010
Location: Athens, Greece
Posts: 2,901
@all

Don't be afraid of the competition.

The way system works, it's probably the only way to get things better.

But it has to be real and fair competition in order to work.
__________________
Win 10 x64 (19042.572) - Core i5-2400 - Radeon RX 470 (20.10.1)
HEVC decoding benchmarks
H.264 DXVA Benchmarks for all
NikosD is offline   Reply With Quote
Old 10th September 2017, 12:50   #5591  |  Link
Andouille
Registered sausage
 
Andouille's Avatar
 
Join Date: May 2012
Posts: 78
Quote:
Originally Posted by x265_Project View Post
Why didn't they conduct this test on a Skylake, Skylake-X or Purley Xeon system, instead of a 4 year old Haswell system?
Because the average users computer age is that old ?
Andouille is offline   Reply With Quote
Old 10th September 2017, 13:02   #5592  |  Link
Atak_Snajpera
RipBot264 author
 
Atak_Snajpera's Avatar
 
Join Date: May 2006
Location: Poland
Posts: 7,806
Quote:
Originally Posted by NikosD View Post
@all

Don't be afraid of the competition.

The way system works, it's probably the only way to get things better.

But it has to be real and fair competition in order to work.
How can we talk about fair competition if their encoder is NOT available for testing? We all have seen over last years bold claims that some new "super-codec" beats x264 by 50% for example.
Atak_Snajpera is offline   Reply With Quote
Old 10th September 2017, 15:51   #5593  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
Indeed, just remember V-Nova Perseus ... which turned out to be no codec on its own, just a high-frequency spectral band (noise) modeller, like HE-AAC or mp3Pro.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 10th September 2017, 23:42   #5594  |  Link
roo1234
Registered User
 
Join Date: Feb 2015
Posts: 10
Quote:
Originally Posted by LigH View Post
Indeed, just remember V-Nova Perseus ... which turned out to be no codec on its own, just a high-frequency spectral band (noise) modeller, like HE-AAC or mp3Pro.
No further news or testing on this? It seemed promising for ultra low bandwidth.
roo1234 is offline   Reply With Quote
Old 11th September 2017, 12:36   #5595  |  Link
x265_Project
Guest
 
Posts: n/a
Quote:
Originally Posted by Andouille View Post
Because the average users computer age is that old ?
Actually, it was a Xeon E5 v2 (Ivy Bridge) processor, with no AVX2 support. No, I don't think it was because the average user's computer is that old. Beamr isn't trying to win any consumer business - they're shooting for commercial customers who run on servers. I think it's clear this was hand selected from among the possible options because it seems to favor their encoder the most.
  Reply With Quote
Old 11th September 2017, 14:32   #5596  |  Link
x265_Project
Guest
 
Posts: n/a
My response to Beamr - http://x265.org/beamr-hevc-encoder-comparison/
  Reply With Quote
Old 11th September 2017, 20:03   #5597  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
Hmm ... from "Epic Face Off" to "Epic Burn"?
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 11th September 2017, 22:45   #5598  |  Link
WhatZit
Registered User
 
Join Date: Aug 2016
Posts: 60
Quote:
Originally Posted by x265_Project View Post
Beamr are even gunning for your UHDcode Pro Player, as well: http://beamr.com/h264-hevc-video-comparison-player/

Watch out they don't file a sniper patent, like McDonalds did with sandwiches. That way, they can list 24 pending patents as (dubious) benefit no. 1 instead of only 23
WhatZit is offline   Reply With Quote
Old 12th September 2017, 05:09   #5599  |  Link
x265_Project
Guest
 
Posts: n/a
Quote:
Originally Posted by WhatZit View Post
Beamr are even gunning for your UHDcode Pro Player, as well: http://beamr.com/h264-hevc-video-comparison-player/
Yes, Vanguard copied our Pro Player years ago, before Beamr bought them.
  Reply With Quote
Old 14th September 2017, 11:17   #5600  |  Link
_kermit
Registered User
 
Join Date: Apr 2017
Posts: 63
Re-encode UHD

Good day,

my first post, although I follow this thread for a long time now, so first things first:
I'd like to thank you for your work. It's amazing how much effort you put into such a great and free ! solution. Really appriciated!

I'd like to re-encode some UHD material but while I found quite a bit about Quality Tuning, I'm lost when it comes to just re-encoding it, using less bandwidth, but keeping everything else the same.
In particular the HDR Parameters.

Examples:
Color range : Limited
Color primaries : BT.2020
Transfer characteristics : SMPTE ST 2084
Matrix coefficients : BT.2020 non-constant
Mastering display color primaries : R: x=0.680000 y=0.320000, G: x=0.265000 y=0.690000, B: x=0.150000 y=0.060000, White point: x=0.312680 y=0.329000
Mastering display luminance : min: 0.0050 cd/m2, max: 1000.0000 cd/m2
Maximum Content Light Level : 1000 cd/m2
Maximum Frame-Average Light Level : 96 cd/m2


Color range : Limited
Color primaries : BT.2020
Transfer characteristics : SMPTE ST 2084
Matrix coefficients : BT.2020 non-constant
Mastering display color primaries : R: x=0.680000 y=0.320000, G: x=0.265000 y=0.690000, B: x=0.150000 y=0.060000, White point: x=0.312700 y=0.329000
Mastering display luminance : min: 0.0000 cd/m2, max: 1000.0000 cd/m2


Color range : Limited
Color primaries : BT.2020
Transfer characteristics : SMPTE ST 2084
Matrix coefficients : BT.2020 non-constant
Mastering display color primaries : R: x=0.680000 y=0.320000, G: x=0.265000 y=0.690000, B: x=0.150000 y=0.060000, White point: x=0.312680 y=0.329000
Mastering display luminance : min: 0.0050 cd/m2, max: 1000.0000 cd/m2


they all have a bit different Parameters.
How would I re-encode those, while preserving all those values for each file?
I guess there is no "take those Parameters from the source file and re-use them in the target file" Option and I have to provide them manually for every file?

Can you provide an example on how to re-encode an mkv (I use ffmpeg and pipe), maybe with some good tunning tips included?

thanks!!
_kermit 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 20:06.


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