[vorbis] tarkin (was Re: FREE at last)

[David Balazic]

Kenneth Arnold (ken at arnoldnet.net) wrote :
> On Mon, Oct 09, 2000 at 02:46:57PM -0700, Ralph Giles wrote:

> > Re minimal facilities, all the compressed stream can really do is provide 
> > timestamps (or ranges). It's easy enough to keep track of exactly where  
> > you are in the decoder (libvorbis provides sample-accurate seeking, for 
> > example).

What about sub-sample-accurate seeking ? ( that is not really seeking
any more, is it ? )
In certain surround sound setups the timings are very important
and only one-sample steps may not be enough.

> > In the trivial implementation, it's just a matter of lining up 
> > the numbers. 
> 
> Right... more pains in decoders' butts. Ah well, I guess we're going to 
> have to live with it. It's not like there's much better, other than    
> SMTPE-timecoding the whole system (which I think should be done possibly
> as metadata, because it's possible that the video should interface with
> systems that use SMTPE (e.g., broadcast).
>
> > A more sophisticated approach is to write some sort of scheduler that    
> > works to (1) keep the audio buffer full (2) display video and text frames  
> > at the appropriate time (3) issue packets to the various decoders so the 
> > above can happen as smoothly as possible given available system resources. 
> 
> True: some smarts there can get the same result.
>      
> > Some suggested heuristics: 
> > 
> > maintaining audio is the most important thing. drop video frames as 
> > necessary down to 1-per-5-seconds or so. then drop audio. 
> 
> But what about inter-frame coding? Wouldn't this totally mess up the 3d
> wavelets?

Is this about "keep audio and video ( and others ) in sync" or
"what to do if the CPU can't decode in real time" ?

Why would this mess up the wavelets ? The wavelet decoder spits out
the frames which are displayed or maybe not displayed. It is of no
concern
of the decoder engine.
 
> > Text (closed captions/subtitles) is better run 'fast-forward' or displayed 
> > in aggregate than dropped. 
> yes.
>      

Same for video. Speeding up and slowing down video is trivial, unless
you are running in sync with the hardware framerate ( which you aren't
on any display over 70 Hz of vertical sync ).
If you're outputting to a TV then you may have problems , but there
are solutions ( PAL on NTSC VCR's and DVD players use them for example )
 


-- 
David Balazic
--------------
"Be excellent to each other." - Bill & Ted
- - - - - - - - - - - - - - - - - - - - - -

--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to 'vorbis-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.