decreasing video playback start time

[Sebastian Dröge]

On Fri, 2016-09-30 at 09:23 -0500, Bryan Noll wrote:
> GStreamer version is 1.9.2 (downloaded and extracted via the
> universal binaries).
> 
> I'm playing a 640x480 MJPEG stream being made available over http on
> a local wireless network. The stream I'm consuming and playing on the
> Android device is also being produced by GStreamer. I've been told
> that the mjpeg stream is 30 frames per second, if that's meaningful
> at all.
> 
> The hardware I'm trying to play it on is primarily an Android Samsung
> Tablet with model number SM-T550 (I assume you're asking about the
> device I'm trying to play it on not the device where it's being
> produced). 
> 
> > Is it using the hardware codecs?

For MJPEG it is using software codecs, we don't support JPEG decoding
via hardware on Android (yet).

> I'm not using a customized pipeline of any kind yet, but was
> wondering if this was the direction I needed to start going. In terms
> of hardware accelerated codecs, if you're talking about the kind of
> thing documented here http://docs.gstreamer.com/display/GstSDK/Playba
> ck+tutorial+8%3A+Hardware-accelerated+video+decoding (not sure if
> that documentation is even legit at this point) then I can definitely
> say that I am not using `gst_plugin_feature_set_rank` to set the rank
> of particular plugins. If I'm not even answering your question
> appropriately, I'm happy to check if you could let me know how.
> 
> The delay I'm interested in reducing is from the moment I call
> `gst_element_set_state (data->pipeline, GST_STATE_PLAYING);` to the
> moment that the underlying state actually changes to
> GST_STATE_PLAYING (which correlates with the video visually playing
> on the screen).
> 
> The playback once the video starts is performing well, with very low
> latency. As another data point, if we navigate to the same MJPEG url
> in Chrome on the same Android device, the playback begins basically
> instantly (sub 1 second). 
> 
> I'm sure the difference is something I'm doing incorrectly or
> inefficiently and not GStreamer itself. Again, appreciate any help.

Using a custom pipeline should not be needed, but it would make sense
to do some profiling to see where all the time is spent.

If your get_state() there blocks for 5s, that means that something
between setting the state and the first decoded frame reaching the sink
takes 5s. We would have to know what exactly it is, and then can
consider optimizing that.

-- 
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: 931 bytes
Desc: This is a digitally signed message part
URL: <https://lists.freedesktop.org/archives/gstreamer-android/attachments/20161003/bcbb1e84/attachment.sig>