x264enc on android: very slow.

[Haiming Wang]

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
> rebuild.
> 
> > 
> >   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:
> 
> https://bugzilla.gnome.org/show_bug.cgi?id=705129
> 
> 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.
> 
> regards,
> Nicolas 
> 
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20130731/b84bafdc/attachment.html>