H.264 bitstream encoded by TI's encoder (h264enc-r) on DM365 is not properly decodable by ffmpeg/VLC/MPlayer

Your setting seems to be fine assuming that "SequenceScalingFlag = 0". We have been making streams of BP using this encoder and did not see any issue playing on vlc or mplayer. Can you send one sample stream which you generated. Also, i beieve you are using 1.00.00.18 version of encoder whcih gets shipped with dbsdk 2.10, pls confirm.

regards

Yashwant

I'm using DVSDK v.2.10.01.18, but I have installed h.264 encoder v.01.10.00.08 (the latest I've found on the TI's website) into it. I've attached ZIP file containing the encoded bitstream, cfg files used to generate it and the ffmped decoding log containing a bunch of error messages.

Hope to hear from you soon,

Valery

Hi,

I used the config file that you have sent. I did not find any erors on my side for both VLC or mplayer. I am attaching the logs genearted by mplayer, VLC player and the bitstream that I got. 

Streams generated by you and me are different. IntraFrameInterval in your case is not 10 while the config put it to be 10. In my case I am getting 10. So I doubt you might have used different config file. Send the config file if you have used different one. When I opened the file in bitstream analyzer, I see there are  few error in the botom most of rows. To me it looks like all the bytes genearated were not written to file. I doubt on your cache settings. Disable the cache and let me know your result

Regards,

Neelakanth

4276.foreman_mar31_0.zip

Hi Neelakanth,

I use exactly the same cfg file I sent. And the problem with IDR frame interval is another disturbing issue for us to hinder our integration of DM365 into our product -- we need IDR frames to be generated with a predictable/controllable interval, sufficiently frequently, which currently does not seem to work. The other point of difference between the encoding processes for you and me is that your encoding session did not include any skipped frames, while for me sometimes 40% of all frames are skipped (which is not good for us, too). Note also, that the resulting files I get may differ from each other even for the same set of the input settings, from run to run, which also looks suspecious.

As to the cache settings, the demo test application source code contains several references to cache stuff:

1) calls to  ARM926_Icache_Disable()/ARM926_Dcache_Disable() which actually do nothing, the functions are defined as:

void ARM926_Icache_Disable()
{
 return;
}
void ARM926_Dcache_Disable()
{
 return;
}

2) CMEM memory parameters:

memParams.type=CMEM_POOL;
memParams.flags=CMEM_CACHED;
memParams.alignment=256;

3) invalidating cache for bitstream output before writing data to the file:

MEMUTILS_cacheInv(outArgs.videncOutArgs.encodedBuf.buf, outArgs.videncOutArgs.bytesGenerated);

Which of those cache-related code pieces should I change? And how?

With best regards,

Valery

For using non-cached, you need to follow you point 2. Pls change memParams.flags=CMEM_CACHED -> CMEM_NONCACHED; Let us know the result after that.  You need to do this in h264encoderapp.c. file.

regards

Yashwant

Valeri,

Also confoirm the version numbers of your toolchain. Below are the vesion on which I tested.

1. Framework components Version 2.24.01.06
2. XDC tools Version 3.15.00.12
3. Codec Engine 2.24
4. LSP Release Version 02.10.00.0
5. MVL toolchain version 5.0

You need to rebuild kernel modules (.ko) with the LSP version that you are using.

Regards,

Neelakanth

I changed CMEM parameter "flags" from CMEM_CACHED to CMEM_NONCACHED and now the output bitstream is decodable, IDR frame interval is just as expected and there're no frame skips. So, it seems the problem was with CMEM memory regions caching. I wonder how does CMEM memory caching affect the peroformance or any other aspect of video encoding on DM365?

Neelakanth,

1. Framework components are v2.24
2. XDC tools are v3.15.01.59
3. Codec Engine is v2.24
4. LSP is v02.10.00.14
5. MVL toolchain is v5.0

Valera,

This is cache issue. Did you modify the application?

Send the h264venc-r executable with and without cache. Also send all the print messages that come on the console when you run these two binaries.

Regards,

Neelakanth

Neelakanth,

The only thing I've modified was CMEM cache setting. Here're executables and logs for both cached and non-cached versions.

With best regards,

Valery

Valery,

I went through the log files and could not find anything obvious. We are trying to reproduce the issue at our end.

Regards,

Neelakanth

Neelakanth,

The only obvious difference between cached and non-cached versions are the frame sizes & the skips: the cached version produces much larges frames and many frames are skipped. Both phenomena are not so good for us (although not so critical).

With best regards,

Valery

Valery,

As a side note -

Have you tried using the encoder whcih comes as part of DVSDK 2.10.01.18 ? Are you seeing the issue there also ?

regards

Yashwant

Yashwant,

Although  the encoder from DVSDK 2.10.01.18 does not meet our requirements (we need support for at least for FullHD, better 2048x2048 and it supports no higher than 1280x720) I tested it too. Its behaviour is exactly the same: when the flag CMEM_CACHED is used, the encoder produces faulty bitstream with many frame skips, the output for the same settings varies from run to run, while for the case of CMEM_NONCACHED everything is allright, the encoder outputs the correct bitstream flawlessly decodable by ffmpeg.

With best regards,

Valery

Valery,

We are not able to reproduce the issue on our side. Do you have any updates fro your side?

Regards,

Neelakanth

Neelakanth,

No, I'm currently using the encoder with CMEM_NONCACHED flag and its behaviour with that flag is quite stable, so there's nothing new from me at the moment.

Perhaps, there's something special about our linux kernel build and/or kernel modules (e.g. cmem.ko)? Are there any specific requirements for the kernel/driver configuration for the CMEM memory caching to work properly?

With best regards,

Valery

Valery,

1. Change in LSP version is not a problem. I tested at my end with same LSP. My kernel is 2.6.18_pro500-davinci_evm-arm_v5t_le and let me know your kernel version.

2. I am using EVM. Are you using EVM or you have your own board?

3. My kernel modules differ from yours. When I use your binary I get error message

CMEM Error: init: major version mismatch between interface and driver.
CMEM Error:     needs driver version 0x3000000, got 0x2300000

This means, you have built your application with linuxutils 2_25 which comes with CE v2_25. Can you check your FC, linuxutils, CE and kernel modules. Keep all these versions same 2_24. Clean everything and do a rebuild of the complete application and then try running with cache enabled.

Regards,

Neelakanth

Neelakanth,

I've got linux kernel v. 2.6.32 (I believe that the guys responsible for the kernel and drivers have just built vanilla kernel source for armv5tejl platform) and I'm using our own board. I built the application with the newer linuxutils just due to the fact the kernel modules I've got have been built from there. I try to get older modules and test with them.

With best regards,

Valery

Valery,

Pls continure using the workwound of having uncached memory for encoding. As a more optimized workaround, you can just make the input buffer as uncached whcih seems to be the culprit.

We could not find the problem using review, and since it is not reproducible here, it might take some time to root cause it. Thanks for your support.

regards

Yashwant

Yashwant,

Ok, it seems that having uncached memory for video encoder does not affect its performace significantly. However, we're also using Ittiam's audio encoders (downloaded TI's website) in our product which seem to be software-only (not hardware accelerated) and are using CMEM memory too (internally, not for IO buffers) -- they might get affected by non-cacheable CMEM memory.

With best regards,

Valery