[FFmpeg-devel] Additional RTSP issues
Sat Jul 18 18:10:16 CEST 2009
On Sat, Jul 18, 2009 at 04:35:37PM +0200, Luca Barbato wrote:
> Michael Niedermayer wrote:
> > On Wed, Jul 15, 2009 at 10:41:38AM -0700, Baptiste Coudurier wrote:
> >> Hi,
> >> On 7/15/2009 12:06 AM, Luca Abeni wrote:
> >>> [...]
> >>>> Maybe just taking the first X correct timestamps, then approximate
> >>>> backwards
> >>>> for the non-stamped packets?
> >>> Well, after receiving the first RTCP SR (and having the first reliable
> >>> timestamp),
> >> What about discarding packets until RTCP SR is received ?
> >> It is streaming, user won't care about loosing a few frames at the
> >> beginning but will definitely prefer having correct timestamps, like
> >> this thread proves.
> > i agree the user likely wont care about loosing a few frames but the user
> > might care about extra delay, i mean something hypothetical like
> > "why does ffplay need 10sec before playback starts while barfoo starts
> > immedeatly ..."
> ffplay currently is the faster to come up with something to see most of
> the time... (since it does almost no buffering while others buffer some
> frame before actually playing)...
playing streams received over a network like the internet (compared to
something designed to guratee low latency low packet loss) requires
buffering so ffplay is not better in this respect. It just will freeze
as soon as a packet is delayed.
The only way i could see to reduce initial buffering delay would be
to receive data quicker than to play it so the buffer reaches a less
critical state quickly ..
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> ... defining _GNU_SOURCE...
For the love of all that is holy, and some that is not, don't do that.
-- Luca & Mans
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel