[i.MX6] VPU capability v.s. GOP size ?

[castel]

Hi all,

     I'm working to decode our samples, 4 x 720 25p H.264 ts (I-frame only,raw H.264 Annex-B byte-stream, like the "vpuenc code=6" produced), I first try the Gstreamer to drive VPU.

     But I meet 2 problems when the 2nd to be played:

             a. "Physical memory allocation error!"

                    This seems to be solved through we set "frame-plus=1" from the thread [ Memory Reserved on i.MX6 for VPU ] 

                    but decoding fail is remained by the following 'b'.

             b. "[WARN] ....VPU lock timeout" and a exception causes from gstreamer

                    Because the multi-streams decoding is OK when we change to use other 720 samples(H.264/MP4 720 30p x 3), we guess the error may be related to the GPO size of 1 in our TS,  we try to prove our guess, and it seems to be proved:

                            to produce a H.264 stream by VPU as sample of GOP=15 :

                                   gst-launch videotestsrc ! "video/x-raw-yuv,width=1280,height=720,framerate=25/1" ! vpuenc code=6 gopsize=15 ! filesink....

                            the 2nd decoding of the sample is OK:

                                   gst-launch filesrc.... ! typefind ! vpudec ! fakesink sync=1.

                            as to another sample encoded in GOP=1,

                                   gst-launch videotestsrc ! "video/x-raw-yuv,width=1280,height=720,framerate=25/1" ! vpuenc code=6 gopsize=1 ! filesink....

                             the 2nd decoding is fail, the error is the same as one from decoding our target sample.                       

     I only try the SOLO now, but all S/DL/Q are on my hand, we'll get good news if trying the higher-end one? (so far as we know, the S/DL/D/Q's VPU have the same skill, the only difference is DL/D/Q could decode dual 1080 30p in dual screens because of bandwidth of DDR3 64bits)

     If the foregoing is solved to be able to decode 4 x 720 25p in background, the performance needs to be considered? (though the VPU skill of multi-streams listed in Freescale slice is 3 x 720 30p, we think it's OK to decode the 4th one according to calculating(1280x720x25x4=92M pixels) refers to the thread [ Memory Reserved on i.MX6 for VPU ]

thanks.

[karina_valencia]

Re: [i.MX6] VPU capability v.s. GOP size ?

eaglezhou May 30, 2013 9:59 PM (in response to imxcommunityscout)

What is your package version ?

such as vpudec plugin/vpu lib/wrapper/firmware.

I tried GOPSIZE=1 in my board, the decode process is ok.

>gst-launch filesrc location=temp_gopsize_1.h264 ! typefind ! vpudec ! fakesink sync=1

My envrionment is :

MFW_GST_V4LSINK_PLUGIN 3.0.5 build on May 17 2013 22:35:09.

Setting pipeline to PAUSED ...

[INFO]  Product Info: i.MX6Q/D/S

vpudec versions :

        plugin: 3.0.5

        wrapper: 1.0.24(VPUWRAPPER_ARM_LINUX Build on May 17 2013 18:25:39)

        vpulib: 5.4.10

        firmware: 2.1.8.34588

[castel]

Hi, Peng:

     we've found it seems to be related by Bitrate not the GOPsize.

     we use a h264 file(26s length) as source, to transcode to I-frame-only ones by VPU, there're only different on size, one is 50MB another is 58MB (by vpuenc "bitrate" para. to control size), it results the former playback is OK but the larger one is FAIL(jitter, freeze ...), even if the IPB-frame one has the issue so. Is there any place could we upload the file for checking?

     we want to find the Bitrate SPEC about the i.MX6 VPU but fail.

     Version:

          we both test the 3.0.5 (with BSP 1_1_0) & 3.0.7(with BSP 4_0_0) and the issue is the same.

thanks.

[castel]

HI, Peng:

     We've uploaded our sample & playback them individually(for each sample, 1st playback to mfw_v4lsink for smoothness check, 2rd~8th playback into fakesink, "sync=1" be added to follow pipeline clock.).

     5 samples:

       1.  orirignal(800x480).h264 (55MB)

               our original file, the jitter occurs(see the car moving is not smooth!) when we do the 5th plays.

       2. vpuenc_gopsize_1_codec_6.h264 (121MB)

               transcoded from "gst-launch filesrc location=orirignal(800x480).h264 ! typefind ! ffdec_h264 ! mfw_ipucsc ! "video/x-raw-yuv,width=720,height=480" ! vpuenc gopsize=1 codec=6 ! filesink location=vpuenc_gopsize_1_codec_6.h264", no any vpuenc parameters added and bitrate is so huge! the 1st play is jitter and then frozen!

       3. vpuenc_gopsize_1_codec_6_Q20_bitrate_22M.h264 (70MB)

               transcoded from "gst-launch filesrc location=orirignal(800x480).h264 ! typefind ! ffdec_h264 ! mfw_ipucsc ! "video/x-raw-yuv,width=720,height=480" ! vpuenc gopsize=1 codec=6 quant=20 ! filesink location=vpuenc_gopsize_1_codec_6_Q20_bitrate_22M.h264", a para. 'quant' added to limit bitrate (22Mb/s, calculated from encoded file), only 1 play is OK, but the jitter is coming when the 2rd playing.

       4. vpuenc_gopsize_1_codec_6_Q25_bitrate_15M.h264 (51MB)

               transcoded from "gst-launch filesrc location=orirignal(800x480).h264 ! typefind ! ffdec_h264 ! mfw_ipucsc ! "video/x-raw-yuv,width=720,height=480" ! vpuenc gopsize=1 codec=6 quant=25 ! filesink location=vpuenc_gopsize_1_codec_6_Q25_bitrate_15M.h264", the jitter occurs when the 5th playing.

       5. vpuenc_gopsize_1_codec_6_Q35_bitrate_7M.h264 (22MB)

               transcoded from "gst-launch filesrc location=orirignal(800x480).h264 ! typefind ! ffdec_h264 ! mfw_ipucsc ! "video/x-raw-yuv,width=720,height=480" ! vpuenc gopsize=1 codec=6 quant=35 ! filesink location=vpuenc_gopsize_1_codec_6_Q35_bitrate_7M.h264", we can play 7 simultaneously OK! the jitter starts for watching when the 8th playing.

     Version: we use all kernel/roofs from the DEMO IMAGE "4_0_0"

    please help for check the issue, we concern the i.MX6's VPU capability for playback multi-stream, and what's limitation(GOP? bitrate?).

thanks.

[eaglezhou · Accepted solution]

Hi, Kang Wen,

   Seems I have access limitation to download your clips. I just give my suggestions below.

   (1) Normally, no special limitation for GOP and bitrate.

   (2) In my opinion, for real-time decoding, the case in which the instances number is more than 4 doesn't make too much sense.

       because it will introduce other bottle neck besides vpu decoder, includes video display.

       meanwhile, the thread/process are difficult to be guaranteed always actived in time by os scheduler.

   (3) gstreamer pipeline is designed/refined for most common clips, for the special clips(high bitrate; frequent I frames), the additional refine work maybe required.

       for high bitrate clips, you can add below codes in vpudec plugin to enlarge internal delay buffer size: (it will improve the efficiency of vpu decoder)

       int size=512000; //big enough to hold at least one video frame.

       CORE_API (VPU_DecConfig,, core_ret, vpudec->context.handle,VPU_DEC_CONF_BUFDELAY, &size);

   (4) For vpu performance issue in multi-instance, you should better try our vpu unit test. such as

     display: /unit_tests/mxc_vpu_test.out -D "-f 2 -i raw.h264"

     no display: /unit_tests/mxc_vpu_test.out -D "-f 2 -i raw.h264 -o /dev/null"

[garypollington]

Hi,

I'm also having issues trying to decode high bandwidth video ( h264 ) streamed over RTP

Where in the vpudec plugin would I put these codes

       int size=512000; //big enough to hold at least one video frame.

       CORE_API (VPU_DecConfig,, core_ret, vpudec->context.handle,VPU_DEC_CONF_BUFDELAY, &size);

file and function is fine .

Thanks !

Gary

[eaglezhou]

Hi, Gary

    You can add above codes into function gst_vpudec_setconfig() in file vpudec.c

Eagle

[castel]

Thanks, Peng:

     Seems the issue's been solved by indicating the larger size of input to VPU as you mentioned, and we've also checked the imx-test (mxc_vpu_test.out) and it works fine in multi-playback.