Android 6.0 gstreamer 1.0: frame is not writable

[Sebastian Dröge]

On So, 2015-12-06 at 20:27 -0800, Gregoire Gentil wrote:
> 
> > What does your application / pipeline look like? Are you using
> > playbin?
> [G2]. It's a very standard playbin:
> 
> playbin uri=file://file.mp4 video-sink="videocrop ! glimagesink"
> 
> I don't think that videocrop changes anything and most of the time,
> it's inactive as all properties are at 0 (documentation says that
> it's then pass-through).

If you would use 1.7 and try to use zerocopy, then this would downgrade
it to run in the CPU and be slow.

Ideally you would do cropping at the display layer, e.g. by adjusting
the Android surface or by just getting GL textures from GStreamer and
rendering them yourself.

> > It would be good to get a debug log as mentioned in my previous
> > mail for the 1.6.0 case, with playbin.
> > 
> > Also if you want to try latest GIT master, in playbin (or suitable
> > manual pipelines) it will do zerocopy decoding/rendering and should
> > provide much higher performance as long as you don't need to look
> > at the pixel data from the CPU.
> > 
> > > - Software decoder has a NON writable buffer (at least on
> > > gstreamer
> > > 1.5.0). Temporary fix is to add "buffer =
> > > gst_buffer_make_writable(buffer);". I guess that it adds a
> > > memcpy.
> > 
> > That's expected currently and this bug:
> > https://bugzilla.gnome.org/show_bug.cgi?id=740222
> > 
> > Making the buffer writable causes a memcpy() here. Why do you need
> > it
> > writable in your case?
> [G2]. Two things: I need a notification when each frame is about to
> be rendered. I also need to alter the frame content to draw some
> overlay info. It would be possible to draw this overlay in a separate
> transparent Android surface on top but I have already piled up many 
> surfaces and for portability, I prefer to draw this specific overlay
> on the native stream.
> 
> I intercept each frame in the sink pad of glimagesink,

Basically same comment as above here :) This is not going to work very
optimal as you're going to do all the processing in the CPU.


But for the actual problem it would be good to get some debug logs.

-- 
Sebastian Dröge, Centricular Ltd · http://www.centricular.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20151207/706d3798/attachment.sig>