Hi,
I am using the DM368 and have set LBRmaxpicsize to 10 in order to keep the frames roughly the same size. Normally this works fairly well, but I notice that the size of the IDR can spike quite a bit above the size specified by BitRate/FrameRate. I have tried using rcAlgo of 0 and 5, and have set rcQMin=0, rcQMinI=0, rcQMax=51 and rcQMaxI=51 in order to let the encoder use the full range of quantization (as far as I know).
Is there any other method of controlling the frame size that will allow me to always keep it within the BitRate/FrameRate limit? If it would help I can gather some print outs of the frame sizes I am seeing, and can show any other encoder parameters necessary.
Thanks,
Chris
What value you are setting for maxdelay?. If its more try by reducing it. Rate control will try to restrict the max size to configured one. But it will not give surety. Can you share bytes generated log for the same.
May i know what is use case here? bcz if you restrict I frame size, quality will be very poor.
Hi Veeranna,Thanks for the response. Currently I am using maxDelay of 1000. I would ideally like to reduce that further, but thought that would introduce more possible frame skipping. Can the frame skipping be controlled then by LBRskipcontrol of 0x00010001? I am using rate control mode of 5 (CBR1) for reference. Also, what is the minimum possible value of maxDelay? I have seen in the user guide it says >= 100, but I am able to set it to 33 (for one frame VBV) and don't get any errors. Is setting it to 33 supported?I had another thought to use the Gradual Decoder Refresh feature in order to spread the I slices over a group of frames, but setting enableGDR to 1 or 2 (and setting GDRduration and GDRinterval appropriately) does not seem to have any effect. Any ideas here as well?The goal of the work I am doing is to stream H.264 inside a transport stream to a TV broadcast decoder that only accepts very strict CBR data. It works fairly well at the moment, besides the jump in frame sizes, the low quality of the IDR frames and the need for me to insert filler data NAL units to keep CBR.This is all running on a PTZ camera, so the video scene can change quite rapidly. Here is a log showing the data at 4Mbps for one second while moving the camera. Note that I would ideally like to see frame sizes of ~16666, and I notice now that it's not only the IDR frame that is going above 16666 bytes: generated frame t 3 s 18785 - IDR frame (t == 3) generated frame t 1 s 18690 generated frame t 1 s 17680 generated frame t 1 s 17653 generated frame t 1 s 17507 generated frame t 1 s 17216 generated frame t 1 s 17324 generated frame t 1 s 17224 generated frame t 1 s 17020 generated frame t 1 s 17081 generated frame t 1 s 16888 generated frame t 1 s 16727 generated frame t 1 s 16689 generated frame t 1 s 16795 generated frame t 1 s 16553 generated frame t 1 s 16541 generated frame t 1 s 16527 generated frame t 1 s 16571 generated frame t 1 s 16555 generated frame t 1 s 16584 generated frame t 1 s 16515 generated frame t 1 s 16544 generated frame t 1 s 16580 generated frame t 1 s 16592 generated frame t 1 s 16489 generated frame t 1 s 16523 generated frame t 1 s 16601 generated frame t 1 s 16592 generated frame t 1 s 16481 generated frame t 1 s 16493 generated frame t 3 s 18905 - IDR frame (t == 3)Thanks for your help,Chris
1) Reg Max delay
User guide has below lines(4-48 page)
maxDelay:Input Maximum acceptable delay in milliseconds for rate control. Min Limit: No minimum value check Max Limit : 30000 msIt is recommended to use value greater than 100ms.Typical value is 1000 ms.By default, this is set to 2000 ms at the time ofencoder object creation
Can you please point me in which section you seen it?
2: Reg GDR.
It should work. You should see Intra slice in GDR interval. and SPS at start of GDR.
Can you please share GDR params and generated stream. Please note that GDR will get disable if GDR interval and I/IDR interval are same. And GDR is not supported in interlace mode.
for more info
http://processors.wiki.ti.com/index.php/H.264_DM36x_Ver_2.0_Codec#Gradual_Decoder_Refresh_.28GDR.29
3: Reg max pic size.
These bytes look ok to me. AS IDR is the 1st frame for RC, so it will allocate more bits to encode.
If your decoder is very strict about frame size, we have one rate control mode for this, it will 100% guarantee the size but speed performance is less. Please have a look at diffrent RC modes .
Veeranna