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 30th April 2020, 08:43   #221  |  Link
hajj_3
Registered User
 
Join Date: Mar 2004
Posts: 958
I'm not sure why you would be using VVC for the olympics as there's no chance that consumers will have a tv or set-top box that can hardware decode VVC in time for the olympics. Or are you just referring to using it to transmit between different broadcast companies so that they can then encode the 8k in to h265 if they wanted? Most people aren't going to see the difference between 4k and 8k unless they are in a cinema.
hajj_3 is offline   Reply With Quote
Old 30th April 2020, 17:12   #222  |  Link
ksec
Registered User
 
Join Date: Mar 2020
Posts: 13
Quote:
Originally Posted by utack View Post
But that was a time when we had actual progress in phones that cost $400, not when the $900 phones big feature was removing the headphone jack
I don't think either codec will spread as quickly as the previous ones
Well it doesn't change the fact we are still shipping ˜1.3B Smartphone annually. Apple, Samsung, Qualcomm, and Huawei together would be 90% of the SoC Market. You could expect close to 80% of Smartphone to have a hardware decoder within 4 year if the Big four act together.

That is all of course, assuming they dont repeat the stupid mistake of HEVC patent pool. ( Still pointing my anger at Qualcomm )

And if anyone like me is keeping an eye on MC-IF, things are *not* looking good.

Last edited by ksec; 30th April 2020 at 17:16.
ksec is offline   Reply With Quote
Old 30th April 2020, 17:30   #223  |  Link
FranceBB
Broadcast Encoder
 
FranceBB's Avatar
 
Join Date: Nov 2013
Location: Germany
Posts: 905
Quote:
Originally Posted by hajj_3 View Post
I'm not sure why you would be using VVC for the olympics as there's no chance that consumers will have a tv or set-top box that can hardware decode VVC in time for the olympics. Or are you just referring to using it to transmit between different broadcast companies so that they can then encode the 8k in to h265 if they wanted? Most people aren't going to see the difference between 4k and 8k unless they are in a cinema.
We didn't want to, it was just a thought we had at the very beginning about how to air in 8K without compromising quality too much as it appeared clear that with H.265 it wasn't possible due to bandwidth and complexity limitations of real-time encoders...
I think we're still way behind with 8K productions and it's not gonna be a thing for quite some time...
So, in the end, it's not true that European broadcasters are not interested in VVC, Jamaika, it's just that it's way too early...
FranceBB is offline   Reply With Quote
Old 1st May 2020, 00:11   #224  |  Link
Blue_MiSfit
Derek Prestegard IRL
 
Blue_MiSfit's Avatar
 
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,695
How would you have even done real-time 8k HEVC? Is there an encoder that supports this? Or would you have to do bonded 4k encoders like how the NHK guys always do their crazy demos?
Blue_MiSfit is offline   Reply With Quote
Old 1st May 2020, 00:36   #225  |  Link
FranceBB
Broadcast Encoder
 
FranceBB's Avatar
 
Join Date: Nov 2013
Location: Germany
Posts: 905
Quote:
Originally Posted by Blue_MiSfit View Post
How would you have even done real-time 8k HEVC? Is there an encoder that supports this? Or would you have to do bonded 4k encoders like how the NHK guys always do their crazy demos?
8 SDI 4K streams that go to 4 4K HEVC encoders bonded together.
There's no 8K HEVC hardware encoder yet, but if you are aware of one, please let me know.

Last edited by FranceBB; 1st May 2020 at 17:18.
FranceBB is offline   Reply With Quote
Old 1st May 2020, 05:23   #226  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 3,241
Quote:
Originally Posted by hajj_3 View Post
I'm not sure why you would be using VVC for the olympics as there's no chance that consumers will have a tv or set-top box that can hardware decode VVC in time for the olympics. Or are you just referring to using it to transmit between different broadcast companies so that they can then encode the 8k in to h265 if they wanted? Most people aren't going to see the difference between 4k and 8k unless they are in a cinema.
Most cinemas are still 2K, and even if it's a 4K projector with 4K content, almost all the VFX are still going to be 2K and upsampled. Any detail beyond 720p vanishes quickly with motion with 1/48th sec of motion blur.

And yes, no one was going to do VVC for the 2020 Olympics. Maybe there will be some tests for the now 2021 Olympics, but nothing customer facing. That would be like doing AV1 for 4K premium DRM content in 2020; HW DRM is vanishingly rare, and if an AV1 encoder can be coerced into doing even 4K live, the MIPS/pixel would be so low that a 1080p HEVC would probably look better below 25 Mbps.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 1st May 2020, 05:25   #227  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 3,241
Quote:
Originally Posted by FranceBB View Post
8 SDI 4K streams that go to 8 4K HEVC encoders bonded together.
There's no 8K HEVC hardware encoder yet, but if you are aware of one, please let me know.
It's 4 bonded together; 2x2 grid. Which means that the edges of the encodes are exactly a cross in the center of the screen, where even slight variations are going to be pretty darn obvious. To the extent that 8K works, it's because the extra detail is largely invisible and so averages out problems .
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 1st May 2020, 05:41   #228  |  Link
foxyshadis
ангел смерти
 
foxyshadis's Avatar
 
Join Date: Nov 2004
Location: Lost
Posts: 9,495
Quote:
Originally Posted by benwaggoner View Post
And yes, no one was going to do VVC for the 2020 Olympics. Maybe there will be some tests for the now 2021 Olympics, but nothing customer facing.
The Olympics are awash in so much money that it's probably the ideal time to try every crazy thing you have on the backburner, though. They do usually get some mix of every mostly-impractical technology of the day to broadcast each time, along with the standard steams.

Not that, if it came together, VVC would be much more than a point-to-point broadcast between a custom camera and receiver, but such are the things PR Newswire is made of.
__________________
There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order.
foxyshadis is offline   Reply With Quote
Old 1st May 2020, 15:53   #229  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 3,241
Quote:
Originally Posted by FranceBB View Post
We didn't want to, it was just a thought we had at the very beginning about how to air in 8K without compromising quality too much as it appeared clear that with H.265 it wasn't possible due to bandwidth and complexity limitations of real-time encoders...
Any concern you have with real-time encoders for HEVC is going to be at least 10x worse for VVC for a couple of years. It's more complex and hasn't had time for thorough optimization and speed/quality tuning.

Quote:
I think we're still way behind with 8K productions and it's not gonna be a thing for quite some time...
So, in the end, it's not true that European broadcasters are not interested in VVC, Jamaika, it's just that it's way too early...
With Covid-19, I'm not aware of any actual 8K projects, live events or scripted, planned for 2020. While there were projects shooting in 8K, post production is all being done at 4K, often with many 2K elements. Now little is being shot with anything but webcams. And people working from home don't have access to 8K post workflows.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 1st May 2020, 21:41   #230  |  Link
birdie
.
 
birdie's Avatar
 
Join Date: Dec 2006
Posts: 157
Quote:
Originally Posted by FranceBB View Post
This is all to say: we're not ready, but I'd very much like to see H.266 begin to be implemented in real hardware encoders and TV decoders...
You're trying to solve a problem which doesn't yet exist and maybe won't exist ever. The number of 8K TV sets sold in the world to this date is less than a thousand I guess, maybe even less.

The more important issue is that the jump from FullHD to 4K was a huge one, outright perceivable as well, while 8K ... I don't want to say it's completely useless but you have to be sitting a foot away from a TV set to appreciate the picture quality and clarity. If you're in your usual sitting-room sitting six feet away or farther from your 60" TV set there will be zero difference between 4K and 8K streams.

8K has a place for medical personnel, civil engineers, CAD designers and for all the professions where utmost picture clarity is required but home entertainment is not one of them.
birdie is offline   Reply With Quote
Old 2nd May 2020, 01:49   #231  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 3,241
Quote:
Originally Posted by birdie View Post
You're trying to solve a problem which doesn't yet exist and maybe won't exist ever. The number of 8K TV sets sold in the world to this date is less than a thousand I guess, maybe even less.
It's a lot more than that. Analyst estimates are 2M will be sold in 2020.

Quote:
The more important issue is that the jump from FullHD to 4K was a huge one, outright perceivable as well, while 8K ... I don't want to say it's completely useless but you have to be sitting a foot away from a TV set to appreciate the picture quality and clarity. If you're in your usual sitting-room sitting six feet away or farther from your 60" TV set there will be zero difference between 4K and 8K streams.
One foot away for each 10" diagonal is about right to resolve full 4K detail with 20/20 vision. Closer than that is where you could start to see 8K. Closer than that is also where the viewing angle to the left and right edges of the screen become so distorted it's hard to see what's happening, and largely outside of your perephrial vision.

Quote:
8K has a place for medical personnel, civil engineers, CAD designers and for all the professions where utmost picture clarity is required but home entertainment is not one of them.
8K is great for when you can lean forward and move your head to "zoom in" to parts of the image. Computer monitors, gaming, collaborative screens, digital signage, etcetera. Just not leaning back and watching moving images without actively moving one's head or body.

Also, a pixel in a camera's Beyer pattern isn't the same as an encoded 4:2:0 pixel or 3-4 subpixels on a display. Having 12-16 subpixels per encoded pixel makes for better 8K than having just 3-4.

All that said, promises great improvements at every resolution. It's not tied to 8K.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 9th May 2020, 09:52   #232  |  Link
Jamaika
Registered User
 
Join Date: Jul 2015
Posts: 690
New updates VVC
Code:
#define JVET_Q0488_SEI_REPETITION_CONSTRAINT              1 // JVET-Q0488: SEI repetition constraint
#define JVET_Q0764_WRAP_AROUND_WITH_RPR                   1 // JVET-Q0764: Combination of wrap around offset and RPR
#define JVET_R0045_TS_MIN_QP_CLEANUP                      1 // JVET-R0045: Cleanup for signalling of minimum QP of transform skip
#define JVET_R0059_RPL_CLEANUP                            1 // JVET-R0059 aspect 2: Condition the signalling of ltrp_in_header_flag[ listIdx ][ rplsIdx ].
#define JVET_R0071_SPS_PPS_CELANUP                        1 // JVET-R0071 item 2-4: cleanups on subpicture signalling (item 1 has been ported in JVET_R0156_ASPECT4)
#define JVET_R0090_VUI                                    1 // JVET-R0090: Fix parsing dependencies in VUI syntax
#define JVET_R0091_CONSTRAINT_SLICE_ORDER                 1 // JVET-R0091: constraint slice signalling order to be the same as slice coding order
#define JVET_R0094_DPB_TID_OFFSET                         1 // JVET-R0094: DPB output temporal ID offsets
#define JVET_R0097_MAX_TRSIZE_CONDITIONALY_SIGNALING      1 // JVET-R0097: Aspect 1, If the luma CTB size is not larger than 32, sps_max_luma_transform_size_64_flag is not signalled and inferred to be 0
#define JVET_R0098_LMCS_AND_SCALING_LISTS_FOR_PH_IN_SH    1 // JVET-R0098: Only signall LMCS and explicit scaling list enable flags in SH when PH is not in SH
#define JVET_R0100                                        1 // JVET-R0100: Proposal 1 DUI Signalling and inference
#define JVET_R0107_VPS_SIGNALING                          1 // JVET-R017: Proposal 2 VPS signaling change and updated inference rule
#define JVET_R0108_DCI_SIGNALING                          1 // JVET-R0108 Proposal 1 DCI signaling changes
#define JVET_R0103_DU_SIGNALLING                          1 // JVET-R0103: Proposal 1 decoding unit signalling change
#define JVET_R0110_MIXED_LOSSLESS                         1 // JVET-R0110: Slice level mixed lossy/lossless coding: encoder only method
#define JVET_R0113_AND_JVET_R0106_PPS_CLEANUP             1 // JVET-R0113 and JVET-R0106: Cleanup in Picture Parameter Set
#define JVET_R0114_NEGATIVE_SCALING_WINDOW_OFFSETS        1 // JVET-R0114: Allow negative scaling window offsets
#define JVET_R0130_TC_DERIVATION_BUGFIX                   1 // JVET-R0130: Cleanup of tC derivation for deblocking filter
#define JVET_R0143_TSRCdisableLL                          1 // JVET-R0143: disable TSRC for lossless coding
#define JVET_R0156_ASPECT3_SPS_CLEANUP                    1 // Condition sps_sublayer_dpb_params_flag on sps_ptl_dpb_hrd_params_present_flag, in addition to sps_max_sublayer_minus1,	JVET-R0156 proposal 3, JVET-R0170, JVET-R0222 proposal 2
#define JVET_R0156_ASPECT4_SPS_CLEANUP                    1 // JVET-R0071 #1, R0156 #4, R0284 #1: Condition sps_independent_subpics_flag on "sps_num_subpics_minus1 > 0"
#define JVET_R0161_CONDITION_SIGNAL_PTL_IDX               1 // JVET_R0161 proposal 2: skip PTL index signaling when number of signaled PTL structure is equal to number of OLSs
#define JVET_R0165_OPTIONAL_ENTRY_POINT                   1 // JVET-R0165: Optional entry point offset
#define JVET_R0166_SCALING_LISTS_CHROMA_444               1 // JVET-R0166: Scaling list for Chroma 444
#define JVET_R0185_OLS_DPB_CLEANUP                        1 // JVET-R0185: Replace if( !vps_all_independent_layers_flag ) condition on vps_num_dpb_params syntax element with if(!each_layer_is_an_ols_flag)
                                                            //             Change vps_num_dpb_params to vps_num_dpb_params_minus1 and change the semantics to a two-way constraint
                                                            //             Signal DPB parameters for OLS in this case only if(!each_layer_is_an_ols_flag)
#define JVET_R0186_CLEANUP                                1 // JVET-R0186 aspect 1: Signal the pps_no_pic_partition_flag ahead in the PPS.
#define JVET_R0188                                        1 // JVET-R0188: Signalling slice_width_in_tiles_minus1[i] and slice_height_in_tiles_minus1[i]
#define JVET_R0191_ASPECT3                                1 // JVET-R0191#3: Modify the upper range of vps_num_dpb_params and num_ols_hrd_params_minus1 to be total number of OLSs minus the number of single-layer OLSs
                                                            //               Constrain that each PTL, DPB, and HRD params in VPS are referred to at least once
#define JVET_R0200_MOVE_LMCS_AND_SCALING_LIST_SE          1 // JVET-R0200 Move the SH flags slice_lmcs_enabled_flag and slice_explicit_scaling_list_used_flag to be just after the ALF parameters
#define JVET_R0201_PREFIX_SUFFIX_APS_CLEANUP              1 // JVET-R0201 Cleanups on Prefix and Suffix APS
#define JVET_R0202_WHEN_PH_IN_SH_INFO_FLAGS_EQUAL_0       1 // JVET-R0202 When sh_picture_header_in_slice_header_flag is equal to 1, rpl_info_in_ph_flag, dbf_info_in_ph_flag, sao_info_in_ph_flag, wp_info_in_ph_flag, qp_delta_info_in_ph_flag shall be be equal to 0
#define JVET_R0202_WHEN_PH_IN_SH_NO_SUBPIC_SEPARATE_COLOR 1 // JVET-R0202 Add constraints when sh_picture_header_in_slice_header_flag equal to 1 sps_subpic_info_present_flag and separate_colour_plane_flag shall be equal to 0
#define JVET_R0203_IRAP_LEADING_CONSTRAINT                1 // JVET-R0203: Constraint that IRAP NAL unit type cannot be mixed with RASL_NUT / RADL_NUT
#define JVET_R0205                                        1 // JVET-R0205: Condition presence of inter_layer_ref_pics_present_flag on sps_video_parameter_set_id
#define JVET_R0208_ALF_VB_ROUNDING_FIX                    1 // JVET-R0208: Rounding offset fix for ALF virtual boundary processing
#define JVET_R0210_NUMTILESINSLICE_SIGNALLING             1 // JVET-R0210 section 3.3: Don't signal NumTilesInSlice syntax element when numTilesInPic - slice_address is 1.
#define JVET_R0225_SEPERATE_FLAGS_ALF_CHROMA              1 // Use two separate flags (one for Cb, one for Cr) to replace ph_alf_chroma_idc in PH and sh_alf_chroma_idc in SH
#define JVET_R0232_CCALF_APS_CONSTRAINT                   1 // JVET-R0232 section 3.2: APS contraint for CCALF
#define JVET_R0233_CCALF_LINE_BUFFER_REDUCTION            1 // JVET-R0233 method 2: Line buffer reduction for CCALF
#define JVET_R0247_PPS_LP_FTR_ACROSS_SLICES_FLAG_CLEANUP  1 // JVET-R0247: Skip pps_loop_filter_across_slices_enabled_flag when the picture contains one slice
#define JVET_R0266_DESC                                   1 // JVET-R0266: change the signalling of the PPS ID from ue(v) to u(6); Code virtual boundary positions using ue(v)
#define JVET_R0267_IDR_RPL                                1 // JVET-R0267: Add RPL constraint for IDR picture
#define JVET_R0271_SLICE_LEVEL_DQ_SDH_RRC                 1 // JVET-R0271/R0155: Slice level DQ and SDH granularity for mixed lossy/lossless.
#define JVET_R0275_SPS_PTL_DBP_HRD                        1 // JVET-R0275: Modified constraint for sps_ptl_dpb_hrd_params_present_flag
#define JVET_R0276_REORDERED_SUBPICS                      1 // JVET-R0276: reference picture constraint for reordered sub-pictures
#define JVET_R0277_RPL                                    1 // JVET-R0277: Modified condition for sh_num_ref_idx_active_override_flag, inference for sh_collocated_from_l0_flag equal to 1 for P-slices
#define JVET_R0278_CONSTRAINT                             1 // JVET-R0278: ph_inter_slice_allowed_flag constraint
#define JVET_R0324_PH_SYNTAX_CONDITION_MODIFY             1 // JVET-R0324 add conditions on PH syntax to conder whether current pic is bi-predictive picture
#define JVET_R0327_ONE_PASS_CCALF                         1 // JVET-R0327: One-pass CCALF
#define JVET_R0330_CRS_CLIP_REM                           1 // JVET-R0330: Remove redundant clipping in chroma residual scaling factor derivation
#define JVET_R0332_HLS_ORDER                              1 // JVET-R0332: Grouping syntax elements in SPS based on slice type
#define JVET_R0334_PLT_CLEANUP                            1 // JVET-R0334: Disable chroma palette for local dual tree
#define JVET_R0347_MTT_SIZE_CONSTRAIN                     1 // JVET-R0347: Set upper limit of minQtSize and maxTtSize to 64, set upper limit of maxBtSize to 64 in chroma-tree
#define JVET_R0350_MIP_CHROMA_444_SINGLETREE              1 // JVET-R0350: MIP for chroma in case of 4:4:4 format and single tree
#define JVET_R0371_MAX_NUM_SUB_BLK_MRG_CAND               1 // JVET-R0371: set the range of max number of subblock based merge candidate to 0 to 5 - sps_sbtmvp_enabled_flag.
#define JVET_R0380_SCALING_MATRIX_DISABLE_YCC_OR_RGB      1 // JVET-R0380 solution3-3: Disable scaling matrix for blocks coded in alternative colour space.
#define JVET_R0388_DBF_CLEANUP                            1 // JVET-R0388: Cleanups on deblocking signalling
#define JVET_R0413_HRD_TIMING_INFORMATION                 1 // JVET-R0413: HRD timing parameters signalling
#define JVET_R0437_BS_DERIVATION                          1 // JVET-R0437: fix the bS derivation for palette mode
#define JVET_R0483_SH_TSRC_DISABLED_FLAG_CLEANUP          1 // JVET-R0483 Comb 4: R0049 + R0271, only R0049 method 3 aspect (Skip signaling sh_ts_residual_coding_disabled_flag when sps_transform_skip_enabled_flag = 0, also proposed in R0068, R0097, R0142, R0153) as R0271 has its own macro
#define JVET_R0164_MEAN_SCALED_SATD                       1 // JVET-R0164: Use a mean scaled version of SATD in encoder decisions
https://github.com/Jamaika1/libbpg_jvetvvc
test codec VVC with gcc 11.0 C++11
https://www.sendspace.com/file/vqahm6
Jamaika is offline   Reply With Quote
Old 14th May 2020, 09:11   #233  |  Link
ksec
Registered User
 
Join Date: Mar 2020
Posts: 13
https://thebroadcastknowledge.com/20...ing-vvc/#video

An article, and video on the current state of VVC. And it really is promising in terms of Complexity to Performance Ratio.

VVC, Finger crossed.
ksec is offline   Reply With Quote
Old 27th May 2020, 08:39   #234  |  Link
ksec
Registered User
 
Join Date: Mar 2020
Posts: 13
VTM 9.0 is out.

https://vcgit.hhi.fraunhofer.de/jvet...VTM/-/releases
ksec is offline   Reply With Quote
Old 27th May 2020, 11:44   #235  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,114
Will it compile in GCC 10.1? ... To be tested.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 28th May 2020, 11:20   #236  |  Link
Jamaika
Registered User
 
Join Date: Jul 2015
Posts: 690
test codec VVC 9.0 280512020 with gcc 11.0 C++11
https://www.sendspace.com/file/om1sw8
Jamaika is offline   Reply With Quote
Old 29th May 2020, 23:43   #237  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 3,241
Quote:
Originally Posted by Jamaika View Post
test codec VVC 9.0 280512020 with gcc 11.0 C++11
https://www.sendspace.com/file/om1sw8
Wow, I see 1431 command line parameters! That's got to be a record...
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 30th May 2020, 09:05   #238  |  Link
Jamaika
Registered User
 
Join Date: Jul 2015
Posts: 690
Quote:
Originally Posted by LigH View Post
Will it compile in GCC 10.1? ... To be tested.
GCC win32 doesn't distinguish between definitions. For defines X equal zero this result is '#if defined (X)' one. Troublesome for WIN64 and _WIN64.
For GCC win32 is 'Memory allocation failed: std::bad_alloc'. For GCC win64 is correct.
For GCC win32 is:
Code:
c:\msys1000\lib\gcc\i686-w64-mingw32\10.1.0\include\xmmintrin.h:892:1: error: inlining failed in call to 'always_inline' '__m128 _mm_set1_ps(float)': target specific option mismatch
  892 | _mm_set1_ps (float __F)
      | ^~~~~~~~~~~
ResizeBiCubic.cpp:150:29: note: called from here
  150 |     __m128 rb3 = _mm_set1_ps(beta[3]);
      |                  ~~~~~~~~~~~^~~~~~~~~
For GCC win64 is correct.
Why am I using gcc win64? Because I can test the codec.
Quote:
Originally Posted by benwaggoner View Post
Wow, I see 1431 command line parameters! That's got to be a record...
I don't know what the problem is.

Last edited by Jamaika; 30th May 2020 at 09:34.
Jamaika is offline   Reply With Quote
Old 1st June 2020, 00:30   #239  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 3,241
Quote:
Originally Posted by Jamaika View Post
I don't know what the problem is.
No problem per se, but rather remarkable!

It'll take a while to figure out optimal presets and tunings given all those options. But that's true of every new codec generation.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 4th June 2020, 13:38   #240  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,114
There will not be any more recent VVC build made with MABS, because the JVET team does not spend any time to make it support GNU C++ 10, especially not in MSYS2/MinGW. Any idea to solve the recent compiling issue will be appreciated.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH 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:13.


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