Qt 4.8.0 on i.MX53 loco -blog archive

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

Qt 4.8.0 on i.MX53 loco -blog archive

1,665 Views
MasahiroUchida
Contributor I

Hello everyone,

I have fixed Qt 4.8.0 phonon to be able to use i.MX53 FSL-MMCODEC.

    patches: ltib-qt480.tar.bz2

  

My settings are :

  # LTIB version

        L11.09.01 (patched 201112)

  #  no X11, use QWS

        fb0: DI1[VGA display],  fb1:DI0[SEIKO WVGA] 

  # no webkit

  # opengl es1 enable (not tested)

  

but, I have found some problems:

  # It is very slow to play video on start up because the color conversion of mfw_ipucsc is very slow. 

  # mfw_ipucsc only supports 16-bit.

  

I will keep working to solve them for a while.

Which is better, fix gst-fsl-plugin or create a qt widget using native gst ?

  

Well, see you again.

Tags (1)
0 Kudos
6 Replies

993 Views
MasahiroUchida
Contributor I

Hello,

 

I said previous comment : 

>> So I changed "mfw_gst_vpu_decoder.c" to make use of internal buffers by default as below:

but this problem is caused by while loop in mfw_gst_vpudec_FrameBufferInit() .

I tried to run with removed line 650~680 from mfw_gst_vpudec_FrameBufferInit(),  

this bottleneck has disappreared. 

 

Someone know why this routine is implemented ?

 

See you!

0 Kudos

993 Views
MasahiroUchida
Contributor I

Hello,

Thank you for giving me notice the full-HD problem.

I had only tested some MP4 less than or equal to VGA size at that time.

And I want to stick to play video in Qt widget in order to use Qt features. 

I knew qwidgetvideosink is very slow as you indicated, but I have not found a solution for them.

Do you konw how to cut corners to QImage ?

Therefore Do I have to create a new Qt video sink ?

 

By the way, it was good to play full-DH video following gst-launch command:

 

gst-launch \
filesrc location=/root/trailer_1080p.mov typefind=true ! \
decodebin2 name=d0 ! \
queue max-size-bytes=256 ! \

volume volume=1 ! \
alsasink \
d0. ! \
queue max-size-bytes=256 ! \
identity ! \
tee name=t0 ! \
queue max-size-bytes=256 ! \
mfw_isink display=TV \
t0. ! \
queue max-size-bytes=256 ! \
mfw_isink display=LCD 

 

but many "VPU blocking: timeout." messages was reported by kernel.

So I will cut and try for a while.

 

Thanks.

0 Kudos

993 Views
micken
Contributor I

Hi again ,

It worked with a very lowres video. The real performance breaker is that the video is rendered to QImage:s.

If the video resolution is high , the sink (qwidgetvideosink) will drop most (all) buffers. It actually does a memcpy() two times. First from the GstBuffer to QBytearray and then from the bytearray to QImage.

0 Kudos

993 Views
micken
Contributor I

Hi,

I just tried your patch with a hd video. With a quicktime movie I get to the first frame and with other formats I get nothing.

However I didn't try your decoder patch , so I don't know if that affects this.

0 Kudos

993 Views
VladanJovanovic
NXP Employee
NXP Employee

that's nice and interesting work.Thank you for sharing it.

Can you play videos without issues now? Also high-resolution (full-hd)?

0 Kudos

993 Views
MasahiroUchida
Contributor I

Hello,

I have found the bottleneck on mfw_vpudecoder associated with converting color slowly.

The vpu decoder uses external buffers by default, but this logic is not so good.

So I changed "mfw_gst_vpu_decoder.c" to make use of internal buffers by default as below:

 

------------------------------------------------------------------------

g_object_class_install_property (gobject_class,
MFW_GST_VPU_USE_INTERNAL_BUFFER,
g_param_spec_boolean ("use-internal-buffer", "use internal buffer",
- "use internal buffer instead allocate from downstream", FALSE,
+ "use internal buffer instead allocate from downstream", TRUE,
G_PARAM_READWRITE));

 

vpu_dec->mirror_dir = MIRDIR_NONE;
vpu_dec->codec = STD_AVC;
vpu_dec->loopback = FALSE;
+ vpu_dec->use_internal_buffer = TRUE;
vpu_dec->vpu_chipinit = FALSE;

 

------------------------------------------------------------------------

See you!

0 Kudos