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 28th August 2019, 21:50   #141  |  Link
iwod
Registered User
 
Join Date: Apr 2002
Posts: 756
Quote:
Originally Posted by benwaggoner View Post
Yeah, so much about AV1's future is dependent on codec licensing and businesss issues that AOM has no control over.

VVC will definitely offer better compression efficiency than AV1, and it seems increasingly probably it can do so with fewer MIPS/watts/mm^2 of silicon.

Of course, the more viable AV1 is, the more pressure there would be on VVC patent holders to come up with a clearer licensing story than HEVC has been dealing with.
LOL, my original post was so full of spelling mistakes I couldn't even comprehend what I was trying to say.

Competition is great.

But I do see the need of Free to use Codec, I just wish they could allow VVC to be royalty free for software uses, and only collect royalty on dedicated hardware.
iwod is offline   Reply With Quote
Old 31st August 2019, 07:52   #142  |  Link
Jamaika
Registered User
 
Join Date: Jul 2015
Posts: 697
VVC codecs after the holidays
Unfortunately, the VVC codec is working more slowly. They are currently underdeveloped. Will there be any improvements to coding speed? Is unknown. HDR HLG functions are currently being finalized.

Opensource HLG https://www.isovideo.com/SDR_to_HLG1...n_Examples.php
Adds VVC 6.1 codecs NONE/SSE41/SSE42/AVX/AVX2 (Codec AVX512 doesn't create in Windows with function -mavx512)
https://www.sendspace.com/file/0qb856

Last edited by Jamaika; 31st August 2019 at 17:38.
Jamaika is offline   Reply With Quote
Old 3rd September 2019, 19:31   #143  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
Quote:
Originally Posted by iwod View Post
LOL, my original post was so full of spelling mistakes I couldn't even comprehend what I was trying to say.

Competition is great.

But I do see the need of Free to use Codec, I just wish they could allow VVC to be royalty free for software uses, and only collect royalty on dedicated hardware.
I'm also very interested to see where EVC/MPEG-5 fits into the decision matrix. That spec is supposed to be done around end of the year.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 3rd September 2019, 19:33   #144  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
Quote:
Originally Posted by Jamaika View Post
VVC codecs after the holidays
Unfortunately, the VVC codec is working more slowly. They are currently underdeveloped. Will there be any improvements to coding speed? Is unknown. HDR HLG functions are currently being finalized.

Opensource HLG https://www.isovideo.com/SDR_to_HLG1...n_Examples.php
Adds VVC 6.1 codecs NONE/SSE41/SSE42/AVX/AVX2 (Codec AVX512 doesn't create in Windows with function -mavx512)
https://www.sendspace.com/file/0qb856
Performance optimization of MPEG reference encoders isn't a huge priority. Generally they make it fast enough to make experimentation possible, but assume actual commercial encoders are where practical speed/quality improvements go.

VPx and AV1 have been kind of unique in having a reference encoder that is also the primary production encoder. Although that is more due to the relative lack of a market for commercial VPx encoders historically.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 4th September 2019, 05:02   #145  |  Link
Jamaika
Registered User
 
Join Date: Jul 2015
Posts: 697
Quote:
Originally Posted by benwaggoner View Post
Performance optimization of MPEG reference encoders isn't a huge priority. Generally they make it fast enough to make experimentation possible, but assume actual commercial encoders are where practical speed/quality improvements go.
What surprises me when encoding VVC?
When I convert material already processed by HEVC, the VVC codec encodes much faster than source. However, do I see these differences in quality video for QP32? No
Thread support is troublesome. There is a combination of POSIX <thread>, <mutex> and linux <pthread> functions which is incorrect. You can't add thread larger than one.
Quote:
Originally Posted by benwaggoner View Post
VPx and AV1 have been kind of unique in having a reference encoder that is also the primary production encoder. Although that is more due to the relative lack of a market for commercial VPx encoders historically.
For me the big surprise is the AV1 MPEG-4.
Jamaika is offline   Reply With Quote
Old 9th September 2019, 06:15   #146  |  Link
Jamaika
Registered User
 
Join Date: Jul 2015
Posts: 697
Tutorial: Generate Microsoft Visual Studio Solution for VTM+360Lib— 360-Degree Video Using VVC Codec (Video Coding)

Compared to HEVC/H.265, VVC/H.266 should allow data rate savings of up to 50%, according to the German research institute. Thus, a more efficient data transmission is possible in the fixed and especially in the mobile network, where data capacity is limited. For example, a 90-minute Ultra HD video encoded with HEVC/H.265 currently requires around 10GB of data, while with VVC/H.266 it will only take up around 5GB.

Last edited by Jamaika; 9th September 2019 at 06:24.
Jamaika is offline   Reply With Quote
Old 9th September 2019, 08:05   #147  |  Link
iwod
Registered User
 
Join Date: Apr 2002
Posts: 756
Quote:
Originally Posted by Jamaika View Post
Tutorial: Generate Microsoft Visual Studio Solution for VTM+360Lib— 360-Degree Video Using VVC Codec (Video Coding)

Compared to HEVC/H.265, VVC/H.266 should allow data rate savings of up to 50%, according to the German research institute. Thus, a more efficient data transmission is possible in the fixed and especially in the mobile network, where data capacity is limited. For example, a 90-minute Ultra HD video encoded with HEVC/H.265 currently requires around 10GB of data, while with VVC/H.266 it will only take up around 5GB.
That is 15Mbps for HEVC, who the hell do that on a mobile network?

All these figures are always giving best case scenario, i want a 50% saving in low end, 2-4Mbps range.

Last time I read, VVC communities would actually like to push for more than 50% savings. I wonder if that is still the case.
iwod is offline   Reply With Quote
Old 10th September 2019, 17:23   #148  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
Quote:
Originally Posted by iwod View Post
That is 15Mbps for HEVC, who the hell do that on a mobile network?
That is possible on some LTE networks already. It is pretty trivial for WiFi.

Quote:
All these figures are always giving best case scenario, i want a 50% saving in low end, 2-4Mbps range.

Last time I read, VVC communities would actually like to push for more than 50% savings. I wonder if that is still the case.
It's hard to predict the savings of a new codec without production-ready encoder implementations, but everything I hear suggests that VVC is quite plausibly capable of delivering the same perceptual quality as HEVC at half the bitrate, with encoders with similar degrees of development. It'll take a while before a generalized 50% would become available, though, as HEVC encoders are way more mature. There's more scope in adapting a VVC encoder from an HEVC one than, say, a AV1 encoder from a HEVC, since the foundation is a lot similar. One could take an existing HEVC encoder and start adding features from the VVC reference encoder and get to a compliant bitstream pretty quickly, and then start iterating on newer tools and quality tuning.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 10th September 2019, 17:29   #149  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
Quote:
Originally Posted by Jamaika View Post
What surprises me when encoding VVC?
When I convert material already processed by HEVC, the VVC codec encodes much faster than source. However, do I see these differences in quality video for QP32? No
Do you mean you aren't seeing a subjective difference in quality at QP32 between HEVC and VVC?

Quote:
For me the big surprise is the AV1 MPEG-4.
What about it? There was a mapping for VP9 to MPEG-4 IIRC.

The MPEG-4 file format and systems layer are very mature with a huge ecosystem around it, and without codec-specific patent issues. The QuickTime file format that it was based on was extremely flexible. It's hard to imagine what value there would be in a whole new file format or systems layer that couldn't be better within or as extensions to MPEG-4.

For professional content, it's really all MPEG-4. MKV is the other format I see used some, but mainly for personal use, and I don't think there is anything MKV can do that MPEG-4 can't; it's more about the installed base of authoring tools and players for MKV. A generic MPEG-4 player wouldn't have the UI to use all the tracks and other info that could be in a MKV-parity MPEG-4 file, so having a different extension is helpful.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 11th September 2019, 05:33   #150  |  Link
Jamaika
Registered User
 
Join Date: Jul 2015
Posts: 697
Quote:
Originally Posted by benwaggoner View Post
Do you mean you aren't seeing a subjective difference in quality at QP32 between HEVC and VVC?
I'm not seeing a subjective difference. I did the test for HD. Maybe we are talking about large 8K sizes.
Quote:
Originally Posted by benwaggoner View Post
One could take an existing HEVC encoder and start adding features from the VVC reference encoder and get to a compliant bitstream pretty quickly, and then start iterating on newer tools and quality tuning.
From what I see, there is no desire for HEVC to follow this direction. The introduction of VVC also means the replacement of TV sets.

Last edited by Jamaika; 11th September 2019 at 05:37.
Jamaika is offline   Reply With Quote
Old 14th September 2019, 09:56   #151  |  Link
Jamaika
Registered User
 
Join Date: Jul 2015
Posts: 697
Adds VVC 6.1 codecs NONE{HDRTools}/NONE{360°}/SSE41/SSE42/AVX/AVX2 (library 360° & AVX512 doesn't create video in Windows with function -mavx512)

https://www.sendspace.com/file/5rgdpv
Jamaika is offline   Reply With Quote
Old 15th September 2019, 06:58   #152  |  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 Jamaika View Post
Adds VVC 6.1 codecs NONE{HDRTools}/NONE{360°}/SSE41/SSE42/AVX/AVX2 (library 360° & AVX512 doesn't create video in Windows with function -mavx512)

https://www.sendspace.com/file/5rgdpv
Thank you for the updated binary.

I wanted to test it again, so I decided to use a few files from a lazy day at work when we went outside and we shot a few samples in 4K Log-C XAVC Intra Class 300 500 Mbit/s. They're gonna be with my ugly face on them, sorry about that. Anyway, I'm trying to encode them in H.266 but it's not only taking an eternity, it's also not very well parallelized as it's using 1 core at a time at 100% on my Dual Xeon setup.
This wouldn't be a big deal, except for the fact that there's no percentage and no estimation, I have to check myself for which frame it has encoded and make a guess.
Can I ask you a progress/percentage/number of frames encoded output in cmd like the one we have in x264/x265 or even like the one in ffmpeg/ffmbc?
I mean, at the current stage of things there's just the terminal showing how each and every frame is encoded and it's taking minutes, literally minutes to encode a single frame and I have two Intel Xeon E5-2630 v3 overclocked at 3.00GHz (from the stock 2.40 GHz), for a total of 16 core, 32 threads and 40 MB of cache L3 and support to instructions up to AVX2 and 32GB of RAM, not exactly a crappy hardware.

Img1: Link
Img2: Link
Img3: Link


This is what I mean:





The AVS Script is just a simple append:

Code:
FFVideoSource("Y:\France\FILE format\File_Test_France\Canon EOS R (Clog)\KU6A0648.MP4")
video1=last
FFVideoSource("Y:\France\FILE format\File_Test_France\Canon EOS R (Clog)\KU6A0649.MP4")
video2=last
FFVideoSource("Y:\France\FILE format\File_Test_France\Canon EOS R (Clog)\KU6A0650.MP4")
video3=last
FFVideoSource("Y:\France\FILE format\File_Test_France\Canon EOS R (Clog)\KU6A0652.MP4")
video4=last
FFVideoSource("Y:\France\FILE format\File_Test_France\Canon EOS R (Clog)\KU6A0653.MP4")
video5=last
FFVideoSource("Y:\France\FILE format\File_Test_France\Canon EOS R (Clog)\KU6A0655.MP4")
video6=last

video1++video2++video3++video4++video5++video6
And the BAT is the following one:

Quote:
@echo off

C:\encoder\encoder\Processors\ffmpeg\x86\ffmpeg.exe -y -loglevel error -i "C:\Encoding\file1.avs" -an -f rawvideo -strict -1 lossless.yuv

pause

EncoderApp_avx.exe --SummaryVerboseness -c "encoder_randomaccess_vtm.cfg" --InputFile=lossless.yuv --BitstreamFile=logc4ktest.vvc --SourceWidth=3840 --SourceHeight=2160 --FrameRate=25 --InputColorPrimaries=1 --InputSampleRange=1 --InputBitDepth=8 --InternalBitDepth=10 --OutputBitDepth=10 --MSBExtendedBitDepth=10 --InputChromaFormat=420 --ChromaFormatIDC=420 --MatrixCoefficients=9 --ConformanceWindowMode=1 --FramesToBeEncoded=1334 --AspectRatioInfoPresent=1 --VideoSignalTypePresent=1 --ChromaLocInfoPresent=1 --VideoFullRange=1

pause
With 16 GB worth of lossless uncompressed video I had to encode out of 1334 frames in XAVC Intra Class 300 4K 25fps.


Source (XAVC Intra Class 300):
Part 1: https://we.tl/t-xvfMxO4dag
Part 2: https://we.tl/t-D4jY7OtqM4


Encoded (H.266 VVC - Incomplete -):
Link: https://we.tl/t-zWSxzCSeF8

(I'm gonna upload the encoded file as soon as it finishes to encode).


EDIT: Alright folks, I fired up the encode at 09 AM. It's 5PM over here and it's still far from the end, but I gotta go and I can't keep my computer busy. I stopped the encode and I uploaded what my Xeon managed to encode so far after 8 hours of encoding. If someone else wants to try to encode it, feel free to do it.
I gotta say that I do wanna help with VVC testing, however if it takes so much time to encode on such a powerful machine it becomes hard for me to help...

Last edited by FranceBB; 15th September 2019 at 16:09.
FranceBB is offline   Reply With Quote
Old 15th September 2019, 18:03   #153  |  Link
Jamaika
Registered User
 
Join Date: Jul 2015
Posts: 697
Quote:
Originally Posted by FranceBB View Post
I'm trying to encode them in H.266 but it's not only taking an eternity, it's also not very well parallelized as it's using 1 core at a time at 100% on my Dual Xeon setup.
There should be two by four cores when adding libgomp, but for gcc it's not. I suppose there is a bug in the VVC software.
In X265 with threads four, Number Wpp Threads is equal to two.
Is this an OpenMP software problem? I don't know. I know that VS2019 is the latest version 5.0, not 3.0 for libgomp.
Quote:
Originally Posted by FranceBB View Post
This wouldn't be a big deal, except for the fact that there's no percentage and no estimation, I have to check myself for which frame it has encoded and make a guess.
Can I ask you a progress/percentage/number of frames encoded output in cmd like the one we have in x264/x265 or even like the one in ffmpeg/ffmbc?
For config "encoder_randomaccess_vtm.cfg" isn't P-frames.
Number of frames encoded output is function "FramesToBeEncoded". There is actually no percentage of processed film.
Quote:
Originally Posted by FranceBB View Post
(I'm gonna upload the encoded file as soon as it finishes to encode).
It is a pity to damage the equipment.

I will only add that they are thinking about AVX2 & 360 suport. The codec doesn't currently work
https://vcgit.hhi.fraunhofer.de/jvet...e_requests/920

PS It is interesting for me why VVC codec is developed on HM-HEVC and not on Mainconcept, Leadtools, other HEVC.
There are currently a waste of time for novelties that are unlikely to come soon. Fast entry means throwing away all receivers HEVC.

https://www.ibc.org/create-and-produ...c/4252.article
Except that the implementation is not as easy as it may seem. All MPEG-based codecs (including AVC/H.264, HEVC/H.265 and VVC) make use of similarities between consecutive pictures. This means each encoding block needs to know about subsequent or previous images, as well as neighboring blocks. Any shortcut taken here will invariably lead to image quality degradation, and any over-engineering in the control mechanism will sacrifice the benefit of parallel processing. We aren't interested in this

Is Hybrid GPU Encoding the ultimate answer? As every use case is different, there is no single best answer. However, Hybrid GPU accelerated encoding delivers faster processing, allowing for more live channels per server, with less demand for CPU power when encoding. But, the performance of the encoder depends on a variety of factors such as the desired encoding profile, resolution, server system, GPU model, etc. In today’s world of ever-increasing quality and performance requirements, especially for live video, GPU Hybrid offers flexibility to get the most out of your investment.

Last edited by Jamaika; 15th September 2019 at 18:41.
Jamaika is offline   Reply With Quote
Old 16th September 2019, 06:03   #154  |  Link
FranceBB
Broadcast Encoder
 
FranceBB's Avatar
 
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,883
Quote:
Except that the implementation is not as easy as it may seem. All MPEG-based codecs (including AVC/H.264, HEVC/H.265 and VVC) make use of similarities between consecutive pictures. This means each encoding block needs to know about subsequent or previous images, as well as neighboring blocks. Any shortcut taken here will invariably lead to image quality degradation, and any over-engineering in the control mechanism will sacrifice the benefit of parallel processing. We aren't interested in this
Well of course parallelization means a reduction of quality and ideally we should stick with single thread, however the increasing computational power required to encode led us to where we are now: a very parallelized world.
I gotta say, though, that H.264 and H.265 are very well parallelized and that although a very little reduction of quality can be proven via objective metrics like SSIM/PSNR in extreme parallelization, such a thing is so small that it's almost unnoticeable and H.265 in particular developed many internal tools in a way that they're meant to be used by multi-core/threads CPUs in a very efficient way.

Quote:
Is Hybrid GPU Encoding the ultimate answer? As every use case is different, there is no single best answer. However, Hybrid GPU accelerated encoding delivers faster processing, allowing for more live channels per server, with less demand for CPU power when encoding. But, the performance of the encoder depends on a variety of factors such as the desired encoding profile, resolution, server system, GPU model, etc. In today’s world of ever-increasing quality and performance requirements, especially for live video, GPU Hybrid offers flexibility to get the most out of your investment.
Sure, GPU encoding is a thing, but GPU encoders have been proven to achieve less quality compared to CPU encoders in both x264 and x265 tests over the years.
Of course, things have improved ever since, but they still lack behind.
Anyway, the same parallelization concept applies: in the world we're living in, there's so much need to parallelize workflows that hybrid CPU/GPU encoding is almost always preferred, despite the loss of quality, which is not as negligible as it was for single-thread multi-thread CPU tests (heck, you can see with your eyes the difference between CPU encoders and GPU encoders).


On a totally unrelated thing...


Linear Algebra consideration:

I was taking a look at the official document about H.266 VVC.
I've stumbled across different transforms in my life, namely the DCT (Discrete Cosine Transform), DFT (Discrete Fourier Transform), WHT (Walsh-Hadamard Transform), DWT (Discrete Wavelet Transform) and of course the KLT (Karhunen-Loeve Transform).
The Discrete Cosine transform is widely used in many codecs and indeed it's my favorite transform 'cause it works with real numbers and it's continuous in 2 phi.
On the contrary, the Fourier Transform works with the imaginary numbers and it's continuous in phi, so not only it has more discontinuity points, but it also requires more computational power since it's using complex numbers.
As a matter of fact, in codecs like H.264 the DCT is used along with the Hadamard Transform which is very light and although it doesn't compress much, it's used in addition to the DCT in order to take care of what the DCT didn't properly take care of.
As to the Wavelet transform, it kinda became popular years ago when they were trying to take care of the blocking issues that were caused by quantizing 4x4 and 8x8 blocks with the Discrete Cosine Transform that was causing blocking artifacts that were not pleasant at not so high bitrates, therefore it was used in implementations like the JPEG2000 or AppleProres 'cause they were processing the whole image at the full resolution all at once, but I've never been a fan of this transform and as a matter of fact, although it has its own advantages and peculiarities, it's not as widespread as the DCT.
As to the Karhunen-Loeve transform, it became popular back in 2013 when we were all looking for alternatives when H.265 was still a work in progress and was on design-stage.
The Karnhunen-Loeve transform is probably the heaviest transform that I'm aware of and it requires a lot of computational power, however, during the tests, it was shown that although it was better than the Discrete Cosine Transform itself, it didn't actually achieve such a significant advantage over the Discrete Cosine Transform on a significant amount of contents, but it required way more computational power than the DCT and therefore the proposal at the time was rejected and the Discrete Cosine Tranform and the Discrete Sine Transform were used in H.265 instead.

Linear Algebra question:

If I got it right, H.266 VVC inherited the Discrete Cosine Transform and Discrete Sine Transform approach from H.265 HEVC which is fine, but it's also using an adaptive multiple transform (AMT) scheme for residual coding for both inter-coded and intra-coded blocks. This approach basically consists of a set of five DCT and DST based transform, namely DCT-II, DCT-V, DCT-VIII, DST-I, and DST-VII.
Fair enough, but how? I mean, I can't find an extensive documentation that fully explains how those are used.
Are they used subsequently? One after the other and in case in which order? Are they used with a sort of pre-filter which analyses the type of frame, divides it in blocks and macroblocks and decide which one it's gonna use or which set it's gonna use?

Last edited by FranceBB; 16th September 2019 at 06:10.
FranceBB is offline   Reply With Quote
Old 16th September 2019, 13:43   #155  |  Link
Jamaika
Registered User
 
Join Date: Jul 2015
Posts: 697
https://www.researchgate.net/publica...and_Complexity 10.2018
HEVC transform is based on a Discrete Cosine Transform (DCT-II), apart for Intra-coded 4x4 TUs for which a
Discrete Sine Transform (DST-VII) is used. In comparison, JEM relies on a variety of selectable core transforms from
the DCT and DST families (DCT-II, DCT-V, DCT-VII, DST-I and DST-VII). An Adaptive Multiple Transform (AMT)
method has been designed such that depending on the selected mode (intra or inter), or further on the intra prediction
direction, a sub-set of the core transforms is built and one transform from this sub-set is chosen based on RDO. In
the JEM, large block-size transforms, up to 128×128 in size, are enabled. High frequency transform coefficients are
zeroed out for the transform blocks with size larger than or equal to 64, so that only the lower-frequency coefficients
are maintained. In addition to AMT, a Mode-Dependent Non-Separable Secondary Transform (MDNSST) is applied
between the core transform and the quantization, with the motivation to reduce remaining dependencies after the
separable core transforms which only address horizontal and vertical signal dependencies. Finally a Signal
Dependent Transform (SDT) is competed to the AMT output. The SDT approximates the optimal Karhunen-Loéve
transform (KLT), which is a signal dependent transform, by estimating current signal to code (transform block) with
similar signals (i.e. reference patch) available at the decoder (already coded).
AV1 also supports multiple transforms: DCT, Asymmetric DST (ADST), flipped ADST, and Identity (IDTX). The
identity transform is equivalent to the transform skip mode of HEVC and JEM. The vertical and the horizontal
transforms can be selected independently from the set of four transforms, resulting in 16 transform combinations.


As to transform, the square transforms in HEVC are extended to non-square transforms for rectangular blocks resulted from binary and ternary tree splits. Besides, [VVC] supports multiple transform sets (MTS), including DCT-2, DST-7, and DCT-8 as well as the non-separable secondary transform. The transforms used in [VVC] can have different sizes with support for larger transform sizes. For DCT-2, the transform sizes range from 2x2 to 64x64, and for DST-7 and DCT-8, the transform sizes range from 4x4 to 32x32. In addition, [VVC] also support sub-block transform for both intra and inter coded blocks. For intra coded blocks, intra sub-partitioning (ISP) may be used to allow sub-block based intra prediction and transform. For inter blocks, sub-block transform may be used assuming that only a part of an inter-block has non-zero transform coefficients.

Increase max QP from 51 to 63. An enhanced rate distortion optimized quantization scheme called Dependent Scalar Quantization. CABAC coder from AVC, it has been enhanced and is now even faster.

Last edited by Jamaika; 16th September 2019 at 14:11.
Jamaika is offline   Reply With Quote
Old 16th September 2019, 15:24   #156  |  Link
FranceBB
Broadcast Encoder
 
FranceBB's Avatar
 
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,883
Quote:
An Adaptive Multiple Transform (AMT)
method has been designed such that depending on the selected mode (intra or inter)
Got it.

Quote:
In addition to AMT, a Mode-Dependent Non-Separable Secondary Transform (MDNSST) is applied
between the core transform and the quantization, with the motivation to reduce remaining dependencies after the
separable core transforms which only address horizontal and vertical signal dependencies.
Ok, it makes sense.

Quote:
Finally a Signal
Dependent Transform (SDT) is competed to the AMT output. The SDT approximates the optimal Karhunen-Loéve
transform (KLT), which is a signal dependent transform, by estimating current signal to code (transform block) with
similar signals (i.e. reference patch) available at the decoder (already coded).
Very interesting 'cause this way a lot of computational power is actually saved by not using the KLT directly which is far too demanding in terms of computational cost, but if this approximation gets similar results, I totally understand why they went for this path.

Quote:
AV1 also supports multiple transforms: DCT, Asymmetric DST (ADST), flipped ADST, and Identity (IDTX).
Oh, I see... I gotta say that I'm not very familiar with AV1 'cause it's not very widespread in broadcast and nobody ever sent us a master file in AV1, but it's good to know.

Quote:
The
identity transform is equivalent to the transform skip mode of HEVC and JEM.
Yeah, of course, it's just like when you multiply a matrix of linear transformation by the identity matrix (the matrix with all one on the main diagonal and zero everywhere else): you get back the matrix you started from. After all the identity it's there (in a space) for a reason: to get back the input as output

Quote:
The vertical and the horizontal
transforms can be selected independently from the set of four transforms, resulting in 16 transform combinations.
I see, that's good.

Quote:
the square transforms in HEVC are extended to non-square transforms for rectangular blocks resulted from binary and ternary tree splits.
I see! That's gonna increase the computational cost, but it's actually very good that they have been modified, so if they did it, it means that the result it's worth the cost.

Quote:
CABAC coder from AVC, it has been enhanced and is now even faster.
Oh, that's great.


Alright, thank you for clarifying my doubts. I'm an young engineer and I have always been interested in applied mathematic. VVC has a lot of potential indeed and some of those things are really reassuring me about VVC and the role that it's gonna play in the future.
Speaking of future, Tokyo 2020 Olympics are gonna be in 8K and we're talking about summer 2020. Do you think that the encoder will be at a much more developed state at that point and it's actually gonna be used to encode and distribute live feeds or do you think that it's still way too early and everything it's gonna be done in HEVC as rumours suggest?

Last edited by FranceBB; 16th September 2019 at 15:28.
FranceBB is offline   Reply With Quote
Old 17th September 2019, 10:13   #157  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
Quote:
Originally Posted by FranceBB View Post
Speaking of future, Tokyo 2020 Olympics are gonna be in 8K and we're talking about summer 2020. Do you think that the encoder will be at a much more developed state at that point and it's actually gonna be used to encode and distribute live feeds or do you think that it's still way too early and everything it's gonna be done in HEVC as rumours suggest?
I'm at the MC-IF meeting in Amsterdam at this very moment.

The current target completion date for the VVC spec is July 2020. There is no WAY it is going to be used in that summer's Olympics! HEVC transport is becoming common, particularly for 4K. We likely could see some VVC used for the 2024 summer Olympics. Even the 2022 Winter Olympics might be too soon for any mission critical applications.

We generally see new codecs used in IP services and VOD first. Breaking the Olympics for 10 minutes is about the highest-risk thing in the TV industry; people will start small.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 17th September 2019, 11:26   #158  |  Link
FranceBB
Broadcast Encoder
 
FranceBB's Avatar
 
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,883
I see, so probably 2024... Thank you for the info!
I really wanted to go to Amsterdam, but they didn't let me go to the IBC (I'm sitting in front of my desk in a studio right now 'cause I'm working).
The boss of my boss of my boss of my boss is there; as a matter of fact, I'm just a level 4 out of 10 in the company I work for, so it's normal. xD
FranceBB is offline   Reply With Quote
Old 17th September 2019, 19:54   #159  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,752
Komm, wir fahren nach Amsterdam...

I don't mind improving the future already today. I remember how I joined the doom9 forums in the middle of the DVD era. Working in an authoring studio. Who cares about DVD's anymore today?
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 18th September 2019, 00:32   #160  |  Link
soresu
Registered User
 
Join Date: May 2005
Location: Swansea, Wales, UK
Posts: 196
Quote:
Originally Posted by benwaggoner View Post

The current target completion date for the VVC spec is July 2020. There is no WAY it is going to be used in that summer's Olympics! HEVC transport is becoming common, particularly for 4K. We likely could see some VVC used for the 2024 summer Olympics. Even the 2022 Winter Olympics might be too soon for any mission critical applications.
I just saw an announcement from Beamr about 8K HEVC encoding at 79 fps, sounds like they have it in the bag - I wonder if they are using SVT at all?

Edit: Found a PDF release from AMD about it, seems their new 64 core EPYC chip managed it. Link here.

Last edited by soresu; 18th September 2019 at 00:36.
soresu 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 11:36.


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