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. |
27th October 2017, 17:36 | #321 | Link | |
Registered User
Join Date: Aug 2015
Posts: 34
|
Quote:
Code:
--preset placebo --no-wpp --bframes 16 --merange 256--min-keyint 1000 --keyint 1000 --no-scenecut --crf=$x This is done on the AWCY infrastructure. Here are two more recent results, still with the old x265 runs: https://arewecompressedyet.com/?job=...3A43%3A40.468Z with --tune psnr https://arewecompressedyet.com/?job=...3A43%3A40.468Z |
|
27th October 2017, 19:09 | #322 | Link | |||
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
|
Quote:
Code:
--preset placebo --no-wpp --bframes 16 --merange 256--min-keyint 1000 --keyint 1000 --no-scenecut --crf=$x
Quote:
Also, none of the metrics I've seen published have particularly good correlation to DMOS. If you can't do a real subjective test, you should at least include VMAF, which is definitely the best available subjective metric today. Quote:
But, really, these results don't matter with an old version. There has been a ton of tuning since that x265 build. Ones relevant to placebo 8-bit SDR testing include:
And bitrates need to be used where all streams to be tested show some degree of compression artifacting. If any stream is visually lossless for any significant period, we don't know if the bitrate is higher than is needed to be visually lossless. That tends to underestimate the advantage of the more efficient encoder. Two tests I like are: VBR:
CBR:
The minimum viable objective metric is VMAF, in my opinion. All the ones currently used for this comparison don't include temporal comparisons(need to catch keyframe strobing and grain swirling!), and all have lots of known defects resulting in poor subjective comparisons. Plus the average of squared errors of individual frames does nothing to pick up on quality variation inside of a clip. A clip that is 3 second great and 3 seconds awful can have a better psnr and ssim as a clip that is consistently mediocre, but consistently mediocre is a much better subjective experience. I understand that is why rate control is deactivated in codec comparisons, but that itself assumes that QP==constant quality, when we know it isn't (which is why CRF was invented). The better the metrics being used, the more relevant the comparison. And it is also helpful for designers of new bitstreams and encoders to get them focused on optimizing the stuff that really matters. The whole sum of squared PSNR and no rate control biases codec development for codecs where fixed QP optimizes for high mean PNSR per frame. And that just isn't something that matters in a real-world encoder with rate control, adaptive quantization, and watched by humans. It is illustrative to encode with --tune psnr and see the ways that subjective quality degrades when optimizing for that metric. Or just using fixed QP. Last edited by benwaggoner; 27th October 2017 at 19:16. Reason: Bad bullets |
|||
27th October 2017, 23:32 | #323 | Link | ||||||
Registered User
Join Date: Aug 2015
Posts: 34
|
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
I also do want to warn that I've seen VMAF give rather unexpected results. For example, AV1's CDEF filter produced clearly superior results in a subjective test but VMAF shows it as several percent worse. In addition, VMAF hates x264 and x265's AQ modes. The greatest strength of VMAF is that it tends to offer an absolute quality measure across different types of video - but locally it's far from perfect. |
||||||
30th October 2017, 08:25 | #324 | Link | |
Registered User
Join Date: Apr 2002
Posts: 756
|
Quote:
But I dont think it matters, at least I hope that is the way Open Media Alliance sees it. If they are in it for the long run. AV1 shouldn't really be perfect. But it should be a statement to the world, that it is possible to do video codec this way. Then I hope they will start drafting a AV2 spec along with a ecosystem around it. But given the way google does thing, I am not holding my breath. |
|
30th October 2017, 17:46 | #325 | Link | |||||
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
|
Quote:
Quote:
Quote:
Quote:
Quote:
In theory, the VMAF framework can be used, but using new clips to retrain the ML. In practice, I think VMAF will need and enhanced temporal component to capture a broader range of codecs and scenarios. In particular, I think the current VMAF will underestimate the perceptual experience hit of keyframe strobing, and thus wouldn't capture Open versus Closed GOP differences. Overall, I think you're making a very good effort here. This is really hard stuff to do well. Fundamentally, there are lots of real-world things we want to predict from metrics that we simply can't predict well. Even DMOS has its limitations, as it takes so long that the results generally don't reflect the abilities of encoder implementations by the time they are published. And golden eyes have all kinds of biases. I know I am so trained to pick up and classic forms of encoding issues that I notice things real-world customers almost never will. We continue to slouch towards mediocrity. |
|||||
1st November 2017, 11:04 | #326 | Link | |
Registered User
Join Date: Jun 2016
Posts: 55
|
Quote:
Can't complain about the current state that much however, AV1 is still a very good codec As for the ecosystem, I am hoping for a family of related container formats, something like: webm - video (AV1/Opus) webp - picture (AV1 Intra) - throw out VP8 weba - audio (Opus) It would definitely help to market these codecs and formats a bit more to the general populace. Not sure AVIF is that great to pronounce Last edited by bstrobl; 1st November 2017 at 11:09. |
|
1st November 2017, 13:13 | #327 | Link | |
Registered User
Join Date: Mar 2004
Posts: 1,120
|
Quote:
|
|
1st November 2017, 13:25 | #328 | Link | ||
Registered User
Join Date: Oct 2009
Posts: 930
|
Quote:
I think AV2 should be something fundamentally different (for the better) and they'll finish it whenever they do. Quote:
It's only good for HW manufacturers, who can resale the same crap, but with a newer HW decoder. Last edited by mzso; 1st November 2017 at 13:28. |
||
1st November 2017, 18:51 | #329 | Link |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
|
Why not use MPEG-4 program streams for video, HEIF for picture, and MPEG-4 program streams for audio? Dropping in a new codec is a lot easier than full support for a new container format. And we have a LOT of mature muxing, distribution, and playback tech built around MPEG-4 PS.
|
1st November 2017, 18:57 | #330 | Link | |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
|
Quote:
The goal isn't just to replace JPEG, but also PNG and GIF. HEIF+HEVC is a superset of all of JPEG, PNG, and GIF, and offers better efficiency than any of them for all their scenarios, and adds a lot of additional scenarios as well (like real PQ Rec. 2020 style HDR). An HEIF+AV1 would likely have similar potential. |
|
1st November 2017, 21:04 | #331 | Link | |
Registered User
Join Date: Mar 2004
Posts: 1,120
|
Quote:
|
|
2nd November 2017, 10:28 | #332 | Link | ||
Registered User
Join Date: Jun 2016
Posts: 55
|
Quote:
I guess the point is to use simplified containers dedicated to few codecs to ensure a decent chance of compatibility, as dropping in newer codecs onto old containers may cause frustrations in the future. HEIF is also a very large spec from what I can tell, would make sense to use a heavily simplified version to ensure compatibility and reliability for standard web distribution. WebP is still at version 0.6 so something could still be fixed up for version 1.0 rather than ditching the name. Ingraining format names like JPEG can be quite useful sometimes. Quote:
Last edited by bstrobl; 2nd November 2017 at 10:31. |
||
2nd November 2017, 21:48 | #333 | Link | |
Registered User
Join Date: Jun 2013
Posts: 95
|
Quote:
* For a new image format to gain relevant success, browser vendors will have to reach a consensus. Google and Mozilla are not going to support anything HEVC or MPEG based. * weba is already the unofficial extension of YouTube's Opus WebM DASH streams. weba/Opus/~160kbps is the highest quality 2ch audio format available (MP4/AAC/256kbps is discontinued). * For local storage, Matroska works, and will work, just fine with any codec combination. * Browsers will support AV1/Opus in WebM by default (muxed or separate, including live DASH/WebM streams).
__________________
https://github.com/MoSal |
|
2nd November 2017, 23:59 | #334 | Link | |
Registered User
Join Date: Aug 2015
Posts: 34
|
Quote:
As far as a still image format, I dunno. HEIF is an option, though it has its own problems (it would be too easy for it to just be a single frame video track, so it's got a totally separate codec mapping). |
|
8th November 2017, 10:22 | #335 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
|
Since MABS is able to build aomenc/aomdec as separate encoder/decoder application pair, I wanted to try it once with a small sample (Siemens "foreman", CIF PAL, 300 frames, Derf's Y4M fixed to 25 fps), running on an AMD Phenom-II X4 (other encoders want to use at most SSE2 here).
Basic batch: Code:
aomenc -v --passes=2 --pass=1 --fpf=foreman_cif.basic.av1.fpf --target-bitrate=300 -o foreman_cif.basic.av1.webm foreman_cif_pal.y4m aomenc -v --passes=2 --pass=2 --fpf=foreman_cif.basic.av1.fpf --target-bitrate=300 -o foreman_cif.basic.av1.webm foreman_cif_pal.y4m Code:
>aomenc -v --passes=2 --pass=1 --fpf=foreman_cif.basic.av1.fpf --target-bitrate=300 -o foreman_cif.basic.av1.webm foreman_cif_pal.y4m Codec: AOMedia Project AV1 Encoder v0.1.0-6495-g63d190aea Source file: foreman_cif_pal.y4m File Type: Y4M Format: I420 Destination file: foreman_cif.basic.av1.webm Coding path: LBD Encoder parameters: g_usage = 0 g_threads = 8 g_profile = 0 g_w = 352 g_h = 288 g_bit_depth = 8 g_input_bit_depth = 8 g_timebase.num = 1 g_timebase.den = 25 g_error_resilient = 0 g_pass = 0 g_lag_in_frames = 19 rc_dropframe_thresh = 0 rc_resize_mode = 0 rc_resize_denominator = 8 rc_resize_kf_denominator = 8 rc_end_usage = 0 rc_target_bitrate = 300 rc_min_quantizer = 0 rc_max_quantizer = 63 rc_undershoot_pct = 25 rc_overshoot_pct = 25 rc_buf_sz = 6000 rc_buf_initial_sz = 4000 rc_buf_optimal_sz = 5000 rc_2pass_vbr_bias_pct = 50 rc_2pass_vbr_minsection_pct = 0 rc_2pass_vbr_maxsection_pct = 2000 kf_mode = 1 kf_min_dist = 0 kf_max_dist = 9999 Pass 1/2 frame 300/301 55384B 1476b/f 36922b/s 3788536 us (79.19 fps) >aomenc -v --passes=2 --pass=2 --fpf=foreman_cif.basic.av1.fpf --target-bitrate=300 -o foreman_cif.basic.av1.webm foreman_cif_pal.y4m Pass 2/2 frame 22/3 24753B 1018316 ms 1.30 fpm [ETA 6:55:11] 4F Pass 2/2 frame 24/5 25314B 1435997 ms 1.00 fpm [ETA 8:18:27] 4F The ETA will rise the longer I let it ... do whatever it does. Such a speed is ... "concerning", nicely said. And I wonder what the reason could be: Is there a minimum CPU requirement for assembly optimized routines way beyond SSE2? Or is there a possible mis-configuration in the build? Or are the computational efforts so extreme when not capped by a per-frame deadline? Unfortunately, there is no support in ffmpeg yet (JEEB mentioned some shared variable names with libvpx in IRC), thus no playback in LAV Filters (e.g. in MPC-HC) yet, either. At most it is detected... Code:
Codecs: D..... = Decoding supported .E.... = Encoding supported ..V... = Video codec ..A... = Audio codec ..S... = Subtitle codec ...I.. = Intra frame-only codec ....L. = Lossy compression .....S = Lossless compression ------- ..V.L. av1 Alliance for Open Media AV1 Last edited by LigH; 9th November 2017 at 20:51. |
8th November 2017, 15:44 | #336 | Link | |
Registered User
Join Date: Mar 2002
Posts: 863
|
Quote:
|
|
8th November 2017, 15:52 | #337 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
|
I do now ... for my hardware, 4 is still a challenge (~10 min for 300 frames CIF). And I guess to watch the result, I still need to decode it to Y4M again...
BTW, what's this hex code at the end of the progress line? A flag for developers, giving hints about the result type and efficiency? Last edited by LigH; 8th November 2017 at 15:57. |
8th November 2017, 22:46 | #338 | Link | |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
|
Quote:
I don't have any specific thoughts about how HEVC and AV1 would compare technically as still image codecs. Also, I would speculate that a lot of the HEVC IP wouldn't apply to still image encoding; so much is around interframe encoding. |
|
9th November 2017, 20:58 | #339 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
|
Brief result: Tested --cpu-used 8..4 with rather low speed differences (every run around 10 minutes) and with quite good quality (no really annoying artefacts, except for floating textures). Will postpone further tests here, no immediate relevance for me, personally.
|
Thread Tools | Search this Thread |
Display Modes | |
|
|