Dynamic change of interframe interval in IPNC RDK 3.5?

Hi Badri,

I would like to extend this question about the B frame enabling.

So far, we are developing product by using DVR RDK4.0, and I found that the internal link will be failed if configuring the interFrameInterval other than 1.

The error code is as follows:

[m3video] 11674: ENCODE: Creating CH0 of 1280 x 720, pitch = (1280, 1280) [PROGRESSIVE] [NON-TILED ], bitrate = 3200 Kbps ...
[m3video] 11691:!ERROR!:ENCLINK::links_m3video/iva_enc/encLink_h264.c:[232]::INTERNAL ERROR:-1
[m3video] ALGCONTROL FAILED:CMD:1
[m3video] ERROR: XDM_UNSUPPORTEDPARAM = 14,
[m3video] ERROR: XDM_FATALERROR = 15
[m3video] ERROR: IH264ENC_UNSUPPORTED_RATECONTROLPARAMS = 21,
[m3video]
[m3video] 11691:ERR::linkID:10000021::channelID:0::errorCode:-5::FileName:links_m3video/iva_enc/encLink_h264.c::linuNum:1270::errorCondition:(algStatus == XDM_EOK)
[m3video] ENCLINK_H264:HEAPID:0 USED:1896
[m3video] 11692: Assertion @ Line: 925 in links_m3video/iva_enc/encLink_common.c: retVal == ENC_LINK_S_SUCCESS : failed !!!

Does the status match what you said that enabling B-Frame encoding is not supported in the encLink?

If so, do we have the option to turn on it? since we need to have the B frame feature to further lower down the bitrate usage and as I remembered, I can enable the B frame encoding under DVR RDK3.0

Thanks,

Thorpe

Hi Badri,

Sorry that I had found the issue why it failed. It's because I need to set the rate control type as VBR.

BTW, I found that the image quality is not improved obviously by turned on B-Frame coding using the same bitrate, is it expected?

I set the interFrameInterval as 3 for inserting 2 B-Frames between two reference frames.

I thought the image quality is supposed to improved obviously since B-Frame coding can save lots of bits while video coding, or is there anything I need to tune as well?

Thanks,

Thorpe

Thorpe,

Could you please share the encoder configurations used here? We suspect something is missing near application end. If possible share the raw video content.

Also mention the video encoder release integrated to this application.

Thanks.

Please refer to the thread http://e2e.ti.com/support/embedded/linux/f/354/t/283381.aspx

Thanks.

Hi Santosh,

Thank you very much for sharing the thread, it's exactly the issue I also concern now.

By the PSNR evaluated from Dave Beal, it looks like the value is lower too much, is it what you expected?

Per my experience, PSNR lower than 30 means very bad.

If the result is not as you expected, could you share a PSNR value you expected for us to reference in the case, 1920x1080, 3Mbps?

And, I have a question regarding to the comment, " 'B' frames always shall not improve the PSNR, sometime (fast moving scenes) they may degrade too".

I agree that B frame is not good for fast moving scenes, but it should save a lot of bits for reference frame, like I or P.

Which is, the overall quality is supposed to improve, are you agree?

Thanks,

Neal

Hi Neal,

PSNR depends on many parameters like bitrate, video content, encoder settings etc Below values are derived from our encoder( using Dave Beal's encoder settings)

• Que : I agree that B frame is not good for fast moving scenes, but it should save a lot of bits for reference frame, like I or P. Which is, the overall quality is supposed to improve, are you agree? Ans: Bits are saved only for moderate moving scenes/ temporal matching sequences. Otherwise 'B' frames consumes more bits if available else code the motion info with less quality(possible high Qp).

Hi Santosh -

Thank you for taking the time to recreate my work.  Using my encoder parameters, you got a much better PSNR than I did.  I took a quick look at the input buffer handling in IPNC RDK 3.5.0 and I think it is incorrect for B-frames, as you suggested.  I'll try to look into it more after my vacation.  Thanks again.

Hi Neal,

This problem is fixed at Dave Beal's end. Please have a look to http://e2e.ti.com/support/embedded/linux/f/354/p/283381/1002739.aspx#1002739

You also try verifying input/output buffer handling logic. Refer H.264 Encoder user guide for more information.

Thanks,

Santosh

Hi Santosh,

Deeply appreciate your feedback, I'll try the configuration as soon as possible.

BTW, I heard that you'll release a new version of DVR RDK 4.x for fixing B frame coding issue at 8/E 2013, is it correct?

if so, could you help to mention if the version is released?

Thanks in advance,

Thorpe

DVR RDK 4.1 release is not yet out. It is expected to be released on September 15 2013.It includes the fix for the timestamp ordering issue with B-frames you reported.

Roger that, thanks a lot for the feedback.

Thorpe

Hi Badri,

Sorry for the bothering.

We would like to know if the DVR RDK 4.1 is released?

Thanks,

Thorpe

Hi Badri and Santosh,

Could you kindly to feedback the question regarding to the release of DVR RDK 4.1?

Thank you very much,

Thorpe

The DVR RDK 4.1 release has been changed in scope and release is not expected until end of this month. Pls let us know which main issues you are looking for from RDK 4.1 and we can check if providing patch is possible.

Hi Badri,

We are looking for the solution about the issue of timestamp of B-Frame coding, it's also appreciated if we have the patch only.

Thanks,

Thorpe

Refer the attached files having all changes related to B Frame. You might have to selectively pickup changes http://e2e.ti.com/cfs-file.ashx/__key/communityserver-discussions-components-files/716/3157.b_5F00_frame_5F00_changes_5F00_pre_5F00_4.1.tar.bzrequired as this is based on our latest codebase.

Hi Sivagamy,

Thanks for the feedback, we'll phase the code in and evaluate it.

Thorpe

RDK 4.1 release is available so it is better you migrate to the released codebase.