x264enc on android: very slow.
whm_buaa at hotmail.com
Wed Jul 31 02:54:05 PDT 2013
HI Nicolas First up, let me explain how did I try to prove colorspace conversation is not the bottleneck. I set property "block" of appsrc to true. So each time when I want to feed data to appsrc, the function will block, untill there is a vacant buffer available. In android camer preview callback, each time when I got a new frame, I will feed the data to appsrc through jni synchronously. If there is no vacant buffer available at appsrc, the feeding will block. I count the framerate in camera preview callback. In this way I can evaluate how fast the pipeline encoding frames.
I really appreciate if neon optimization can be in the soft encoder :).
I heard some one encounter some problems in using hardware encoder. They said the bitrate is very high. I didn't try in person. I will try it later.
BTW, by many times try, I found the property "speed-preset" magically improved the encoding speed . Now I can get 8 fps for320x240 video.
Thank you very much for your help as ever!
Best Regards,Haiming Wang
> Subject: Re: x264enc on android: very slow.
> From: nicolas.dufresne at collabora.com
> To: gstreamer-devel at lists.freedesktop.org
> Date: Wed, 31 Jul 2013 00:36:19 +0200
> Le lundi 29 juillet 2013 à 21:28 +0800, Haiming Wang a écrit :
> > Hi Nicolas,
> > Thank you very much for your help.
> > Regarding the colorspace conversation, as I mentioned in my previous
> > email, I used a pipeline in which I replaced all the elements just
> > after ffmpegcolorspace with fakesink , and I found the speed is still
> > quite quick. The framerate is around the same as the camera preview
> > frame rate(15fps), So I believe the bottle neck should not be at
> > color space conversation.
> I don't fully understand what you have done to prove there was no
> colorspace conversion issues, neither in what replacing the encoder by
> fakesink show that. But I'm just giving you hints and this is might not
> be your issue. I had problem produce 30 fps in QSIF sized stream in the
> past because of that NV12 to I420 conversion issue on both iOS and
> Android. This is fixed upstream but not in any released version. Sharing
> more details about your build would help in figuring if you might have
> an affected build.
> > Regarding the profiling tool, what profiling tool do you suggest me
> > to use? I have some experience with gprof on android, but it was
> > said the tool doesn't support multi-thread very well. It's also not
> > easy to use. Do you have any suggestion about the tool?
> I have never used any profiling tools on Android. Last time I had the
> iOS profiling tool to show be the bottleneck. I have been told that
> oprofile and prof may way, but will require a rooted device and a kernel
> > You also suggest me using a simpler profile. Does the profile here
> > means h264 profile? Can it be configed by x264enc properties?
> Yes, h264 profile is usually set through caps, but that might not be
> true if you are using 0.10.
> > Yes, I also considered to use the hardware encoder on android.
> > However I didn't think the performance of the software is so
> > unacceptable. I see some software encoder running on Android, and the
> > frame rate can reach 15 fps, and the performance is quite acceptable.
> > I want to know if there are some settings for x264enc, which can
> > improve the performance.
> That being said, I realized it's not written yet, see:
> Also, as Arun have said, if you are using the SDK, it is built without
> NEON acceleration. Adding that does increase the performance a lot.
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the gstreamer-devel