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. |
1st May 2018, 15:05 | #41 | Link | |
VP Eng, Kaleidescape
Join Date: Jan 2018
Location: Mt View, CA
Posts: 51
|
Quote:
|
|
6th May 2018, 20:17 | #43 | Link | |
Registered User
Join Date: Apr 2002
Posts: 756
|
Quote:
Now that we have reached a plateau, these questions becomes much more important. |
|
16th May 2018, 10:01 | #44 | Link |
Registered User
Join Date: Apr 2002
Posts: 756
|
http://blog.chiariglione.org/the-mpe...o-start-again/
Sounds like VVC is coming along nicely. I wish they could aim a little higher then the 50% improvement though. There is another pieces about the problem of IP. http://blog.chiariglione.org/ip-coun...enue-counting/ |
22nd May 2018, 19:50 | #45 | Link | |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,771
|
Quote:
The real metric is efficiency @ perf. If a new codec is able to deliver better quality in the same encoding time, that's a win. And as Moore's Law marches on, the number of MIPS/pixel we are willing to spend keeps going up up up. x265 beats x264 for most scenarios with the same encoding time, AND it can provide much more efficient encoding for the patient. Any new codec has to show that it can provide significant efficient gains in reasonable encoding time. And quality @ perf gets way better in the initial years after a new bitstream is defined as performance and psychovisual tuning gets done. Increases in decoder complexity are a bigger barrier, since that goes to the cost of all those decoders in all those devices. If something takes 4x the silicon and milliwatts to decode versus an existing standard, it would have to be REALLY more efficient. MPEG-2 -> H.264 -> HEVC were about 2x more complex per pixel, for about 2x better efficiency. Generally more complexity or lower efficiency gains don't really move the market (see MPEG-4 part 2, Theora, VP6-9) |
|
22nd May 2018, 20:34 | #46 | Link | |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,771
|
Quote:
Does anyone have any sense of the increased HW decoder complexity of AV1 versus HEVC, and how much is additive (versus the same decoder using the same functional blocks for multiple codecs)? I worry that the current AV1 encoder is so slow that there really isn't a big enough corpus of encoded content to figure out what quality/efficiency delta could be anticipated in the real world in a given time frame. The cost to add AV1 decode depends on the delta in silicon area and milliwatts. I've not heard any estimates for that delta yet. Anyone else? Obviously the cheaper the cost to add decode, and the bigger the relative value, are both going to be big factors in adoption. |
|
26th May 2018, 07:11 | #47 | Link | |
Angel of Night
Join Date: Nov 2004
Location: Tangled in the silks
Posts: 9,559
|
Quote:
A quadratic increase in complexity for a linear increase in efficiency sucks, but that's what we have the remnants of Moore's law for. |
|
3rd September 2018, 23:18 | #49 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,784
|
I am not able to build the "VTM Repository" (trunk) in MSYS2 / MinGW: If you try to create the Makefile with the CMake generator "MinGW Makefiles", it complains that sh.exe must not be in the path; if you try the generator "MSYS Makefiles", BBuildEnv.cmake warns that it is not fully supported, and make fails with:
Code:
jvet-svn/source/Lib/CommonLib/x86/CommonDefX86.h:158:71: error: SSE vector return without SSE enabled changes the ABI [-Werror=psabi] |
4th September 2018, 04:16 | #50 | Link | |
Derek Prestegard IRL
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,989
|
Quote:
|
|
4th September 2018, 23:58 | #51 | Link |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,771
|
I’m sure it’ll come. But I’m not really expecting to have a good sense of how AV1 and HEVC would compare for real-world scenarios before Q4 2019. HEVC is going to be better at quality @ perf for any real-world perf scenario for a long time. Getting all the inter and intra frame parallelization working is quite a project, and all the tuned vectorization (AVX2 & AVX512 these days).
This article on threading in x265 is an eye-opening read about the challenges of just parallelizing a modern codec. https://x265.readthedocs.io/en/default/threading.html And just look at the sheer amount of ASM code in it https://bitbucket.org/multicoreware/...579?at=default. Given the greater complexity of AV1, it would take a greater equivalent effort to provide the same degree of optimization as x265 has after 5+ years of serious development. |
7th September 2018, 11:01 | #52 | Link | |
Registered User
Join Date: Apr 2002
Posts: 756
|
Quote:
How about a codec that targets to similar or better quality than 1Mbps 720P HEVC @ 500Kbps, 2Mbps 1080P HEVC @ 1Mbps, 8Mbps 4K HEVC @ 4Mbps. And as to patents fees, why cant they keep it simple? All software implementation should be free. $0.5 for hardware decoder and $1 hardware encoder, $1.25 for both and charged per unit. No Caps, there more you sell the more you pay. License includes all the previous HEVC and AVC patents. That is combined to be $3B+ yearly revenue. On a twenty years target they are getting back ~$60B for their investment. Edit: The software implementation being free meant we could have a image format implementation that is available free for the web. We need something to replace jpeg. Last edited by iwod; 7th September 2018 at 14:00. |
|
9th September 2018, 19:49 | #53 | Link | |
Angel of Night
Join Date: Nov 2004
Location: Tangled in the silks
Posts: 9,559
|
Quote:
I've been experimenting with long-term references, which are a promising avenue for video that flips from one viewpoint to another and then back (incredibly common), which can give significant savings in some scenes, but making this work within the profiles available is almost impossible. I have no idea why set-tops are limited to a handful of megabytes in 2018. |
|
27th October 2018, 19:57 | #55 | Link | |
Registered User
Join Date: Jan 2007
Posts: 729
|
Quote:
The slides should be here: http://mile-high.video/files/mhv2018/ |
|
28th October 2018, 01:40 | #56 | Link |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,771
|
There was also some great data about VVC at the SMPTE Tech meetings in LA this week. Efficiency gains for objective metrics on HEVC HM are getting close to 30%, and the encoder is only about 1/5th slower. Subjective testing shows bigger gains than objective metrics predict. Theory is that the motion interpolation is a better match for the human visual system, so high QP motion artifacts aren’t nearly as objectionable. It’s always districting when things happen on a grid structure; our eyes are REALLY good at horizontal and vertical detail, and regular distributions.
Same track also showed that HEVC beats AV1 on subjective tests even The goal of the same subjective quality as HEVC at half the bitrate looks within reach, given the bitstream has still more than a year to percolate. It might be more than 50% for UHD and higher resolutions. (Although I still don’t think 8K video is going to really be a thing). |
28th October 2018, 16:34 | #58 | Link |
Registered User
Join Date: Apr 2002
Posts: 756
|
http://www.streamingmedia.com/Articl...P9-128213.aspx
The good news which I don't think had any media attention was the formation of Media Coding Industry Forum (MC-IF) for VVC. And from the start HEVC Advance and most of the Velos Media Companies are already included ( Missing Qualcomm ) as well as those who were previously not included in All three of the HEVC Pool such as technicolour and Nokia. Lets hope they have learned their lesson with HEVC. |
29th October 2018, 08:32 | #59 | Link |
I am maddo saientisto!
Join Date: Aug 2018
Posts: 95
|
MSYS2/GCC 8.2 64bits only:
VVCSoftware_VTM-2.2-51ce2f5b: https://mega.nz/#!s5Q1GYAA!cUHFazHOo...QvDfsLdl3Uhxf8 Unfortunately the parallel mode related code hasn't been updated after the introduction of JVET-L0266-HMVP, which means the function call at line 935 in EncCu.cpp fails to compile when enabling WPP and multithreading. So, single thread for now. Last edited by SmilingWolf; 29th October 2018 at 08:34. |
29th October 2018, 18:51 | #60 | Link |
Registered User
Join Date: Mar 2002
Posts: 863
|
Nice, thanks for the new build. The quality/efficiency seems to have improved slightly compared to the last build i have from april. Definitely better than AV1, the lower the bitrate, the bigger the difference is. It is slower than aomenc with its slowest preset though.
Definitely looks very promising quality-wise, i just hope the licensing shenanigans won't be repeated again. |
|
|