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. |
![]() |
#1701 | Link | |
Registered User
Join Date: Jan 2019
Posts: 9
|
Quote:
Here's a quick&dirty test, using an admittedly peculiar content source. Lena_std.tif from lenna.org, RGB24 converted to 8-bit 4:2:0, both downscaled and then upscaled two times each (i.e. 256x256, 1024x1024) into 250 frames long videos. All encoders are the latest versions available today on Wolfberry's public GDrive. All encoding times are reported by Win10's PowerShell: Measure-Command {start-process process -argumentlist "args" -Wait}, and expressed in milliseconds. Code:
x264 common settings: --crf 15 --preset veryslow --tune stillimage 405 --threads 1: 03130.76 || 03142.22 || 03119.85 (03130.94) 405 --threads 2: 02101.52 || 02105.54 || 02105.00 (02104.02) 420 --threads 1: 26487.85 || 27508.10 || 26479.85 (26825.27) 420 --threads 2: 16336.86 || 15308.29 || 15327.17 (15657.44) x265 common settings: --crf 15 --preset veryslow --frame-threads 1 --lookahead-slices 1 505 --no-wpp: 05160.82 || 05161.18 || 05154.55 (05158.85) 505 --wpp: 04131.71 || 04142.67 || 04131.78 (04135.39) 520 --no-wpp: 68123.55 || 68134.36 || 67103.71 (67787.21) 520 --wpp: 36649.91 || 37674.62 || 34628.27 (36317.60) x265 common settings: --crf 15 --preset placebo --cu-lossless --rd-refine --tskip -qg-size 64 --ref 6 --bframes 16 --me sea --subme 7 --frame-threads 1 --lookahead-slices 1 505 --no-wpp: 063053.81 || 061024.00 || 062028.34 (062035.38) 505 --wpp: 039684.32 || 038664.65 || 038684.41 (039011.13) 520 --no-wpp: 796345.10 || 796345.10 || 796345.10 (796345.10) 520 --wpp: 235701.00 || 235701.00 || 235701.00 (235701.00) libvpx common settings: --lag-in-frames=25 --passes=2 --end-usage=q --cq-level=20 --good --cpu-used=0 --kf-max-dist=250 --auto-alt-ref=6 --tile-rows=0 --enable-tpl=1 --frame-parallel=0 --ivf 905 --tile-columns=0 --row-mt=0 --threads=1: 05167.92 || 05164.62 || 05167.18 (05166.57) 905 --tile-columns=5 --row-mt=1 --threads=2: 04133.40 || 04143.00 || 04147.51 (04141.44) 920 --tile-columns=0 --row-mt=0 --threads=1: 50871.23 || 49853.74 || 49845.72 (50190.23) 920 --tile-columns=5 --row-mt=1 --threads=2: 31568.60 || 31571.60 || 28518.96 (30553.05) XAB .. output type X .. 4 for x264, 5 for x265, 9 for libvpx AB .. 05 for 256x256, 20 for 1024x1024 Only one x265 beyondplacebo encode at each resolution due to appalling performance. The average values are reported in brackets, for each output type and encoding settings. 1. x264 is at least twice faster than either x265 or lipvpx, at comparable encoding complexity. 2. x265 parallelizes better than libvpx as encoding complexity increases. 3. x265 versylow is at best comparable with the slowest libvpx settings, lagging behind as the resolution increases. 4. x265 beyondplacebo is significantly slower than the slowest libvpx settings. As mentioned above, this is just one possible comparison. The enthusiasts should definitely do their own, and only then report whichever encoder to be the speed demon. It's very hard to conceive that chunk-based libvpx (the obvious caveats aside: logistical hassle and quality issues) is ever slower than x265 regardless of the hardware footprint, each of them at its highest encoding complexity. But instead of testing themselves (with whatever source they please, at whatever resolution and bit depth, on whatever encoding machine), people prefer to reiterate ad absurdum that libvpx is always slower than x265. And it was, indeed, years ago. Last edited by Asilurr; 31st May 2019 at 10:02. |
|
![]() |
![]() |
![]() |
#1702 | Link | |||
Registered User
Join Date: Jan 2007
Posts: 739
|
Quote:
Quote:
Quote:
Last edited by mandarinka; 31st May 2019 at 13:44. |
|||
![]() |
![]() |
![]() |
#1703 | Link | |
Registered User
Join Date: Dec 2002
Posts: 5,570
|
Quote:
![]() You could do a fast first pass for scenechange detection and vbv estimation and send the chunks along with that info. |
|
![]() |
![]() |
![]() |
#1704 | Link | |
Registered Developer
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,072
|
Quote:
Its just how it goes. And for UHD Blu-ray discs, they can just throw massive bitrates at it to solve any such issues. As said above, it all comes back to the same thing: If you want a codec for a use-case that noone else focuses on, then do the work, instead of the complaining. ![]()
__________________
LAV Filters - open source ffmpeg based media splitter and decoders |
|
![]() |
![]() |
![]() |
#1705 | Link | |
Registered User
Join Date: Jan 2007
Posts: 739
|
Quote:
Also you can't really expect users to jump to programming and so that shouldn't really be thought of as a solution. Even if with the open source principles, you are actually entitled to it. But, it's not like, easy to do. Second, users want to do the using, not switching roles to open source programmers. It's probably easier to just not use such software (and use x264, x265, whatever is better). Though with this "open formats" movement/fandom/advocacy, there is this curious anomaly that people are so strong subscribers to the concept that they want to use it even if it "is not for them" at all... well there are lots of weird layers to these debates. I think this superstrong mindshare that bends people's views is another reason why pointing out the technical problems should keep being done. And not brushed aside by "it's not for you" arguments. The enthusiasts al over the internets seem to think "it" is for them, by the look of it. Maybe sometimes they also think all those winning compression tests and netflix blogs are also for them (while perhaps they also aren't?). Last edited by mandarinka; 31st May 2019 at 19:33. |
|
![]() |
![]() |
![]() |
#1706 | Link | |
Registered User
Join Date: May 2005
Location: Swansea, Wales, UK
Posts: 184
|
Quote:
The guy under the name xiph_mont was working on a new audio codec called Ghost when Daala started up in earnest and it was abandoned - and he later moved to AV1 development with most of those that worked on Daala. |
|
![]() |
![]() |
![]() |
#1707 | Link |
Registered User
Join Date: Aug 2009
Posts: 198
|
Xiphmont was employed by Red Hat and Mozilla, both companies that have a business model (and a mission) incompatible with codec licenses and therefore strong motivation for "me-too" codecs that they can integrate properly.
(Which reminds me, VP9 has been the default codec choice for webRTC in Firefox and Chrome for a couple of years. I can't quickly find any stats on what kind of usage this gets. Originally the browsers agreed a compromise of supporting both VP8 and H.264 baseline and Firefox shipped that via a licencing hack where Cisco provide the binary blob and it doesn't cost them anything in licence fees because they were already at the annual cap.) |
![]() |
![]() |
![]() |
#1708 | Link |
Registered User
Join Date: Mar 2002
Posts: 857
|
What's the difference between deltaq and AQ in aomenc? Deltaq changes the quantizer of the frames, and AQ changes the quantizers of the blocks within the frames, or am i completely wrong?
Also, what is tpl-model, what does it do? |
![]() |
![]() |
![]() |
#1709 | Link |
Registered User
Join Date: Aug 2015
Posts: 34
|
Deltaq is at superblock granularity, whereas "AQ" uses segment support which is down to 4x4 granularity. The two bitstream features are sorta redundant but their coding is optimized for different uses - Deltaq was designed for sub-frame rate targeting, and segments are more for mbtree/psy purposes.
|
![]() |
![]() |
![]() |
#1710 | Link | |
Registered User
Join Date: Mar 2002
Posts: 857
|
Quote:
|
|
![]() |
![]() |
![]() |
#1715 | Link | |
Registered User
Join Date: May 2016
Posts: 20
|
Quote:
I find your comment extremely surprising considering your join date of 2006. I would expect such a comment from a newbie. Unless the entirety of the developer and encoding community are lying to me, what is occurring with AV1 is absolutely par the norm for new codecs. 265 is still a dog to encode without a reasonable monster of a PC. How will an even more compressed, newer codec, that's open (and therefore can't break terrible patents) begin to compete only 6 months in? The only thing that AV1 has going for it, is it's openness and the hope that /so many players/ throwing themselves at the problem, will slowly address the performance issues. None the less, it's been 6 months. You're not going to see this getting hardware acceleration for at least 6 more months on any devices. I suspect it'll be ubiquitous at best case scenario of 3 years. (more experienced members, welcome to correct me) |
|
![]() |
![]() |
![]() |
#1716 | Link | |
Registered User
Join Date: May 2016
Posts: 20
|
Quote:
Yet here you are outlining exactly why it is very unlikely to and it kind of blows me away, you're totally correct. AV1 /at scale/ when a video is being watched upwards of 500 times a week, makes so much more sense. Those encode times will eventually pay for themselves. |
|
![]() |
![]() |
![]() |
#1718 | Link |
Registered Developer
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,072
|
__________________
LAV Filters - open source ffmpeg based media splitter and decoders |
![]() |
![]() |
![]() |
#1719 | Link |
Registered User
Join Date: Aug 2010
Location: Athens, Greece
Posts: 2,901
|
nVidia and AMD (possibly Intel for Gen11 iGPUs) could add in drivers a hybrid decoding approach of AV1 using the GPU itself (shaders) but not ASIC yet.
__________________
Win 10 x64 (19042.572) - Core i5-2400 - Radeon RX 470 (20.10.1) HEVC decoding benchmarks H.264 DXVA Benchmarks for all |
![]() |
![]() |
![]() |
#1720 | Link | |
.
Join Date: Dec 2006
Posts: 174
|
Quote:
It's kinda strange we have projects like x264/x265 for patent encumbered H.264/H.265 codecs, yet nothing like that for VP9/AV1. Last edited by birdie; 9th June 2019 at 19:55. |
|
![]() |
![]() |
![]() |
Thread Tools | Search this Thread |
Display Modes | |
|
|