C66x H.264HP encoder - Noise clips generate big GOP size

The input is 8-bit uyvy generated by setting each byte as

void SetToNoise(char* buf, int size)
{
  for(int i = 0; i < size; ++i)
  {
    buf[i] = rand() & 0xff;
  }
}

The uyvy format is then converted to 420 planar to feed your encoder. I attached the following 3 files:

CODEC_FMT(UYVY8_640x360p, H264_640x368p30) is the format used for generating the attached stream.

Dongning

4478.h264hpvenc_ti_config.cpp

4857.H264Encoder.cpp

7024.640x360_30fps_2500k0bps_1_0_v01_00_02_00.zip

Hi Paula, Dongning

As there are no correlation between frames, most of the MBs are coded as intra in B frames also.
So the increase in filesize is expected. We could not see much increase in size with normal configs(with same noise input).

It may be possible to control this through removing high frequency coefficients but currently it is not supported through config file. Code/Algorithm change might be required.

Thanks and regards

Sudheesh

Hi Dongning,

In general high frequency suppression is used to improve quality, not in this kind of use case.

It is possible to reduce bitrate for these noise sequences by suppressing high frequency components, but this will affect normal content badly as we are planning to get ~9x bit saving by suppressing coefficients..

Regards 

Rama

Hi Rama,

thank you for your reply.

If a GOP size is considerable larger than the targeted average size for a CBR bit stream, then RC should do take some measure to control the GOP size. Ideally RC should first rasie QP. If this is not enough, then discard high frequency transform coefficients. However, we cannot allow QP to use maximum allowed by the specs, i.e., 51, since if we do not restrict QP range in the configurations, the QP used by RC does not seem to produce as a good quality compression as when it is restricted. This is at least the case for version 1.0.0.4. This has been discussed and desmontrated in our earlier discussion of last year. That is why we cannot let QP to go all the way up to the maximum 51.

If GOP sizes are consistently too large, say twice the targeted average size, and maximum allowed QP in the configure has been used, then RC should discard high frequency transform coefficients for CBR bit stream. Otherwise, the RC fails to fulfil the CBR requirement. It is hard to accept that the bitstream is CBR when a GOP size has been constantly 10x as large as a targeted average GOP size. I cannot understand how it can make normal content worse if the RC works for normal content since discarding only kicks in when QP has reached the maximum allowed and the rate is still too high.

Regards,

Dongning

In case that it is not made clear in my previous posting, discarding high-frequency transform coefficients can kick in as soon as the RC detects the number of bits encoded is abnorammly large instead of doing this after a GOP encoding is compeleted.

Regards,

Dongning

Hi Dongning,

I understand the requirement now. This kind of specific feature/mechanism is not present in current H264 HP encoder. We need to implement the same. 

Regards

Rama

HI Dongning,

We are planning to start this feature in mid of September and expecting it to take 6 to 7 weeks to complete this feature.

You may expect an update in October 3rd week.

Regards

Rama

Hi Dongning,

Please see attached H.264 lib and configuration file which includes "High frequency suppression" feature. Please note that  rcAlgo= 3 selects CBR without frameskips and without scene change detection.

Also note that QPmax values were changed. When you have a chance please give a try to them on your system and let us know how new lib+new config files behaves for your system content and noise clips. 

6253.h264hpvenc_ti.le663122.codecParams_Quantel.cfg

Thank you,

Paula

Hi Paula,

Thank you for the update. This update has some improvement over the version we received earlier. However, the GOP size is still far too big than that of the targeted CBR. For our 640x360, 30fps @ 2.5 Mbps, the target GOP size of 15 frames should be 15625 bytes. However, we get the first GOP size of 1392640 byes when using the rate control parameter of your configuration, which is nearly 9 times as the targeted GOP size.

By the way, the codec should be designed to discard high frequency coefficient if required, to achieve close to the targeted bit rate (and GOP size) REGARDLESS what rate control QPs are used. Otherwise, i.e., if we have to use your min/max QPs, these QPs may not generate encoded video of acceptable quality for non-noise video.

Please let me know if your test result is the same as or similar to ours.

Regards,

Dongning

Hi Dongning,

We have observed around only 5x increase in size for noise sequences when considered around 300 frames.
Frequency suppression is triggered mostly for noise sequences when Qp hits it max configured value.
Initial 3 to 4 frames have more bits as we look for characteristics for few frames to avoid triggering freqeuncey suppression for scene changes in normal sequences when CBR is used.

We have also tuned relative bitsconsumption of I,P B frames wrt your requirement of CBR without frameskips and without change in GOP, so setting QpmaxI to 24 for CBR may not be really required.

Thanks and regards

sudheesh

Hi Sudheesh,

Our product has a fixed allocation which can pack up to 3 GOPs at the targeted bit rate with a little bit overhead room. Any GOP size more than 3 times of the targeted GOP size will likely fail to be packed into the allocation. Could you please just discard more high frequency cofficients and to make your rate control respond quick to avoid generating too high bit rate than the targeted? 5x of the targeted bits over 300 frames frames is too high, and is not acceptable as it is generating CBR. If it is CBR, then it should generate bit rate close to the targeted over 300 frames instead of 5 times of it. If you thinking your implementation of this required feature may other users, then make it configurable, i.e., add a configurable parameter to let user decide the maximum number of coefficients discardble within each block.

I look forward to your fix.

Regards,

Dongning

Hi Dongning,

We will try with configurable parameter to have much more compression for higher frequency components.

Regards

Sudheesh

Hi Dongning,

Please see attached H.264HP encoder RTSC package, configuration files and some test clips. For testing I used a bigger QP range, I think results are good. When you have a moment please check this new lib which contains High suppression coefficients feature as an input param. Also if you have some bandwidth please check increasing QP range on your system. RC has been tuned so please give it a chance and let us know your comments.

7103.HighFreqCoeffSuppression_Release_clips.zip

6403.C66x_h264hpvenc_01_00_03_00_ELF.tar

Thank you,

Paula

4024.2015-02-16_upload.zipDear Paula,

Thank you for the update.

We evaluated the library and noticed some improvement, but it still generates too many bits to fit into our allocation. Examining the encoded streams of noise, I find that QP does not change for a given macroblock row for the first IDR, and the number of bits generated for the first row alone is about the number of the average bits per frame at the target bit rate. Furthermore, as the number of bits are considerably larger than the targeted average as you encoded more macroblock rows, the QP used for the last 3 rows are reduced, which will generate more bits. I would think that the encoder should keep using the same QP of the previous MB row if not larger to generate less bits. It is not clear why the rate control design behaves like this.

When two cores work in a team to encode one bit stream, both slices suffer the same issues described above. This just makes the matter even worse.

From our test, it seems that the option 1 and 3 for suppressHighFreqCoeffs generate the same bit rate for noise.

To further improve your encoder for handling noise, I have the following thoughts/recommendations which might be useful:

1. If time allows, do a picture or even MB complexity analysis to have an idea what average Q for the frame and delta Q to add for an MB. If this consumes too much time, maybe sample some MBs to get an idea what Q to use.
2. Check the number of bits encoded for the current MB, and the total of the current frame as well as total so far of the current GOP against the targeted. Take action to control the bit rate rather than leave it at the end of the MB row when it might be too late.
3. The noise frame may not be the first frame in a GOP, so make sure that the rate control can also handle this case.

Herewith I attached some streams encoded by your this update and the configuration files used for encoding them.

Regards,

Dongning

Hi Dongning,

Initial frames will be kept out of filtering as it looks for noise behaviour over some consecutive frames for triggering suppression.
For noise sequences, as adaptive filtering identifies most of the frames as noise frames, option 1 and 3 will be same.
Perceptual rate control algorithm changes Qp for wrt complexity of the picture and its effect may not be visible for noise sequences.

Current frequency suppression algorithm works on the transform coefficients without much change on rate control algorithm which is set and optimized for normal sequences. Option 3 for the suppressHighFreqCoeffs is the highest compression possible out of frequency suppression. Improving further for noise sequences bits reduction will need lot of efforts in changing rate control algorithm.

Thank you very much for the detailed analysis on RC and Suppression algorithms.
As you already know, other options can be tuning intraFrameInterval, enableIntraPartition etc.

Thanks and regards

Sudheesh