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. |
13th October 2021, 00:00 | #561 | Link |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,770
|
Great stuff @FranceBB!
HEVC and VVC are both approaching the SSIM saturation point, and it might be interested to redo the AVC/HEVC/VVC comparison at perhaps 10 Mbps CBR. The greater variability of SSIM between VVC frames is also interesting. VVC has some impressive motion artifact suppression technologies that might score a lot better psychovisually than SSIM (which is fundamentally designed for still image comparisons, not video). Does the oscillation correlates with B-frames or something? Is it visible in full-speed playback? |
13th October 2021, 12:30 | #562 | Link | |
Broadcast Encoder
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,903
|
Quote:
What I've noticed is relatively interesting. So basically we all know that any encoder is gonna assign more bits to the I than it will to the P and B, however if we compare it with the H.265 stream, we can see that x265 is spreading those a bit more evenly than VVEnc is for H.266. Let me be more specific: basically, since the final encode is gonna be CBR, I can see how "large" each frame is gonna be in the GOP and what I've noticed is that in H.265 we have like: Intra large, P and B a bit smaller, while in H.266 we have like: Intra very large, P and B much smaller to have the same bitrate in the end in both encodes, which means that either VVEnc better detected the blocks and macroblocks across the scene and was able to use motion compensation in a better way OR it's using some of the new psychovisual features so that it "thinks" that it doesn't need as much bitrate, but it actually does. What I can say, though, is that in motion, if you look closely, you can see the difference as you look at the grain pattern in the back which appears to be blurrier than other frames in the exact same points in which the SSIM score drops, so it looks like something didn't go as expected, but from my experience I feel like this has something to do with the VVEnc implementation rather than H.266 itself. I'm pretty sure that we're gonna see the bitrate much more evenly spread (and much closer to how it's spread in x265) in x266 when it will become available. Last edited by FranceBB; 13th October 2021 at 12:33. |
|
14th October 2021, 06:42 | #563 | Link | |
Registered User
Join Date: Jul 2015
Posts: 705
|
Quote:
Last edited by Jamaika; 14th October 2021 at 06:47. |
|
20th October 2021, 18:58 | #564 | Link |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,770
|
When a codec gets better bidirectional prediction, you'd expect the I/P to b ratio to get higher. Visually do you see any issues before or after?
SSIM isn't a particularly sensitive metric, and the same QP can look different in different codecs. At this early stage, we need to be relying on visual examination. If we have to use metrics, the newest version of VMAF is the best available for SDR content. |
21st October 2021, 11:15 | #565 | Link |
Artem S. Tashkinov
Join Date: Dec 2006
Posts: 345
|
An ffmpeg fork with VVC decoding support: https://github.com/tbiat/FFmpeg
Not a huge fan since it's not exactly clear how it's been patched. Separate patches against the known ffmpeg git snapshot would be better. |
21st October 2021, 17:32 | #566 | Link | |
Registered User
Join Date: Jul 2015
Posts: 705
|
Quote:
Code:
dpb.c:1183:28: warning: passing argument 1 of 'pthread_mutex_lock' discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers] 1183 | pthread_mutex_lock(&decoded_ctus->ref_mtx); | ^~~~~~~~~~~~~~~~~~~~~~ In file included from dec_structures.h:5, from ovdec_internal.h:8, from ovdpb.h:8, from dpb.c:10: c:\msys1200\x86_64-w64-mingw32\include\pthread.h:1039:69: note: expected 'struct pthread_mutex_t_ **' but argument is of type 'struct pthread_mutex_t_ * const*' 1039 | PTW32_DLLPORT int PTW32_CDECL pthread_mutex_lock (pthread_mutex_t * mutex); | ~~~~~~~~~~~~~~~~~~^~~~~ Code:
drv.c:3:45: error: unknown type name 'VVCMV' 3 | fill_mvp_map(struct VVCMVCtx *const mv_ctx, VVCMV mv, | ^~~~~ drv.c:17:114: error: unknown type name 'VVCMV' 17 | fill_dbf_mv_map_b(struct DBFInfo *const dbf_info, struct VVCMVCtx *const mv_ctx, struct VVCMVCtx *const mv_ctx1, VVCMV mv, | ^~~~~ drv.c:57:80: error: unknown type name 'VVCMV' 57 | fill_dbf_mv_map(struct DBFInfo *const dbf_info, struct VVCMVCtx *const mv_ctx, VVCMV mv, | ^~~~~ drv.c:93:8: error: unknown type name 'VVCMergeInfo' 93 | static VVCMergeInfo | ^~~~~~~~~~~~ drv.c:94:14: error: unknown type name 'VVCLocalContext' 94 | derive_mvp_b(VVCLocalContext *const lc_ctx, | ^~~~~~~~~~~~~~~ drv.c:95:20: error: unknown type name 'VVCPartSize' 95 | const VVCPartSize *const part_ctx, | ^~~~~~~~~~~ drv.c:98:14: error: unknown type name 'VVCMV' 98 | VVCMV mvd0, VVCMV mvd1, | ^~~~~ drv.c:98:26: error: unknown type name 'VVCMV' 98 | VVCMV mvd0, VVCMV mvd1, | ^~~~~ drv.c:99:14: error: unknown type name 'uint8_t' 99 | uint8_t mvp_idx0, uint8_t mvp_idx1, | ^~~~~~~ drv.c:1:1: note: 'uint8_t' is defined in header '<stdint.h>'; did you forget to '#include <stdint.h>'? +++ |+#include <stdint.h> 1 | drv.c:99:32: error: unknown type name 'uint8_t' 99 | uint8_t mvp_idx0, uint8_t mvp_idx1, | ^~~~~~~ drv.c:99:32: note: 'uint8_t' is defined in header '<stdint.h>'; did you forget to '#include <stdint.h>'? drv.c:100:14: error: unknown type name 'uint8_t' 100 | uint8_t inter_dir) | ^~~~~~~ drv.c:100:14: note: 'uint8_t' is defined in header '<stdint.h>'; did you forget to '#include <stdint.h>'? drv.c:147:17: error: unknown type name 'VVCLocalContext' 147 | update_mv_ctx_b(VVCLocalContext *const lc_ctx, struct VVCInterCtx *const inter_ctx, | ^~~~~~~~~~~~~~~ drv.c:148:23: error: unknown type name 'VVCPartSize' 148 | const VVCPartSize *const part_ctx, | ^~~~~~~~~~~ drv.c:149:23: error: unknown type name 'VVCMV' 149 | const VVCMV mv0, const VVCMV mv1, | ^~~~~ drv.c:149:40: error: unknown type name 'VVCMV' 149 | const VVCMV mv0, const VVCMV mv1, | ^~~~~ drv.c:152:17: error: unknown type name 'uint8_t' 152 | uint8_t inter_dir) | ^~~~~~~ Code:
nvcl_hrd.c:5:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token 5 | { | ^ nvcl_hrd.c:11:3: warning: data definition has no type or storage class 11 | } OVSubLayerHRD; | ^~~~~~~~~~~~~ nvcl_hrd.c:11:3: warning: type defaults to 'int' in declaration of 'OVSubLayerHRD' [-Wimplicit-int] nvcl_hrd.c:36:50: error: unknown type name 'subLayerId' 36 | sublayer_hrd_parameters(OVNVCLReader *const rdr, subLayerId) | ^~~~~~~~~~ nvcl_hrd.c:55:52: error: unknown type name 'firstSubLayer' 55 | ols_timing_hrd_parameters(OVNVCLReader *const rdr, firstSubLayer, MaxSubLayersVal) | ^~~~~~~~~~~~~ nvcl_hrd.c:55:67: error: unknown type name 'MaxSubLayersVal' 55 | ols_timing_hrd_parameters(OVNVCLReader *const rdr, firstSubLayer, MaxSubLayersVal) | ^~~~~~~~~~~~~~~ nvcl_hrd.c:82:1: warning: return type defaults to 'int' [-Wimplicit-int] 82 | general_timing_hrd_parameters(OVNVCLReader *const rdr) | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ nvcl_hrd.c: In function 'general_timing_hrd_parameters': nvcl_hrd.c:85:5: error: 'ghrd' undeclared (first use in this function) 85 | ghrd->num_units_in_tick = nvcl_read_bits(rdr, 32); | ^~~~ nvcl_hrd.c:85:5: note: each undeclared identifier is reported only once for each function it appears in |
|
22nd October 2021, 17:32 | #567 | Link | |
Registered User
Join Date: Mar 2020
Posts: 117
|
VVenC 1.2.0 released
https://github.com/fraunhoferhhi/vve...ses/tag/v1.2.0 Quote:
__________________
Previously iwod |
|
23rd October 2021, 00:09 | #569 | Link | |
Registered User
Join Date: Feb 2020
Posts: 541
|
Quote:
|
|
23rd October 2021, 00:36 | #570 | Link | |
Artem S. Tashkinov
Join Date: Dec 2006
Posts: 345
|
Quote:
|
|
25th October 2021, 11:03 | #571 | Link | |
Registered User
Join Date: Aug 2021
Posts: 4
|
Quote:
https://github.com/bitmovin/vvDecPlayer https://github.com/fraunhoferhhi/vvdecWebPlayer |
|
25th October 2021, 18:46 | #572 | Link |
Registered User
Join Date: Feb 2020
Posts: 541
|
The trace_headers implementation is always the first one! There is no point to implement presenter if bitstream parser is not done. same for AV1 (there is a very simple low overheader parser in ffmpeg not used for decoding) and also there is a parser of HDR10+, no support for presenting HDR10+ yet.
Last edited by Balling; 4th November 2021 at 23:20. |
30th October 2021, 15:59 | #573 | Link |
Artem S. Tashkinov
Join Date: Dec 2006
Posts: 345
|
So, MulticoreWare now lists x266 encoder among its products, yet its git repo continues to be members only, what's going on? Have I missed something?
|
31st October 2021, 11:09 | #574 | Link | |
Registered User
Join Date: Apr 2020
Posts: 23
|
Quote:
I don't know but they seem to need more time for the first version of x266 than x265, and there is no any player support yet. Last edited by Dann0245; 31st October 2021 at 13:19. |
|
11th November 2021, 17:25 | #575 | Link |
Artem S. Tashkinov
Join Date: Dec 2006
Posts: 345
|
The latest MSU codecs comparison: https://compression.ru/video/codec_c...in_report.html at FullHD.
TLDR: H.266 shines except for high-speed/RT encoding where H.265 implementations are still better. Looks like you can test their codec for free: https://www.huaweicloud.com/intl/en-us/product/mpc.html - I want to try this. Last edited by birdie; 11th November 2021 at 17:38. |
15th November 2021, 05:29 | #576 | Link |
Registered User
Join Date: Oct 2001
Location: Germany
Posts: 7,277
|
So the conclusion of that comparision is that in theory you get the best qulits with these three encoders: HW266, S266_vX, Tencent266 but since they are closed source and not available to try or buy you can't use them.
|
16th November 2021, 19:30 | #578 | Link |
Registered User
Join Date: Jun 2013
Posts: 95
|
On the other hand, it's the first time I hear about xin26x which could develop into a good encoder suite if the developers ever get to a stage where some effort is spent on subjective tuning.
__________________
https://github.com/MoSal |
17th November 2021, 09:24 | #580 | Link | |
Angel of Night
Join Date: Nov 2004
Location: Tangled in the silks
Posts: 9,559
|
Quote:
|
|
Thread Tools | Search this Thread |
Display Modes | |
|
|