About Freescale i.MX6Q VPU codec simultaneously
Locked
 
|
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! |
Re: About Freescale i.MX6Q VPU codec simultaneously
|
|
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 |
|
|
First, use queue, not queue2. queue2 is overkill for this, and typically used for network buffering. ---------------------------------- OK, I'll try to use queue. 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. -------------------------------- I've tried to put base.mp4 to tmpfs, and write new.h264 to tmpfs, buf the result is as the same as before. So I think that I/O is not a bottleneck. Third, what happens if you set sync=false in imxg2dvideosink? -------------------------------- OK, I've got a smooth play of the base.mp4 after setting sync=false in imxg2dvideosink, but I found that the playing time(33 seconds) is longer than the normal(30 seconds). We can't stand the latency. Now I'm trying to use mxc_vpu_test demonstration example to optimize this, I think some memory copys happened in Gstreamer, so it should be OK if I avoid memory copys, espically the decoded YUV data. I'll use only a thread to run VPU encodec and decode. If I have some good result, I'll show you. I am not working in company, because a New Year in China. and Happy New Year to you. -- 夫君子之行，静以修身，俭以养德。 At 2017-01-25 18:26:08, "Carlos Rafael Giani [via GStreamer-devel]" <[hidden email]> wrote: Several possibilities.
|
|
|
In reply to this post by qqk
Hello,
I am not really a person to give advises on that. So, i will share my guess. OK? (can be a good start, as long as nobody did respond to you till now)
As i see, it is latency problem. It is discussed a lot on forum. You easily find it.
Sorry. It is all how i can help.
Mikl _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
|
|
OK, thank you. 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-02-10 20:54:39, "Mikl [via GStreamer-devel]" <[hidden email]> wrote:
|
|
|
In reply to this post by Carlos Rafael Giani
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]" <[hidden email]> wrote: Several possibilities.
|
«
Return to GStreamer-devel
|
1 view|%1 views
| Free forum by Nabble | Edit this page |