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

[Sebastian Dröge]

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?

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
-------------- 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-android/attachments/20140125/b2f556bf/attachment-0001.pgp>