androidmedia

[Andoni Morales]

Zerocopy in android can be done passing a SurfaceTexture to the android
media codec. We have a working branch for 0.10 here:
  https://github.com/fluendo/gst-plugins-bad/tree/sdk-0.10.23-hls
It's a hack that only work for playback and without any kind of negotiation.

In the hackfest I started porting all this work to 1.0 but I did not have
time to finish it. I have pushed my changes so far in this branch:
https://github.com/ylatuya/gst-plugins-bad/tree/amczerocopy

In case anyone is asking...  *IT DOES NOT WORK AT ALL YET*

The things missing are:
 1) Use a GstMemory instead of GstMeta for passing the surface and codec
structure downstream
 2) Handle proper negotiation

Cheers,
Andoni


2014-03-29 19:27 GMT+01:00 Yves Bard <yves.bard at free.fr>:

> Hi,
>
>    I have take a look at this decoder performance.If it could help you,
> here are some more infos.
>   The main trouble comes from the use of the mediacaodec class which tends
> to copy all frames from the the gpu to the cpu. This copy is very bad and
> produce dreadful performance ( see :
> http://stackoverflow.com/questions/15500290/access-violation-in-native-code-with-hardware-accelerated-android-mediacodec-dec).
>
> The First solution is to send a surface to the amcdecoder plugin with a
> new property, and use it with the mediacodec class. Then write some
> java+opengl glue to decode to a fbo, then pass the fbo to the eglsink or
> whatever plugin you want to use.
> The second solution is to do a strange mix between a decoder and a sink,
> but it's not a "gstreamer friendly" solution, cause you can't use the post
> decoder plugins. You transform the decoder into a decoder-sink ( in fact a
> gstsink ) and send a surface to your new sink. the media codec send the
> frame to the surface, you just have to write some java code to use the
> surface.
>
> The third solution is to ask some google guy's  to correcte/ameliorate
> their mediacodec implementation ( :) )
>
> -> The first solution is an evolution, the second ask some development,
> the third some prayers. I don't see any bugs :)
> -> I would love to see the first solution implemented. Is it possible to
> do something like this for the 1.4.0  ?
>
> sincerely,
>
>  Yves Bard
>
> Le 29 mars 2014 à 09:49, Sebastian Dröge <sebastian at centricular.com> a
> écrit :
>
> On Mi, 2014-03-26 at 17:01 -0400, Alok Kumar wrote:
>
> Thanks you for reply.
> It seems to be using amcvideodec-omxsecavcdec0, but it is dropping lots of
> frame for 1080p 60fps (hence skipping frames)
>
> 03-26 12:22:33.745: W/GStreamer+amcvideodec(4817): 0:01:01.052789946
> 0x6039b630
> gstamcvideodec.c:1158:gst_amc_video_dec_loop:<amcvideodec-omxsecavcdec0>
> Frame is too late, dropping (deadline 0:00:00.084564417)
> 03-26 12:22:33.745: W/GStreamer+amcvideodec(4817): 0:01:01.054200696
> 0x6039b630
> gstamcvideodec.c:1158:gst_amc_video_dec_loop:<amcvideodec-omxsecavcdec0>
> Frame is too late, dropping (deadline 0:00:00.067775529)
>
> pipeline as "filesrc ! decodebin ! eglglessink", should adding queue buffer
> will help ?
>
>
> This is most likely a problem of amcvideodec and eglglessink not doing
> zerocopy rendering together. Could you file a feature request bug about
> that at http://bugzilla.gnome.org ?
>
> --
> Sebastian Dröge, Centricular Ltd - http://www.centricular.com
> Expertise, Straight from the Source
> _______________________________________________
> gstreamer-android mailing list
> gstreamer-android at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-android
>
>
>
> _______________________________________________
> gstreamer-android mailing list
> gstreamer-android at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-android
>
>


-- 
Andoni Morales Alastruey

LongoMatch:The Digital Coach
http://www.longomatch.ylatuya.es
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-android/attachments/20140329/534a541d/attachment.html>