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. |
28th August 2019, 21:50 | #141 | Link | |
Registered User
Join Date: Apr 2002
Posts: 756
|
Quote:
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. |
|
31st August 2019, 07:52 | #142 | Link |
Registered User
Join Date: Jul 2015
Posts: 708
|
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. |
3rd September 2019, 19:31 | #143 | Link | |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,771
|
Quote:
|
|
3rd September 2019, 19:33 | #144 | Link | |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,771
|
Quote:
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. |
|
4th September 2019, 05:02 | #145 | Link | |
Registered User
Join Date: Jul 2015
Posts: 708
|
Quote:
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. For me the big surprise is the AV1 MPEG-4. |
|
9th September 2019, 06:15 | #146 | Link |
Registered User
Join Date: Jul 2015
Posts: 708
|
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. |
9th September 2019, 08:05 | #147 | Link | |
Registered User
Join Date: Apr 2002
Posts: 756
|
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. |
|
10th September 2019, 17:23 | #148 | Link | |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,771
|
That is possible on some LTE networks already. It is pretty trivial for WiFi.
Quote:
|
|
10th September 2019, 17:29 | #149 | Link | ||
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,771
|
Quote:
Quote:
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. |
||
11th September 2019, 05:33 | #150 | Link | |
Registered User
Join Date: Jul 2015
Posts: 708
|
Quote:
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. |
|
14th September 2019, 09:56 | #151 | Link |
Registered User
Join Date: Jul 2015
Posts: 708
|
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 |
15th September 2019, 06:58 | #152 | Link | ||
Broadcast Encoder
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,905
|
Quote:
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 Quote:
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. |
||
15th September 2019, 18:03 | #153 | Link | |||
Registered User
Join Date: Jul 2015
Posts: 708
|
Quote:
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:
Number of frames encoded output is function "FramesToBeEncoded". There is actually no percentage of processed film. Quote:
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. |
|||
16th September 2019, 06:03 | #154 | Link | ||
Broadcast Encoder
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,905
|
Quote:
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:
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. |
||
16th September 2019, 13:43 | #155 | Link |
Registered User
Join Date: Jul 2015
Posts: 708
|
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. |
16th September 2019, 15:24 | #156 | Link | ||||||||
Broadcast Encoder
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,905
|
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
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. |
||||||||
17th September 2019, 10:13 | #157 | Link | |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,771
|
Quote:
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. |
|
17th September 2019, 11:26 | #158 | Link |
Broadcast Encoder
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,905
|
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 |
17th September 2019, 19:54 | #159 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,784
|
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? |
18th September 2019, 00:32 | #160 | Link | |
Registered User
Join Date: May 2005
Location: Swansea, Wales, UK
Posts: 196
|
Quote:
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. |
|
|
|