Image quality is not improved obviously if using B-Frame coding

THere are changes required at encLink level to  enable B-frame encoding. These are not part of RDK 4.0. It will be availavle in the next DVR RDK release. There is a patch you can use for evaluation purposes :

http://e2e.ti.com/cfs-file.ashx/__key/communityserver-discussions-components-files/717/1882.enc_5F00_link_5F00_b_5F00_frame.patch

that can be applied on top of RDK 4.0.

Enable B-frame encoding only after applying this patch. AFter that check the generated stream really has B-frames using a stream analyzer.

Refer this post for additional  details: http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/717/p/276048/972270.aspx#972270

Hi Badri,

Thanks  a lot for the feedback.

According to the reference post, it looks like the new patch fixed the dynamic resolution change while encoding.

Could you also help to mention the other detailed fix about the B-Frame coding by the patch?

Actually, I would like to know if the encoded timestamp is being corrected after enabling B-Frame coding.

For example, I found the current timestamp output is as follows

IBBPBBPBBP... and output timestamp is 012345678...

But, the correct  timestamp is supposed to be 201534867...

Thanks in advance,

Thorpe

The patch has nothing to do with dynamic resolution. The patch add basic encLink functionality to enable B-frame encoding and B-frame encoding _should_not_ be enabled without this patch.B-frame encoding requires changes in encLink to handle locking of reference buffers and out of order output of bitstream buffers none of which will work correctly without this patch.I summary don't enable B-frame encoding unless you have this patch,

Hi Badri,

From the patch, I see there a folder change in Rules.make, which is 

-h264enc_DIR := $(TI_SW_ROOT)/codecs/REL.500.V.H264AVC.E.IVAHD.02.00.04.01
+h264enc_DIR := $(TI_SW_ROOT)/codecs/REL.500.V.H264AVC.E.IVAHD.02.00.06.00

It looks like the encoder firmware had also been updated to 02.00.06.00, but I don't have it on hand.

Could you help to forward it to me as well?

Thanks,

Thorpe

As mentioned in the post don't modify Rules.make and continue to use the encoder version that is part of DVR RDK,

Roger that, I'll try the patch to see the result.

Thanks a lot,

Thorpe

Sorry to bother again.

I found there are some mismatches afte applying the patch on our code from DVR RDK 4.0 and got some compiled errors.

Our SDK version is 04.00.00.03.

Is the patch matched to our SDK version?

Thanks,

Thorpe

What is  the compile error ? Share the error logs

Here is the error log regarding to the compile error

"links_m3video/iva_enc/encLink_h264.c", line 444: error: identifier "IH264ENC_EXTERROR_NUM_MAXWORDS" is undefined
"links_m3video/iva_enc/encLink_h264.c", line 572: error: identifier "IH264ENC_EXTERROR_NUM_MAXWORDS" is undefined
"links_m3video/iva_enc/encLink_h264.c", line 574: error: struct "<unnamed>" has no field "extErrorCode"
"links_m3video/iva_enc/encLink_h264.c", line 574: error: struct "<unnamed>" has no field "extErrorCode"
"links_m3video/iva_enc/encLink_h264.c", line 575: error: struct "<unnamed>" has no field "extErrorCode"
5 errors detected in the compilation of "links_m3video/iva_enc/encLink_h264.c".

Thanks,

Thorpe

BTW, I had fixed the by myself. (I just mark the code since it's for error message only)

After applying the new patch, I still had the question as follows.

I'd set the interFrameInterval as 3 and the following is the log I dumped after get the bitstream buffer from Venc_getBitstreamBuffer()

encode timestamp: 2160, upperTimeStamp: 0, lowerTimeStamp: 3262, timestamp: 3262, size: 8728
encode timestamp: 2192, upperTimeStamp: 0, lowerTimeStamp: 3295, timestamp: 3295, size: 22949
encode timestamp: 2229, upperTimeStamp: 0, lowerTimeStamp: 3328, timestamp: 3328, size: 1041
encode timestamp: 2261, upperTimeStamp: 0, lowerTimeStamp: 3361, timestamp: 3361, size: 7740
encode timestamp: 2293, upperTimeStamp: 0, lowerTimeStamp: 3394, timestamp: 3394, size: 19141
encode timestamp: 2325, upperTimeStamp: 0, lowerTimeStamp: 3427, timestamp: 3427, size: 950
encode timestamp: 2360, upperTimeStamp: 0, lowerTimeStamp: 3460, timestamp: 3460, size: 10061
encode timestamp: 2392, upperTimeStamp: 0, lowerTimeStamp: 3493, timestamp: 3493, size: 44949
encode timestamp: 2424, upperTimeStamp: 0, lowerTimeStamp: 3526, timestamp: 3526, size: 7798

....

My question is that why the timestamp is increasing sequentially? By my understading, the timestamp is supposed to be like, 2229, 2160, 2192, 2325, 2261, 2293.... due to display order is not the same as encoding order

I also check another provided timestamp, such as upperTimeStamp, lowerTimeStamp and timestamp inside VCODEC_BITSBUF_S, but the value is still increasing sequentially.

If possible, could you help to comment the behavior?  Do we need to regular the timestamp by our application level?

Thank you very much,

Thorpe

Don't refer encodeTimestamp.It refers to time when encoding is complete and is for profiling purposes. Not useful for anything else.

The issue you have found with upper and lower timestamp is a bug . I checked the code and timestamp assignment to bitstream buffers is not done correctly when stream has B-frames. We will share a patch once this is fixed.

Got it, thank you very much for the feedback. :)

Regarding the timestamp issue, do you have the schedule to forward the new patch? We hope to get it since we are developing the B-Frame encoding for our application now.

Thanks in advance,

Thorpe

The fix will be part of the next DVR RDK release 4.x scheduled to be available end of Aug 2013.

Thanks a lot for the fixing.

And, it's more appreciated that if possible, you can provide the patch early of the format release for us to do some testings.

Thanks in advance,

Thorpe

Hi Badri,

Had DVR RDK release 4.x released now? If so, could you also share the version number?

I'll ask our contact window to download the new release and have a try.

Thank you very much,

Thorpe