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.

 

Go Back   Doom9's Forum > Video Encoding > New and alternative video codecs

Reply
 
Thread Tools Search this Thread Display Modes
Old 13th October 2021, 00:00   #561  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
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?
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 13th October 2021, 12:30   #562  |  Link
FranceBB
Broadcast Encoder
 
FranceBB's Avatar
 
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,883
Quote:
Originally Posted by benwaggoner View Post
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.
Yep, re-doing the test at a much lower bitrate is what I also wanna do 'cause it will definitely highlight more things. The 25 Mbit/s were picked 'cause our current UHD playout live H.265 hardware encoder is using 25 Mbit/s for every content, so I wanted the test to be as realistic as possible.

Quote:
Originally Posted by benwaggoner View Post
Does the oscillation correlates with B-frames or something? Is it visible in full-speed playback?
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.
FranceBB is offline   Reply With Quote
Old 14th October 2021, 06:42   #563  |  Link
Jamaika
Registered User
 
Join Date: Jul 2015
Posts: 697
Quote:
Originally Posted by FranceBB View Post
Yep, re-doing the test at a much lower bitrate is what I also wanna do 'cause it will definitely highlight more things. The 25 Mbit/s were picked 'cause our current UHD playout live H.265 hardware encoder is using 25 Mbit/s for every content, so I wanted the test to be as realistic as possible.

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.
I failed to produce ABR for 10Mbps. Wrong data in VVC come out. I found bitrate low. As a curiosity I added CBR QP 24 for yuv420p10le bt2020 VVC and EVC placebo. The obtained result for codecs with similar codec technology. EVC has twice bitrate in I/P/B frames. This would mean either artificially inflating the result to better advertise the EVC codec or bugs in the VVC codec. Unfortunately for 4K 10Mbps there is lot of grayscale pixel averaging.

Last edited by Jamaika; 14th October 2021 at 06:47.
Jamaika is offline   Reply With Quote
Old 20th October 2021, 18:58   #564  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
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.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 21st October 2021, 11:15   #565  |  Link
birdie
Artem S. Tashkinov
 
birdie's Avatar
 
Join Date: Dec 2006
Posts: 337
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.
birdie is offline   Reply With Quote
Old 21st October 2021, 17:32   #566  |  Link
Jamaika
Registered User
 
Join Date: Jul 2015
Posts: 697
Quote:
Originally Posted by birdie View Post
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.
OpenVVC is a bit strange.https://github.com/OpenVVC/OpenVVC/c...6b5f096dabf895
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
Jamaika is offline   Reply With Quote
Old 22nd October 2021, 17:32   #567  |  Link
ksec
Registered User
 
Join Date: Mar 2020
Posts: 117
VVenC 1.2.0 released

https://github.com/fraunhoferhhi/vve...ses/tag/v1.2.0

Quote:
major efficiency improvement for faster, minor speedups for fast and medium
allowing separate encoding of first and second pass in 2pRC (using a statistics data file)
improvements to single picture and low-rate rate-control
added support for packed 10 bit YUVs
added a balanced IDR refresh mode (using IDR_W_RADL in first intra period)
improvements to ALF, DMVR, error handling and others
various fixes and cleanups
__________________
Previously iwod
ksec is offline   Reply With Quote
Old 22nd October 2021, 19:13   #568  |  Link
birdie
Artem S. Tashkinov
 
birdie's Avatar
 
Join Date: Dec 2006
Posts: 337
Quote:
Originally Posted by ksec View Post
And we still have zero players. I've only found VQProbe but it's an analyzer, not a player, so I've no idea whether it can play audio or play in full screen mode.
birdie is offline   Reply With Quote
Old 23rd October 2021, 00:09   #569  |  Link
Balling
Registered User
 
Join Date: Feb 2020
Posts: 539
Quote:
Originally Posted by birdie View Post
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.
There is also this. https://patchwork.ffmpeg.org/project...t/?series=3487
Balling is offline   Reply With Quote
Old 23rd October 2021, 00:36   #570  |  Link
birdie
Artem S. Tashkinov
 
birdie's Avatar
 
Join Date: Dec 2006
Posts: 337
Quote:
Originally Posted by Balling View Post
This patchset allows ffmpeg to recognize VVC bitstream data, it doesn't contain an actual decoder implementation either directly or though an external library. IOW it's useless.
birdie is offline   Reply With Quote
Old 25th October 2021, 11:03   #571  |  Link
contemporarymind
Registered User
 
Join Date: Aug 2021
Posts: 4
Quote:
Originally Posted by birdie View Post
And we still have zero players. I've only found VQProbe but it's an analyzer, not a player, so I've no idea whether it can play audio or play in full screen mode.
There's a couple proof-of-concept players by now based on vvdec, even for the browser. no audio though...

https://github.com/bitmovin/vvDecPlayer
https://github.com/fraunhoferhhi/vvdecWebPlayer
contemporarymind is offline   Reply With Quote
Old 25th October 2021, 18:46   #572  |  Link
Balling
Registered User
 
Join Date: Feb 2020
Posts: 539
Quote:
Originally Posted by birdie View Post
This patchset allows ffmpeg to recognize VVC bitstream data, it doesn't contain an actual decoder implementation either directly or though an external library. IOW it's useless.
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.
Balling is offline   Reply With Quote
Old 30th October 2021, 15:59   #573  |  Link
birdie
Artem S. Tashkinov
 
birdie's Avatar
 
Join Date: Dec 2006
Posts: 337
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?
birdie is offline   Reply With Quote
Old 31st October 2021, 11:09   #574  |  Link
Dann0245
Registered User
 
Join Date: Apr 2020
Posts: 23
Quote:
Originally Posted by birdie View Post
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?
They listed on their website many months ago.

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.
Dann0245 is offline   Reply With Quote
Old 11th November 2021, 17:25   #575  |  Link
birdie
Artem S. Tashkinov
 
birdie's Avatar
 
Join Date: Dec 2006
Posts: 337
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.
birdie is offline   Reply With Quote
Old 15th November 2021, 05:29   #576  |  Link
Selur
Registered User
 
Selur's Avatar
 
Join Date: Oct 2001
Location: Germany
Posts: 7,259
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.
__________________
Hybrid here in the forum, homepage
Selur is offline   Reply With Quote
Old 15th November 2021, 05:58   #577  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
Quote:
Originally Posted by Dann0245 View Post
They listed on their website many months ago.

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.
The complexity jump in new tools is a lot bigger in absolute terms than from H.264 to H.265, so that's more new code to write. Relative complexity jump is about on par.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 16th November 2021, 19:30   #578  |  Link
MoSal
Registered User
 
Join Date: Jun 2013
Posts: 95
Quote:
Originally Posted by Selur View Post
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.
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
MoSal is offline   Reply With Quote
Old 16th November 2021, 23:45   #579  |  Link
RanmaCanada
Registered User
 
Join Date: May 2009
Posts: 328
Quote:
Originally Posted by Selur View Post
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.
Sadly it was the same thing with HEVC when it was being tested. You can't buy literally 90% of the codecs or encoders they used, so it's geared more towards industrial aspects like security camera or broadcasting.
RanmaCanada is offline   Reply With Quote
Old 17th November 2021, 09:24   #580  |  Link
foxyshadis
ангел смерти
 
foxyshadis's Avatar
 
Join Date: Nov 2004
Location: Lost
Posts: 9,558
Quote:
Originally Posted by FranceBB View Post
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.
Rate control in general always seems to be one of the biggest bugbears of any prototype encoder. SSIM is a flawed measure but oscillating that much is absolutely going to be visible, the same way Xvid and early versions of x264 worked. It's a painful amount of iteration, trying to optimize for a whole spectrum of use cases and completely unknown upcoming features, so I can understand why it doesn't get as much love as say, a new SIMD optimization that can be directly benched against the C as an immediate improvement.
foxyshadis is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 21:48.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.