Android 6.0 gstreamer 1.0: frame is not writable

[Gregoire Gentil]

On 12/06/2015 12:02 AM, Sebastian Dröge wrote:
> On Sa, 2015-12-05 at 18:18 -0800, Gregoire Gentil wrote:
>>
>> Analysis:
>> - gstreamer 1.6.0 doesn't compile with NDK-r9. Found a similar bug
>> report. Recommendation was to upgrade. It compiles with NDK-r10e.
>
> Yes, there were some API changes on Google's side between r9 and r10
> which make this necessary unfortunately. The NDK version is unrelated
> to your problem though.
>
>> - gstreamer 1.5.x on Android 6.0 doesn't find the hardware decode,
>> hence the software decoding. Found a similar bug report.
>> Recommendation was to upgrade. Indeed, gstreamer 1.6.0 fixes this
>> problem. But performance is  catastrophic on Nexus 7 2013 + Android
>> 5.1.1. I don't know if it's my implementation or a more generic bug.
>
> 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).




> 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,

Grégoire