Issue occurs in using h264ven library function on DSPC8681(C6678)

Hi Sunzhao,

We once observed similar barrier stuck issue when the encoding bit rate is low and the resolution is 1080p. This has been identified as an issue internal to the codec, and we are fixing it. We will provide an updated codec library once the fix is finalized and verified. Meanwhile, what is the bit rate and resolution for your demo program? Can you please try with a larger bit rate?

Thanks,

Hongmei

Hi Hongmei,

    I don't think low bitrate cause this issue because the resolution and bitrate setting here is 480p with 10Mbps. After I try with larger bit rate,

The issue still occurs.

B.R.

Sunzhao

Hi Sunzhao,

We checked the source code and there is a single place which can cause one core in barrier 0 and another core in barrier 2. This is the issue we are fixing. We will keep you posted once we have an updated lib.

BTW, is 10Mbps too high for 480p? Can you please try a lower bit rate, say 2Mbps?

Thanks,

Hongmei

Hi Sunzhao,

Can you please try the updated H264BPENC lib as attached below? Please let us know if it resolves the issue you observed.

1715.h264venc_ti.zip

Thanks,

Hongmei

Hongmei,

   With the new library you provided, My application will still be blocked in the library function,

one is at sync point 0 and another is at sync point 2. And I also find that for some frames that

has already been encoded, some macro blocks lies at the boundary between the 2 cores are

not encoded correctly.

B.R.
Sunzhao

Hi Sunzhao,

Is this issue happening consistently? Is the blocking always for a specific frame of your test vector?

If it is possible, can you please share the failing YUV and also the encoding parameters? We would like to reproduce and further investigate.

Thanks,

Hongmei

Hi Hongmei,

      I find that some encoding error exist in my compressed bitstream,  some macro blocks

lies on the boundary between the 2 cores are not encoded correctly,  some mosaic can be

seen in the re-constructed picture. And I find there is a Rose red line exist in line 240 (bottom slice

of core0 is 240).  So I am checking if there is something error with my code. If so, the blocking

error may not caused by the library itself. I only want to know the possible reason that may causing

core0 blocked at sync point 0 and core1 blocked at sync point 1 , and also I want to know the possible

reason causing the rose red line on the boundary of 2 cores? I have ever suspect that it is a cache

coherence issue. But from the dumping log, I can ensure that the dual core has got same data

from the input buffer.

     As for the test vector, I find that every testing bitstream will block the encoder after tens of frames

encoded here...

B.R.

Sunzhao

Hi Sunzhao,

When the encoding cores have different results when detecting the slice types, say core 0 detects I slice while core 1 detects P slice, the two cores can enter different barriers: core 0 in barrier 2 and core 1 in barrier 0.

The artifacts and red line around the boundary can be due to cache inconsistency. Can you please check value of the MAR registers (0x01848200-0x0184827C)  . You mentioned that you made some code changes. What is your base code, H.264BP encoder unit test application or sv04 in MCSDK Video? Is it possible to try the same test vector in the baseline? Can you share the encoding parameters and/or the input clip if possible?

Thanks,

Hongmei

Hi Hongmei,

   My code is base on the H.264BP encoder unit test application. I find that even I have set the attribute
of all external memory to non-cachable, the red line is still occurs. So I think it is not related with
the cache coherence.
   And also I find that even I use the original test application to encode one of my test case(dual core case), the boundary
area between cores looks out of shape obviously. And I think you may reproduce this issue. Please help me
check it. My configuration file is attached here: 2262.cfg.rar
the original snapshot of frame is attached here: 5518.1.rar
the snapshot of compressed frame is attached here:4276.2.rar

the output file I generate here is attached here:0218.ref.rar

By the way, I may need one ftp server to upload my test case.
  
B.R.
Sunzhao

Hi Sunzhao,

Thanks for the files. It looks like the resolution of your input clip is 800x600. When the encoding is performed by multiple cores, the current H.264BP encoder published on Web supports only video height  of multiple of 16. When the video height is not multiple of 16, such as 600 in your test case, there will be artifacts on slice boundaries as you reported.

Using H264BP encoder unit test, I tried a 800x600 test vector with 20 frames, and the barrier stuck issue can be reproduced. With a resized test vector of 800x608, the encoding can be completed correctly. Is it possible to use 800x608 resolution in your use case? If so, can you please try it out?

If you have to use 800x600 resolution, the updated H264BP encoder library posted earlier in this thread has fixed the above issue and can support video height which is not multiple of 16 for multi-core encoding. I rebuilt the H264BP encoder unit test with this updated codec library, and then verified that it can encode 800x600 input with two cores. Can you please check if the updated H264BP encoder library is correctly linked when you tried it earlier? If the problem still exists, please send us your input clip. I will email you the FTP information for uploading.

Thanks,

Hongmei

Hi Hongmei,

     With the new video library you provided, I find that some artifacts still exist at the boundary area, although it seems a little better than before. I have upload one file named test800x600.yuv to the ftp server, You may check it.

B.R. Sunzhao  

Hi Sunzhao,

Thanks for sharing the input YUV. We tried it and can reproduce the quality issue for the 2-core encoding. It turns out there are some cache coherence issues with shared memory usage internal to the codec. One of such cases is fixed in the attached codec library and the quality degradation is reduced (still not completely avoided). Please give it a try. We are continuing the investigation and will let you know once the issue is fully resolved.

8054.h264venc_ti.zip

Meanwhile, we noticed that the degradation goes away when the bit rate is greater than 4Mbps (with the patched lib posted earlier and this new lib). Can you please also increase the bit rate and try?

Thanks,

Hongmei

Hi Hongmei,

    I find the quality of h264 baseline video encoder is not good especially it do encoding of the video scenes with black black ground(such as the terminal in linux).

I do analyze on the bitstream and find some "bars" are exist on the encoded frames. The attched file is the snapshot of it.5481.1.rar  Analying it with eseye, I find the quality is more worse. The attached file

 is the snapshot from eseye.1385.2.rar

My es bitstream is here.5074.outfile0.rar

My encoding parameter is almost the same as the unit test demo except that the I frame interval has been changed to 10 and the max search range is set to 9 And

the bitrate is set to 0x600000.

 Please help me check if there is something possible to improve the encoding quality. Thanks a lot!

B.R.

Sunzhao

Hi Sunzhao,

Thanks for the files. We are investigating the quality degradation issue with the baseline H264BP encoder. We will keep you posted once the issue is completely resolved.

The quality issue you are seeing with ESEyE can be due to it cannon handle "constrainedIntraPredEnable=1". Please use "constrainedIntraPredEnable = 0" in your configuration and retry. As for "SearchRange", 9 may be small for 800x600 resolution, and we can try 32 or 48.

For now, please use the latest H264BP encoder lib posted earlier and also set the bit rate larger than 4Mbps.

Thanks,

Hongmei

Hi Hongmei,

     I find that bugs exist in the latest video library(8054.h264venc_ti.zip) you provided. The bitstream generated by that library have MV errors when I played it with mplayer. The error log seems as below: "[h264 @ 0x8bb710] concealing 675 DC, 675 AC, 675 MV errors ..." After replace the library with the early version(1715.h264venc_ti.zip) , No error happens.

B.R.

Sunzhao

Hi Sunzhao,

The MV errors from MPlayer appear when there are SKIP frames generated from the encoding. For H264BP encoder, SKIP frames can be avoided even with a low bit rate when appropriate rate control algorithms are selected. We tried the following encoding settings with the latest codec lib (8054.h264venc_ti.zip), and there are no SKIP frames generated in the encoded output, even for bit rates lower than 4Mbps. As there are no SKIP frames, mPlayer is not giving any errors. No degradation is seen in ESEYE either.

Can you please use the above option to see if the degradation can go away?

Thanks,

Hongmei

Hi Hongmei,

   With the configuration parameter you provided, The error message generated by mplayer can be removed

 Thank you!  But I got another issue when I run video encoder on core6 and core7.  DSP print "Invalid core ID"

 in the CIO console. Because I havn't find this error message in my application. I guess it is from the video library.

And I guess it is caused by the IH264_MAXCORES. I want to know if we can remove this message because the

performance is very worse with it.

B.R.