iMX6 VPU Zero Buffer Decode

[LeonardoSandova]

Original thread is from a user's profile area, but placing on i.MX Community for wider audience:

We need to use the VPU decoder in a zero-delay mode, i.e. we give the decoder a frame of H.264 data and the decoder performs the decode and provides the framebuffer, immediately.  It looks like according to the documentation if we set reorderEnable in the DecOpenParam structure, the decoder should operated in this mode.  However we must feed 3 frames in before we get the first frame out. Previously we used iMX53 and this zero-delay decode worked fine.

Enclosed is a modified version of the mxc_vpu_test example.  The example was modified to read a .h264 files along with an index file that precisely feeds one frame per keystroke to the decoder.  The very first frame is made up of SPS, PPS and and I-Frame, all other frames are P frames.  A Readme file in the tgz file explains the changes.  You need to build this in the same directory as the original mxc_vpu_text.  You probably will have to modify the system directory and the example should build.  Also the binary is included see readme for launch instructions.

I guess we are missing setting some parm somewhere to get into this zero-delay mode????

Original Attachment has been moved to: mxc_vpu_test_single_frame.tgz

[ganeshr]

I have the exact same requirement in my project to decode H264 frame by frame . I have following questions :

1. How can one generate index file (car.idx) for any h264 streams ?

[LeonardoSandova]

Hi SteveBakke seems that the main problem is that the statement DecOpenParam.reorderEnable=0 is somehow ignored.  Have you tried other set of h264 & idx files? or more general, other codec formats? Perhaps you are not interested in other codecs but this is just to make sure the code you have added is correct.

Leo

[SteveBakke]

Yes, other files and the "live real-time stream data" has the same problem.  It must be H.264.

Steve

[YixingKong]

Steve, please click Correct Answer/Helpfule Answer if your issue is resolved.

Thanks,

Yixing

[LeonardoSandova]

HI Steve,

I have queried your question to one of our experts (DaianeAngolini) and she mentioned the following:

"“reorder” does not seems to mean “zero buffer”

Reorder on a H264 is not what I would like to expect from a zero buffer approach, because H264 first frame is not a complete displayable frame. You may try using another decoder.

But, the mainly thing would be considering that i.mx53 default MM version is an old on. Something like 2.0.5. And now we are at 3.0.8 for imx6. It means we gone from 2.X.X to 3.X.X, a huge difference into the source code. Imx5 VPU decoder was based on imx-lib, current imx6 vpu decoder is based on libfslvpuwrap. I don´t think the VPU firmware changed so much (it is still 1.0.15 currently). Maybe customer can compare both source codes in order to understand why reorder used to work and know it´s useless."

Leo

[SteveBakke · Accepted solution]

Yes that worked.  Instead of using the VPU_xxx API, we used the libfslvpuwrap API (which then calls the VPU_XXX API).  We could not tell exactly why this worked, but can't knock success!!!!

Thanks,

Steve