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. |
22nd November 2018, 18:47 | #1241 | Link | |
Registered User
Join Date: Aug 2010
Location: Athens, Greece
Posts: 2,901
|
Quote:
Scaling to more threads and better hyperthreading implementation along with better clocks (?) for the specific SKUs, probably gave RyZen the clear lead.
__________________
Win 10 x64 (19042.572) - Core i5-2400 - Radeon RX 470 (20.10.1) HEVC decoding benchmarks H.264 DXVA Benchmarks for all |
|
22nd November 2018, 19:52 | #1242 | Link |
Registered User
Join Date: Jan 2007
Posts: 729
|
The Haswell chips they use for testing is a mobile 4C/8T quadcore which probably runs with low clocks (probably some macbook, so...) and the other is a 4C/4T lower-price desktop SKU which is why it will have lower performance than Ryzen. BTW that Ryzen is a hexacore 6C/12T anyway (yay for AMD!).
|
22nd November 2018, 20:49 | #1243 | Link |
Registered User
Join Date: Aug 2008
Posts: 343
|
Wonder how they ran six/eight thread benchmark on 4core/4 thread cpu. If they did, that means decoder has internal switch for thread count. And whats more, single core is underutilized since more CPU threads gives more performance. And since benchmark on 6 core zen gives better results than on 4 thread haswell means AOM decoder they compare to, is highly single threaded. Both decoders have still room to improve anyway.
And. If they compare speed on 12 thread zen this means they compare threading. Global Comparison benchmark shows it. Last edited by littleD; 22nd November 2018 at 20:55. |
26th November 2018, 00:17 | #1244 | Link |
Registered User
Join Date: Apr 2018
Posts: 63
|
I encoded the full 4096x1714 4K version of Tears of Steel with libaom.
Bitrate of the final file is about 3.5mbit/s, and quality is definitely on a scale of at least "very good". Have fun looking what aom can do with that little bitrate, or at benchmarking: https://drive.google.com/drive/folde...uL?usp=sharing |
26th November 2018, 18:47 | #1245 | Link | |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,770
|
Quote:
Can you share the command line you used? |
|
26th November 2018, 19:22 | #1246 | Link |
Registered User
Join Date: Jan 2002
Posts: 332
|
@utack
with my AMD 2700x and libdav1d : 98 fps. frame=17620 fps= 98 q=-0.0 Lsize=N/A time=00:12:14.16 bitrate=N/A speed=4.09x video:9223kB audio:412879kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown bench: utime=1003.859s stime=182.547s rtime=179.705s bench: maxrss=2521828kB Did you encode with some tiles ? because It only use 40-50% of the CPU. You should, it encode faster ( use more threads ) and decode also faster . |
26th November 2018, 20:39 | #1247 | Link | |
I am maddo saientisto!
Join Date: Aug 2018
Posts: 95
|
Quote:
row-mt can maximise CPU usage at encode time, but as you said the lack of tiles reduces playback performance Last edited by SmilingWolf; 26th November 2018 at 20:42. |
|
26th November 2018, 21:47 | #1248 | Link | |
Registered User
Join Date: Apr 2018
Posts: 63
|
A little over 3 days
It is in the google drive folder xz -dc tearsofsteel-4k.y4m.xz | aomenc --cpu-used=4 --row-mt=1 --threads=8 --kf-max-dist=250 --bias-pct=75 --webm -o sk.webm --end-usage=q --aq-mode=1 --cq-level=44 --codec=av1 --passes=2 --pass=2 --fpf=/tmp/fpf - Quote:
https://bugs.chromium.org/p/aomedia/...detail?id=2262 Using dav1d for playback with frame parallel decoding works great, and also does not crash when it reaches the "corrupt" frame |
|
26th November 2018, 21:55 | #1249 | Link |
Registered User
Join Date: Jan 2002
Posts: 332
|
My try with the first 1500 frames @1000kb/s with row-mt + tiles
My 2 pass command line : 7z.exe" x "ToS_1920x800_xdither.7z" -so | aomenc.exe --cpu-used=4 --row-mt=1 --threads=16 --tile-columns=4 --tile-rows=2 --kf-max-dist=250 --bias-pct=75 --webm -o tos.webm --target-bitrate=1000 --codec=av1 --passes=2 --pass=2 --fpf=fpf --limit=1500 - Pass 2/2 frame 1500/1481 8290530B 2633147 ms 34.18 fpm [ETA unknown] Pass 2/2 frame 1500/1500 8314991B 44346b/f 1064304b/s 2656175 ms (0.56 fps) And the result file : https://www.sendspace.com/file/dcf6ii It seems to decode fine for me. Last edited by easyfab; 26th November 2018 at 22:03. |
26th November 2018, 22:01 | #1250 | Link | |
I am maddo saientisto!
Join Date: Aug 2018
Posts: 95
|
Quote:
No reason to give that up IMO BTW, just to be clear, using row-mt does NOT automatically introduce tiling. Using AOMAnalyzer to take a look at the clip confirms that every frame is just one big tile. There are no columns nor rows @easyfab: That's interesting, that it decodes properly. It used to croak in the first couple frames for me (http://forum.doom9.org/showthread.ph...31#post1856831) Maybe it has been fixed and it flew under my radar. Guess I'll check now EDIT: Holysmoly you're right, mixing tiles, threads and row-mt together has been fixed! Last edited by SmilingWolf; 26th November 2018 at 22:17. |
|
26th November 2018, 22:19 | #1251 | Link |
Registered User
Join Date: Jan 2002
Posts: 332
|
for me ( 16 threads cpu ) without tiles, row-mt alone is more than 2x slower ( only use 4/6 threads / cpu usage 10-20 % ) less than 20 fpm.
with row-mt + tiles it use all threads ( cpu usage 50-60% ) and give 34 fpm on TOS 1500 first frames . I'm ok to loose a bit quality with tiles to gain 2x speed. Last edited by easyfab; 26th November 2018 at 22:23. |
26th November 2018, 22:22 | #1252 | Link |
I am maddo saientisto!
Join Date: Aug 2018
Posts: 95
|
We share the same opinion. The tradeoffs are vastly in favour of tiling
|
28th November 2018, 00:30 | #1253 | Link | |
Registered User
Join Date: May 2009
Location: Hungary
Posts: 79
|
Quote:
This is almost unbelievable given the codec's infancy. |
|
28th November 2018, 10:34 | #1254 | Link |
Registered User
Join Date: Nov 2009
Location: Northeast Ohio
Posts: 447
|
Are you playing this back with dav1d or libaom?
__________________
____HTPC____ | __Desktop PC__
2.93GHz Xeon x3470 (4c/8t Nehalem) | 4.5GHz 1.24v dual-core Haswell G3258 Radeon HD5870 | Intel iGPU 2x2GB+2x1GB DDR3-1333 | 4x4GB DDR3-1600 |
29th November 2018, 22:10 | #1255 | Link |
Registered User
Join Date: May 2009
Location: Hungary
Posts: 79
|
I tried it with the latest mpv on Arch Linux. It uses libaom by default:
Code:
[vd] Codec list: [vd] libaom-av1 (av1) - libaom AV1 [vd] Opening decoder libaom-av1 [vd] No hardware decoding requested. [vd] Using software decoding. [vd] Detected 4 logical cores. [vd] Requesting 5 threads for decoding. [ffmpeg/video] libaom-av1: 1.0.0 [vd] Selected codec: libaom-av1 (libaom AV1) |
6th December 2018, 19:57 | #1256 | Link |
Registered User
Join Date: Jan 2007
Posts: 729
|
I see nobody talking about it here, yet, but it seems Google or some other members decided to "unfreeze" the bitstream, there will by the look of it be an incompatible AV1.1.0 revision.
Supposedly it's mostly driven by requests of hardware implementers which wanted to restrict the format a bit in some places. It looks like hardware might only implement AV1.1.0 mostly, not AV1.0? (This is a bit speculative, maybe there will be exceptions). Current AV1.0 decoders will support the more restricted AV1.1.0 streams but new (hardware) decoders targetting AV1.1.0 won't be compatible with AV1.0 video. Rather messy, IMHO they should have just delayed the codec finalization and do it properly the first time around, instead of this, but I guess politics prevailed. There's remarkable silence about it, but I guess it's not the best news so they don't want to brag about it too much until it's final (not sure if the decision is set in stone already). |
6th December 2018, 20:33 | #1257 | Link | |
Registered User
Join Date: Apr 2018
Posts: 63
|
Quote:
These should have never been implemented in a new codec the first place, it is just a lazy workaround because libaom sucks at frame parallel encoding and decoding. rav1e and dav1d won't need them |
|
6th December 2018, 21:34 | #1258 | Link |
I am maddo saientisto!
Join Date: Aug 2018
Posts: 95
|
Ronald Bultje commented on frame parallelism being a bad thing for VP9, so not much of a surprise it was turned off by default in AV1/libaom
Tiles help with decoding, do I have to re-link my tests every time this stuff is brought up? The proposed changes to tile width management only had to be set in stone, all I know is that they have been the de-facto standard in the libaom codebase since at least this summer, when I first began encoding 1080p clips. EDIT: looks like I was thinking about something else in these regards, nevermind And since we're talking about this, why at least not link the to the source of the news? https://www.reddit.com/r/AV1/comment...lude_breaking/ Last edited by SmilingWolf; 6th December 2018 at 22:07. |
6th December 2018, 22:31 | #1259 | Link | |
Registered Developer
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,346
|
Quote:
In any case, at the current point in time, AV 1.0 bitstreams will just eventually vanish, and AV 1.1 will be the actual standard people use. Outside of tech demos, AV1 is generally unused still. And with knowing this change is here, noone is going to adopt it now until this is cleared up and "final" again.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders Last edited by nevcairiel; 6th December 2018 at 22:33. |
|
8th December 2018, 01:08 | #1260 | Link |
Registered User
Join Date: Jan 2007
Posts: 729
|
I can't tell how correct it is, but this was an interesting read: https://codecs.multimedia.cx/2018/12...cal-about-av1/
Author is a former libav/ffmpeg developer if you don't remember his name. |
Thread Tools | Search this Thread |
Display Modes | |
|
|