Android 6.0 gstreamer 1.0: frame is not writable

Gregoire Gentil gregoire at gentil.com
Sat Dec 5 18:18:22 PST 2015



On 12/01/2015 12:35 AM, Sebastian Dröge wrote:
> On Do, 2015-11-26 at 11:11 -0800, Gregoire Gentil wrote:
>>
>> On 11/25/2015 11:41 PM, Gregoire Gentil wrote:
>>>
>>>
>>> On 11/25/2015 07:43 PM, Sebastian Dröge wrote:
>>>> On Mi, 2015-11-25 at 12:40 -0800, Gregoire Gentil wrote:
>>>>> Hello,
>>>>>
>>>>> Do understand that the same code is working on Nexus 7 2013
>>>>> running
>>>>> Android 5.1.1.
>>>>>
>>>>> To answer precisely your question, I do:
>>>>>
>>>>> playbin uri=... video-sink="... ! glimagesink"
>>>>>
>>>>> video_sink = gst_bin_get_by_interface(GST_BIN(bin),
>>>>> GST_TYPE_VIDEO_OVERLAY);
>>>>> GstPad *pad = gst_element_get_static_pad(video_sink, "sink");
>>>>> gst_pad_add_probe(pad, GST_PAD_PROBE_TYPE_BUFFER,
>>>>> (GstPadProbeCallback)cb, NULL, NULL);
>>>>
>>>> You need to provide some more details about your pipeline here,
>>>> what
>>>> are those dots exactly and what kind of media file are you
>>>> playing?
>>>>
>>>> Did you also check that the same decoder (or at least another
>>>> amcvideodec-* decoder) is used in both cases? Which version of
>>>> GStreamer are you using, 1.6.1 or something else?
>>> On Android 6.0, it seems to be working with 1.6.1 + ndk-r10e (not
>>> r9
>>> which prevents from compiling) but then the performance becomes
>>> catastrophic on Android 5.1.1,
>>>
>>> Grégoire
>>>
>> For the records, the problem is that on Android 6.0, the system was
>> using software decoding and the buffer going out of the decoder are
>> not writable while on Android 5.1.1, the system was using hardware
>> decoding and the buffer is writable. The problem boils down to make
>> work hardware decoding on Android 6.0 which works with Gstreamer
>> latest 1.6.1 while it's not with 1.5.0. But 1.6.1 on Android 5.1.1
>> has catastrophic performance...
>
> Can you provide a clear list of observations? Which versions of
> GStreamer and the NDK are working on which Android version, and which
> codecs are being used then?
> Also what are the devices you're testing on?
>
> Once you did that, it might make sense to file a bug at
>    https://bugzilla.gnome.org/enter_bug.cgi?product=GStreamer
> but let's wait with that until we have a better overview of what goes
> wrong.
>
> Also debug logs with "2,amc*:6" would be good to have for all the
> cases.
>
Findings:
Nexus 7 2013 + Android 5.1.1 + gstreamer 1.5.0-git + NDK-r9 + h264: All 
working, decode in hardware, buffer in sink pad is writable.

Nexus 5x + Android 6.0 + gstreamer 1.5.0-git + NDK-r9 + h264: Decode in 
software, buffer in sink pad is NOT writable.

Android 5.1.1 + gstreamer 1.6.0 + NDK-r9: Not compiling.

Nexus 5x + Android 6.0 + gstreamer 1.6.0 + NDK-r10e + h264: All working, 
decode in hardware, buffer in sink pad is writable.

Nexus 7 2013 + Android 5.1.1 + gstreamer 1.6.0 + NDK-r10e + h264: Decode 
in hardware, buffer in sink pad is writable, performance is catastrophic.



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.

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

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


Right now, I'm back to gstreamer 1.5.0-git + NDK-r9, with 
gst_buffer_make_writable. At least, it works well everywhere though on 
Nexus 5x + Android 6.0, it doesn't decode in hardware and I have one or 
two additional memcpy, but the SnapDragon 808 is powerful enough.



Next step:
If someone has "some spare time", it would be interesting to test 
playbin of gstreamer 1.6.0 + NDK-r10e on Android 5.1.1 to see if the 
stack (especially the hardware decoding), works well,

Grégoire


More information about the gstreamer-devel mailing list