<div dir="ltr"><div><div><div><div>Zerocopy in android can be done passing a SurfaceTexture to the android media codec. We have a working branch for 0.10 here:<br> <a href="https://github.com/fluendo/gst-plugins-bad/tree/sdk-0.10.23-hls">https://github.com/fluendo/gst-plugins-bad/tree/sdk-0.10.23-hls</a><br>
It's a hack that only work for playback and without any kind of negotiation.<br><br></div>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:<br>
<a href="https://github.com/ylatuya/gst-plugins-bad/tree/amczerocopy">https://github.com/ylatuya/gst-plugins-bad/tree/amczerocopy</a><br><br></div>In case anyone is asking... *IT DOES NOT WORK AT ALL YET*<br><br></div>The things missing are:<br>
1) Use a GstMemory instead of GstMeta for passing the surface and codec structure downstream<br></div> 2) Handle proper negotiation<br><br>Cheers,<br>Andoni<br><div><div><div><div><div><div><div class="gmail_extra"><br>
<br>
<div class="gmail_quote">2014-03-29 19:27 GMT+01:00 Yves Bard <span dir="ltr"><<a href="mailto:yves.bard@free.fr" target="_blank">yves.bard@free.fr</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div style="word-wrap:break-word">Hi,<div><br></div><div> I have take a look at this decoder performance.If it could help you, here are some more infos.</div><div> 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 : <a href="http://stackoverflow.com/questions/15500290/access-violation-in-native-code-with-hardware-accelerated-android-mediacodec-dec" target="_blank">http://stackoverflow.com/questions/15500290/access-violation-in-native-code-with-hardware-accelerated-android-mediacodec-dec</a> ). </div>
<div><br></div><div>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.</div>
<div>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.</div>
<div> </div><div>The third solution is to ask some google guy's to correcte/ameliorate their mediacodec implementation ( :) )</div><div><br></div><div>-> The first solution is an evolution, the second ask some development, the third some prayers. I don't see any bugs :) </div>
<div>-> I would love to see the first solution implemented. Is it possible to do something like this for the 1.4.0 ?</div><div><br></div><div><span style="white-space:pre-wrap"> </span>sincerely,</div><div><br></div>
<div>
<span style="white-space:pre-wrap"> </span>Yves Bard</div><div><br></div><div><div>Le 29 mars 2014 ā 09:49, Sebastian Dröge <<a href="mailto:sebastian@centricular.com" target="_blank">sebastian@centricular.com</a>> a écrit :</div>
<br><blockquote type="cite"><div style="font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
<div><div class="h5">On Mi, 2014-03-26 at 17:01 -0400, Alok Kumar wrote:<br><blockquote type="cite">Thanks you for reply.<br>It seems to be using amcvideodec-omxsecavcdec0, but it is dropping lots of<br>frame for 1080p 60fps (hence skipping frames)<br>
<br>03-26 12:22:33.745: W/GStreamer+amcvideodec(4817): 0:01:01.052789946<br>0x6039b630<br>gstamcvideodec.c:1158:gst_amc_video_dec_loop:<amcvideodec-omxsecavcdec0><br>Frame is too late, dropping (deadline 0:00:00.084564417)<br>
03-26 12:22:33.745: W/GStreamer+amcvideodec(4817): 0:01:01.054200696<br>0x6039b630<br>gstamcvideodec.c:1158:gst_amc_video_dec_loop:<amcvideodec-omxsecavcdec0><br>Frame is too late, dropping (deadline 0:00:00.067775529)<br>
<br>pipeline as "filesrc ! decodebin ! eglglessink", should adding queue buffer<br>will help ?<br></blockquote><br>This is most likely a problem of amcvideodec and eglglessink not doing<br>zerocopy rendering together. Could you file a feature request bug about<br>
that at<span> </span><a href="http://bugzilla.gnome.org/" target="_blank">http://bugzilla.gnome.org</a><span> </span>?<br><br>--<span> </span><br>Sebastian Dröge, Centricular Ltd -<span> </span><a href="http://www.centricular.com/" target="_blank">http://www.centricular.com</a><br>
Expertise, Straight from the Source<br></div></div><div class="">_______________________________________________<br>gstreamer-android mailing list<br><a href="mailto:gstreamer-android@lists.freedesktop.org" target="_blank">gstreamer-android@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/gstreamer-android" target="_blank">http://lists.freedesktop.org/mailman/listinfo/gstreamer-android</a></div></div></blockquote></div><br></div><br>_______________________________________________<br>
gstreamer-android mailing list<br>
<a href="mailto:gstreamer-android@lists.freedesktop.org">gstreamer-android@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/gstreamer-android" target="_blank">http://lists.freedesktop.org/mailman/listinfo/gstreamer-android</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>Andoni Morales Alastruey<br><br>LongoMatch:The Digital Coach<br><a href="http://www.longomatch.ylatuya.es">http://www.longomatch.ylatuya.es</a>
</div></div></div></div></div></div></div></div>