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 September 2017, 15:51 | #5581 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,783
|
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.) |
9th September 2017, 17:31 | #5582 | Link | |
RipBot264 author
Join Date: May 2006
Location: Poland
Posts: 7,815
|
Quote:
__________________
Windows 7 Image Updater - SkyLake\KabyLake\CoffeLake\Ryzen Threadripper |
|
9th September 2017, 17:44 | #5583 | Link |
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 |
9th September 2017, 18:17 | #5584 | Link |
Registered User
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?
__________________
https://github.com/stax76/software-list https://www.youtube.com/@stax76/playlists |
9th September 2017, 18:49 | #5585 | Link |
RipBot264 author
Join Date: May 2006
Location: Poland
Posts: 7,815
|
10 Mbps? Why not 20Mbps? With 10 MBps budget even Xvid looks decent.
__________________
Windows 7 Image Updater - SkyLake\KabyLake\CoffeLake\Ryzen Threadripper |
9th September 2017, 18:55 | #5586 | Link |
Registered User
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.
__________________
https://github.com/stax76/software-list https://www.youtube.com/@stax76/playlists |
10th September 2017, 07:32 | #5587 | Link | |
Guest
Posts: n/a
|
Quote:
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. |
|
10th September 2017, 11:55 | #5588 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,783
|
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.
|
10th September 2017, 12:13 | #5589 | Link | |
RipBot264 author
Join Date: May 2006
Location: Poland
Posts: 7,815
|
Quote:
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.
__________________
Windows 7 Image Updater - SkyLake\KabyLake\CoffeLake\Ryzen Threadripper Last edited by Atak_Snajpera; 10th September 2017 at 12:15. |
|
10th September 2017, 12:28 | #5590 | Link |
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 |
10th September 2017, 13:02 | #5592 | Link |
RipBot264 author
Join Date: May 2006
Location: Poland
Posts: 7,815
|
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.
__________________
Windows 7 Image Updater - SkyLake\KabyLake\CoffeLake\Ryzen Threadripper |
11th September 2017, 12:36 | #5595 | Link |
Guest
Posts: n/a
|
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.
|
11th September 2017, 14:32 | #5596 | Link |
Guest
Posts: n/a
|
My response to Beamr - http://x265.org/beamr-hevc-encoder-comparison/
|
11th September 2017, 22:45 | #5598 | Link | |
Registered User
Join Date: Aug 2016
Posts: 60
|
Quote:
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 |
|
12th September 2017, 05:09 | #5599 | Link | |
Guest
Posts: n/a
|
Quote:
|
|
14th September 2017, 11:17 | #5600 | Link |
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!! |
|
|