Controlling cache or buffer length in RTSP H.264 live stream?

[Ricky Houghton]

On Sat, Jan 25, 2014 at 11:56 AM, Sebastian Dröge <sebastian at centricular.com
> wrote:

> On Fr, 2014-01-24 at 11:36 -0500, Ricky Houghton wrote:
> > As a follow up, I have determined that the program, Tutorial #4,l thinks
> > that the stream is "NOT LIVE", however it never hits the buffering_cb
> > function in tutorial-4.c, so this function is not responsible for the
> delay.
>
> Buffering only happens if the stream is not considered live, and for
> RTSP streams only if the complete duration is known. What's the case
> here?
>

The duration is unknown so I would assume there is no buffering - but there
is some somewhere.
(N.B. the function Tutorial 4 function buffering_cb is never called, so
there is no buffering happening here.)

The RTSP stream is coming from a hardware encoder running the TI DaVinci
8168. The particular
encoder is here: http://www.neyasystems.com/products/uxstreamer - they have
demonstrated 100ms
video to network in the past. (These guys are my friends.) Network latency
is single digit millisecond as the units are sitting
on an isolated AP, encoder hardwired, Nexus 7 is only wireless device.

I have continued playing/exploring and I stumbled upon

g_object_get (data->pipeline, "buffer-duration", &bufdur,NULL);
g_object_get(data->pipeline, "buffer-size", &bufsize,NULL);

Are these two values relevant, even if local buffering (in Tutorial 4) is
not being used?

Can you point me to how I can control the rtspsrc buffer? I am using
Tutorial 4 and have access to the
pipeline etc, but not exactly clear how to access the rtspsrc filter and
how I might set the parameters for the buffering?
I can RTFM, however I don't fully understand the connection of the Android
world and the GStreamer world via the NDK.

I am software dev, but mostly embedded and mostly C/C++. - If there is an
example somewhere on how to reach into the
rtspsrc and which parameters I could adjust to likely pull the pieces
together.

Thanks for your time,

Ricky





>
> Some more comments below
>
> > On Thu, Jan 23, 2014 at 9:15 PM, Ricky Houghton <
> ricky.houghton at gmail.com>wrote:
> >
> > > I was able to successfully compile and run the tutorials on my Nexus 7
> > > device. (Thanks to all who made this possible.)
> > >
> > > I modified the code for Android Tutorial #4 slightly to serve up a live
> > > stream from a H.264 device serving up a RTSP stream. The video displays
> > > correctly and everything works nicely. I've left it running for more
> than
> > > an hour with no issue.
> > >
> > > However there is a constant delay of about 4 to 5 seconds on the video
> > > stream. I've used Bing and Google to search for an answer, but can't
> seem
> > > to find which buffer/cache variable might contribute to the delay. (The
> > > code appears to ignore buffering if the stream is live, but there is
> > > clearly some buffering underneath that is creating this delay)
> > >
> > > Please note, the delay is constant over the hour, so I'm pretty sure
> the
> > > decoder is able to keep up - and the latency/delay doesn't increase
> which
> > > lends me to believe there is a buffer/cache value that is set rather
> high.
>
> There's a latency property on rtspsrc which by default is 2000
> milliseconds. So you automatically have a delay of 2 seconds added there
> already. You can try to lower the latency but how low it can go depends
> on your network conditions.
>
> Apart from that there is probably also some delay caused by the encoder
> (x264enc by default has a delay of 3 seconds for example, which encoder
> do you use here?)... and of course the network.
>
> > > Thanks,
> > >
> > > Ricky
> > >
> > > btw, when the application starts, I do receive a few messages similar
> to
> > > this one, however they quickly disappear once the video stream
> synchronizes
> > > and stabilizes. It normally takes about 3 or 4 seconds for this, then
> > > everything is fine. I do not see this message again, no matter how
> long I
> > > run the encoder.
> > >
> > >  01-23 21:10:54.550: W/GStreamer+amcvideodec(2319): 0:00:28.046864000
> > > 0x69d96860
> > >
> gstamcvideodec.c:1025:gst_amc_video_dec_loop:<amcvideodec-omxnvidiah264decode0>
> > > Frame is too late, dropping (deadline 0:00:00.194772226)
>
> That would mean that in the beginning decoding happens a bit too slow.
> If you lower the latency on rtspsrc it will happen more often in the
> beginning probably.
>
> This could be because the nvidia hardware decoder also introduces some
> delay but does not advertise it (and we have no way to know it
> unfortunately because the Android APIs don't expose that).
>
> --
> Sebastian Dröge, Centricular Ltd - http://www.centricular.com
> Expertise, Straight from the Source
>
> _______________________________________________
> gstreamer-android mailing list
> gstreamer-android at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-android
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-android/attachments/20140125/43f25199/attachment.html>