Custom Query (1440 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (31 - 33 of 1440)

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
Ticket Resolution Summary Owner Reporter
#1451 fixed not clear spelling kolya
Description

In the spec, there is:

pcm_enabled_flag equal to 0 specifies that PCM data are not present in the CVS. NOTE 4 – When MinCbLog2SizeY is equal to 6, PCM data are not present in the CVS even when pcm_enabled_flag is equal to 1. The maximum size of coding block with pcm_enabled_flag equal to 1 is restricted to be less than or equal to Min( CtbLog2SizeY, 5 ). Encoders are encouraged to use an appropriate combination of log2_min_luma_coding_block_size_minus3, log2_min_pcm_luma_coding_block_size_minus3, and log2_diff_max_min_pcm_luma_coding_block_size values when sending PCM data in the CVS.

It is not clear what PCM data are assumed not to be in the stream: only PCM samples, or related syntax like pcm_sample_bit_depth_luma_minus1 etc.

#1450 fixed HM encoder memory reduction karlsharman
Description

The HM Encoder takes excessive memory, especially when considering increasing picture sizes and GOP structures.

For example, when encoding Traffic (2560x1600), with the 16-frame GOP structure used by JVET, memory requirements are 2482 MiB.

For 4K sequences, memory requirements are approximately 2.1 times higher; i.e. ~ 5361 MiB.

For derived branches, such as JEM, memory utilization is even higher.

The reason is because all memory is allocated for all the processing at the outset. This means that for a 16 frame GOP simulation, up to 32 TComPic objects will be present, all of which have memory allocated for encoding decisions.

15 of the frames will only actually contain source image data

  • these are frames that have been buffered up prior to the complete GOP encoding.

1 of the frames will be being processed, and will therefore need

source data and encoding decision data.

Up to 16 frames will be kept as part of the reference picture

list structure. These technically only require the reconstructed picture data and other information present in the DPB.

The attached patch reduced the memory usage by ~60% for the above example, reducing Traffic, GOP-16 from 2482 MiB to just 1020 MiB.

It achieves this by allocating memory only when it is needed. It also introduces a DPB structure into which side information is placed for reference frame usage.

Note that there is not such a significant problem in the decoder, as it only allocates data for pictures when they are decoded, and destroys the data afterwards (as it also has to cope with video format changes).

The patch does not affect run-time or coding efficiency.

I have uploaded it as a ticket so that other branches may examine and comment.

#1449 fixed Incorrect offset derivation in Eq 8-10x from chroma format for CPR cgisquet
Description

Current formulas in 8.5.3.2.1 are: offsetX = ( ChromaArrayType == 0 ) ? 0 : ( mvCLX[ 0 ] & 0x7 ? 2 : 0 ) (8-106) offsetY = ( ChromaArrayType == 0 ) ? 0 : ( mvCLX[ 1 ] & 0x7 ? 2 : 0 ) (8-107) They seem to enforce using an offset even for 4:4:4 with odd mvCLX coordinates.

These formulae should probably read something like: offsetX = ( ChromaArrayType != 1 && ChromaArrayType != 2 ) ? 0 : ( mvCLX[ 0 ] & 0x7 ? 2 : 0 ) (8-106) offsetY = ( ChromaArrayType != 1 ) ? 0 : ( mvCLX[ 1 ] & 0x7 ? 2 : 0 ) (8-107) to properly account for 4:2:0 and 4:2:2.

Note: there does not seem to be an appropriate version for the SCC text.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
Note: See TracQuery for help on using queries.