[gst-devel] totem and osssink? (long)

[Thomas Vander Stichele]

On Thu, 2004-03-11 at 20:45, Ronald Bultje wrote:
> Hi,
> 
> On Thu, 11 Mar 2004, Thomas Vander Stichele wrote:
> > - first few buffers arrive at audiosink with timestamp 0, but audiosink
> > is already beyond that point, and drops all those buffers
> >
> > The end result here is that the start of a song got dropped because the
> > clock is running before data is flowing.
> > (Correct me if I read any of the source wrong in this regard).
> 
> No. The audio only starts running when data first comes in. Dropping audio
> data is wrong either way. Assume the 100% CPU use case, where data
> *always* comes in too late. We *can not* drop incoming buffers. If we do,
> we *know* next buffers also come in too late. Hey, where's my audio?

I'm not describing how I think it should work, I'm describing how it
worked before Benjamin's changes.

Other than that, I don't agree that it's wrong to drop audio data
necessarily.  An audiosink should try to make the best effort possible
to not drop audio, allowing for stretching if necessary, or allowing for
minor variations in time of arrival.  In the case of 100% CPU use, there
are two possibilities.  Either something is maxing out the processor,
leaving GStreamer "just enough" CPU to decode and playback, and audio is
arriving only slightly late.  If it's only playing audio, it's probably
fine to keep playing, and adjust for it somehow.  If it's playing video,
however, it may still be correct to drop audio to keep up with video. 
It all depends.

OTOH, if the CPU just cannot cope with decoding both, what should it do
? Play audio and stop showing video ?

Thomas


Dave/Dina : future TV today ! - http://www.davedina.org/
<-*- thomas (dot) apestaart (dot) org -*->
You are going to get every square inch of your ass kicked.
<-*- thomas (at) apestaart (dot) org -*->
URGent, best radio on the net - 24/7 ! - http://urgent.fm/