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. |
16th March 2018, 23:29 | #501 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,783
|
No, I could only agree: I would expect multi-threaded processing of frames, possibly in a slices or wavefront partition technology. (AFAIR, AV1 still uses small macroblock-like windows, just more overlapping to neighborhoods...)
|
17th March 2018, 03:41 | #502 | Link |
Angel of Night
Join Date: Nov 2004
Location: Tangled in the silks
Posts: 9,559
|
I don't think anyone but the developers know what half the options mean or do, though some expected values are in the code. You might try --cpu-used=8, which is supposed to max out the processing power.
Actually don't bother, that argument does nothing, they nerfed it without removing the option. Hm. Maybe pthreads isn't detected correctly? OK, tracing the code, you have to have more than one tile-column to get more than one thread; threading is tile-based only. You'd think default would equal threads, but...? |
17th March 2018, 06:01 | #503 | Link |
Registered User
Join Date: Mar 2002
Posts: 863
|
--cpu-used is actually the speed/quality slider, it has nothing to do with threading, they just named it stupidly. The lower it is, the more additional tools and searches are enabled, so 0 is the highest quality, but ridiculously slow, and 8 is the "fastest", but lowest quality.
|
17th March 2018, 12:58 | #504 | Link |
Registered User
Join Date: Dec 2002
Posts: 1,022
|
This cmdline
ffmpeg -i moto--x264-8bit-420-1080p2400fps-468frames.mp4 -strict -1 -f yuv4mpegpipe - | aomenc -w 1920 -h 1080 -v --fps=24000/1000 --cpu-used=8 --dev-sf=255 --tile-columns=6 --limit=48 --i420 -t 24 -b 8 --input-bit-depth=8 --end-usage=cbr --target-bitrate=1024 -p 1 --webm --num-tile-groups=32 -o aomout.webm - resulted in aomenc running 15 threads and cpu load bouncing around between 4 and 20 percent. Encoding 48 frames took approx. 10 minutes. |
17th March 2018, 14:54 | #505 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,783
|
IMHO, aomenc (and vpxenc the same way) will need a lot of simplification regarding sane defaults and relations between parameters to become user friendly... balancing the presets (and "everything default" equals to the "medium" preset) for x264 and x265 took quite an important part of their development efforts.
Last edited by LigH; 17th March 2018 at 14:57. |
17th March 2018, 17:05 | #506 | Link |
Registered User
Join Date: Dec 2002
Posts: 1,022
|
Source: 1080p24 8bit 4:2:0 468 frames (19.5 seconds)
cmdline: ffmpeg -i moto--x264-8bit-420-1080p2400fps-468frames.mp4 -strict -1 -f yuv4mpegpipe - | aomenc -w 1920 -h 1080 -v --fps=24000/1000 --cpu-used=4 --tile-columns=6 --i420 -t 14 -b 8 --input-bit-depth=8 --end-usage=vbr --target-bitrate=1024 -p 1 --webm -o aomout.webm - Encoding took 74 minutes, running on 14 threads. Output has a reported (mediainfo) bitrate of 1047 kbps. Oddly enough framerate is reported as 24.025 fps. |
17th March 2018, 17:50 | #509 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,783
|
Hmm, yes, it looks a bit like "duration / (framecount-1)". So, maybe the opposite way, aomenc counted the duration of the last frame, MediaInfo instead assumes it does not count.
|
17th March 2018, 22:54 | #510 | Link |
Registered User
Join Date: Dec 2002
Posts: 1,022
|
I encoded the same 1080p24 8bit 4:2:0 source on aomenc 0.1.0-8449-g6471e8bd7 twice, first with --cpu-used=4 and then with --cpu-used=2. Target bitrate was set for 1024 kbps. Below are the 3SSIM Metric graphs for both encodes.
--cpu-used=4 (green) took 4440 seconds to encode, while --cpu-used=2 (red) took 9060 seconds. Last edited by colinhunt; 17th March 2018 at 23:00. |
20th March 2018, 17:32 | #511 | Link |
Registered User
Join Date: Jun 2016
Posts: 55
|
IETF 101: https://www.youtube.com/watch?v=qS7hfrFWeic
Spec is somewhat "frozen", so only bugfixes left. Last edited by bstrobl; 20th March 2018 at 17:42. |
20th March 2018, 19:15 | #512 | Link | |
Registered User
Join Date: Apr 2002
Posts: 756
|
Quote:
As said in the video, there are still crap loads of things going on under the hood. That is not necessarily a bad thing, they are taking the time to properly finish it. But I have slightly less confident given how they have handle it, I hope they release a preview or beta to the industry before going final. |
|
20th March 2018, 19:20 | #513 | Link |
Registered Developer
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,348
|
The part of the industry that cares is involved in the development already, so whats left?
__________________
LAV Filters - open source ffmpeg based media splitter and decoders |
20th March 2018, 19:21 | #514 | Link |
Registered User
Join Date: Jun 2016
Posts: 55
|
The interesting part about the xvc presentation is that this is basically the current state of JVET/JEM, along with its current bitrate performance that ISO/ITU and co. have managed to achieve.
Obviously there is no way in hell Divideon is getting away with basically a direct rip of JVET, so if xvc gains any commercial ground whatsoever it will simply get sued into oblivion or into updating and making a poor codec. Might as well use VP9/AV1 in that case, especially if no old files become incompatible. The best they can hope for is to basically become a replacement for MPEG LA, but I don't see any lists where they have gained any companies as licensors. |
20th March 2018, 21:27 | #515 | Link | |
Registered User
Join Date: Mar 2004
Posts: 1,126
|
Quote:
P.S mediainfo 18.03 has just been released that can detect AV1 files: http://mediaarea.net/en/MediaInfo Last edited by hajj_3; 20th March 2018 at 22:12. |
|
23rd March 2018, 13:13 | #516 | Link |
Registered User
Join Date: Feb 2015
Posts: 45
|
https://www.golem.de/news/videocodec...03-133457.html
According to this German article, the bitstream has been frozen with just a few bugs to work out. I hope that hardware decoders can come a lot sooner than we expect, and that nvidia and arm have already been working on them. |
23rd March 2018, 15:35 | #517 | Link | |
Registered User
Join Date: Mar 2004
Posts: 1,126
|
Quote:
|
|
24th March 2018, 11:52 | #518 | Link |
Registered User
Join Date: Jan 2002
Posts: 332
|
some tests with foreman clip @250kbit/s on my i7-2600k:
x264 - core 155 r2901 7d0ff22 preset : placebo real bitrate 263 kb/s size 321 KiB time : pass 1 : 1s pass 2 : 9s total time : 10 s metrics : SSIM All:0.948739 (12.902161) PSNR average:36.585589 VMAF score = 93.379718 x265 - 2.7+3-9086c8a3e76d:[Windows][GCC 7.3.0][64 bit] 8bit+10bit+12bit preset : veryslow real bitrate 254 kb/s size 311 KiB time : pass 1 : 39s pass 2 : 39s total time : 78 s metrics : SSIM All:0.952898 (13.269586) PSNR average:37.447079 VMAF score = 95.024192 libvpx-vp9 v1.7.0-213-gf4b1eca53 preset : cpu-used 0 real bitrate 238 kb/s size 291 KiB time : pass 1 : 2s pass 2 : 68s total time : 70 s metrics : SSIM All:0.952918 (13.271442) PSNR average:37.275722 VMAF score = 94.977788 aomenc 0.1.0-8871-g7a3c26460 preset : cpu-used 2 real bitrate 252 kb/s size 307 KiB time : pass 1 : 2s pass 2 : 1254s total time : 1256 s metrics : SSIM All:0.951930 (13.181228) PSNR average:37.565993 VMAF score = 95.79106 aomenc is real slow for the moment and with cpu-used 2 . I won't try 1080p file for the moment =p |
24th March 2018, 12:04 | #519 | Link |
Registered User
Join Date: Dec 2005
Location: Germany
Posts: 1,795
|
The most important part: Which one of the encodes pleases your eyes the most?
__________________
AVSRepoGUI // VSRepoGUI - Package Manager for AviSynth // VapourSynth VapourSynth Portable FATPACK || VapourSynth Database Last edited by ChaosKing; 24th March 2018 at 12:15. |
24th March 2018, 13:03 | #520 | Link |
Registered User
Join Date: Jan 2002
Posts: 332
|
here you have the result files. I add a av1->x264 (crf 0) file .
https://www.sendspace.com/file/bm5el8 For me av1 is the most "clean" |
|
|