About Freescale i.MX6Q VPU codec simultaneously

[qqk]

I think I found the reason of the latency problem.


Now I'm trying to use mxc_vpu_test demonstration example to optimize this,  I didn't do memory copys, espically 
the decoded YUV data.
I pass the address of decoded YUV buffer for display to the address of input encode YUV buffer directly,  now the
fps of decode for display and encode for saving to file simultaneously,  can achieve about 28 fps.


So It's OK !





--

夫君子之行，静以修身，俭以养德。

At 2017-01-25 18:26:08, "Carlos Rafael Giani [via GStreamer-devel]" <ml-node+s966125n4681631h35 at n4.nabble.com> wrote:
Several possibilities.

First, use queue, not queue2. queue2 is overkill for this, and typically
used for network buffering.

Second, try what happens if you put base.mp4 in tmpfs (meaning it is
placed in RAM) and also write new.h264 to tmpfs. The idea here is to
rule out I/O as a bottleneck.

Third, what happens if you set sync=false in imxg2dvideosink?


On 2017-01-23 04:10, qqk wrote:

> Hi, everyone.
>
> I have posted this topic on NXP community.
> The website is :
> https://community.nxp.com/message/868167
>
> BUT nobody can answer it.
> So  I post it here for help.
>
> --------------------------------------------------------------------------------------------------------
>
> Hello,
> I have a question about VPU codec on IMX6Q.
>
> First, a MP4 file is loaded into memmory, then it is be demuxed to the H264.
> After that, we get the input H264 data. OK, now we need doing 3 things
> simultaneously.
> 1. H264 is send to VPU, then VPU decodes it to YUV. YUV is send to IPU or
> G2D for display.
> 2. At the same time, H264 is also send to VPU for re-encoding to a new H264
> file.
> 3. At the same time, H264 is also send to a remote PC for RTP/UDP streaming
> simultaneously.
>
> I use Gstreamer to finish that. the GST commond is :
> gst-launch-1.0  -v filesrc location=`pwd`/base.mp4 ! qtdemux ! h264parse !
> tee name=tt tt. ! queue2 ! rtph264pay ! udpsink host=192.168.1.110 port=5000
> tt. ！ queue2 ! imxvpudec ! tee name=t t. ! queue2 ! imxg2dvideosink t. !
> queue2 ! imxvpuenc_h264 bitrate=10240 ! filesink location=new.h264
>
>  
> Now , we found that the IMX6Q has not a smooth play of the MP4 file on the
> LCD by using IPU or G2D. but the remote PC can play smoothly by using
> RTP/UDP.
> How can I optimize that ?
>
> thanks!
>
>
>
> --
> View this message in context: http://gstreamer-devel.966125.n4.nabble.com/About-Freescale-i-MX6Q-VPU-codec-simultaneously-tp4681586.html
> Sent from the GStreamer-devel mailing list archive at Nabble.com.
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel



If you reply to this email, your message will be added to the discussion below:
http://gstreamer-devel.966125.n4.nabble.com/About-Freescale-i-MX6Q-VPU-codec-simultaneously-tp4681586p4681631.html
To unsubscribe from About Freescale i.MX6Q VPU codec simultaneously, click here.
NAML



--
View this message in context: http://gstreamer-devel.966125.n4.nabble.com/About-Freescale-i-MX6Q-VPU-codec-simultaneously-tp4681586p4681838.html
Sent from the GStreamer-devel mailing list archive at Nabble.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20170210/6a4baf92/attachment.html>