iMX6 VPU Zero Buffer Decode

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

iMX6 VPU Zero Buffer Decode

Jump to solution
3,665 Views
LeonardoSandova
Specialist I

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

1 Solution
1,334 Views
SteveBakke
Contributor II

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

View solution in original post

6 Replies
1,333 Views
ganeshr
Contributor I

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 ?

0 Kudos
1,334 Views
LeonardoSandova
Specialist I

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

0 Kudos
1,334 Views
SteveBakke
Contributor II

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

Steve

0 Kudos
1,334 Views
YixingKong
Senior Contributor IV

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

Thanks,

Yixing

0 Kudos
1,334 Views
LeonardoSandova
Specialist I

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

0 Kudos
1,335 Views
SteveBakke
Contributor II

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