DM816x H264 Codec can't decode file that can be played on PC

Hi,

I was able to play the video but for some reason I have to tell the decoder that the video is 722 height instead of 720, trying to identify if the problem is the video itself or the codec. Any suggestion is welcome,

-David

Hi David,

Actual height detected in SPS is 736 and not 720. If the codec is created as 720 as maxHeight, then decoder will fail to decode.

Hi Ramprasad,

Yes, codecvisa reports 736 and not 720 but it also reports
- Cropping Bottom
16
so it means that the file is 720p. What is weird is why the decode_display plays the file as an interlaced file.

-David

Hi Ramprasad,

This seems to be something in the codec, the video is MBAFF but according to the datasheet it is supported. For instance, using the same file but less frames you could use the other decode application included in the EZSDK to see if the output of the decoder is the one that contains fields instead of frames. Using the file in [2], you can run:

/usr/share/ti/ti-omx/decode_a8host_debug.xv5T -w 1280 -h 722 -i /01_CH_720p_short.h264 -o decode.yuv -c h264

this produces a YUV file called decode.yuv which you can see using the yuv player in [3]

./7yuv decode.yuv

Setting the size as 1280x720 you can see at the bottom that each buffer contains two images, not just one as expected since the content is progressive.

Any ideas about why?

[2] dl.dropboxusercontent.com/.../01_CH_720p_short_300.h264
[3] http://datahammer.de/

Hi David,

MBAFF means macro-block level adaptive frame and filed . So decoder will consider this as an interlaced format and allocates two separate buffers for each field.

Please refer Appendix A.3 . This mentions interlaced and MBAFF picture format.

Ram

Hi Ram,

Thanks for your answer. There are actually two different concepts, Picture Adaptive Frame Field (PAFF) and Macroblock
Adaptive Frame Field (MBAFF) [4]. If this video were PAFF then I would think that is possible to get two fields in the output, however, the video is MBAFF which means that the macroblocks are the ones that could be in frame or field mode, not all the video buffer.

Using this video in other embedded systems you will see that the output is progressive however it seems a problem in the TI codec that since it is MBAFF it will put in the output an interlaced result, two fields.

If you play this video in the RDK, do you see the same result? Thanks again for your help on this,

-David

[4] www.iconceptpress.com/.../1205000470.pdf

Hi all,

I have a similar problem than David. I am using the latest EZSDK 5.05.02.00 with H264 decoder version ivahd_h264vdec_02_00_17_00_production on DM8168 EVM. I can not get a good video playback of the video in [1] using the decode_display application:

./usr/share/ti/ti-omx/decode_display_a8host_debug.xv5T -i 01_CH.h264 -w 1920 -h 1080 -f 30 -g 0 -d 0 -c h264

It starts showing the first frames and then it gets stuck but I can play the video in my PC without problems. Any help will be really appreciated!

- Eugenia

[1] https://www.dropbox.com/s/kixwe1v7sj5st2y/01_CH.h264?dl=0

Hi all,

I have a similar problem than David. I am using the latest EZSDK 5.05.02.00 with H264 decoder version ivahd_h264vdec_02_00_17_00_production on DM8168 EVM. I can not get a good video playback of the video in [1] using the decode_display application:


./usr/share/ti/ti-omx/decode_display_a8host_debug.xv5T -i 01_CH.h264 -w 1920 -h 1080 -f 30 -g 0 -d 0 -c h264


It starts showing the first frames and then it gets stuck but I can play the video in my PC without problems. Any help will be really appreciated!


- Eugenia

[1] www.dropbox.com/.../01_CH.h264

Hi David,

As Ram mentioned all h264 decoder on TI platforms stores MBAFF frames output in Field format. This is required as this frame can be a reference frame for future frame decoding and same frame/buffer will become Display frame. 

We believe application should not expect/assume format of the decoded YUV for any stream, it should check frame_type from the buffer and display accordingly.

Thanks,

Veeranna