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

Kenneth Arnold ken at arnoldnet.net
Tue Oct 10 07:05:45 PDT 2000



On Mon, Oct 09, 2000 at 05:42:48PM -0700, Ralph Giles wrote:
> On Mon, 9 Oct 2000, Kenneth Arnold wrote:
> 
> > > What's MLP?
> > 
> > Read K5? Mindless Link Propogation.
> 
> You make it sound like bad thing!

That's why I prepended a NS == "not so" to it.

Anyway, it was Gregory Maxwell in that particular case.

> > Best left in hardware, huh? So what about me playing moviez at home with
> > nothing more than my run-of-the-mill graphics card?
> > 
> > > 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). 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).
> 
> What's so magical about SMTPE? 0:0:23:27 <-> frame 717; isn't it all the
> same to the decoder?

It's not magic; I don't know how Ogg does timestamping, but it should be able
to interface exactly (i.e. same precision) as stuff that speaks SMTPE.

> > > 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?
> 
> Er, right. I was thinking about mpeg-1/2, where you can easily decide not
> to decode B (or even P) frames in advance to catch up. I imagine there
> will be analogous options: not inverting the transform for some slices,
> dropping 'scalable' packets, that sort of thing. On some systems, just
> color-converting/blitting the frame is significant.

Ah, right. e.g. not updating one frame would put less load on the X server
(if not direct rendering), or you wouldn't need to scale the frame to fit the
screen. Okay, I see.

>  -r


-- 
Kenneth Arnold <ken at arnoldnet.net>
Proudly registered Linux user #180115! See http://counter.li.org/
GCM/CS/E/IT/M/S d?(-)(pu) s:-(:--) a15>? C++(+++) UL+++ P+ L++ E W++(+)
N? o? K? w--(-) O? M+ V? PS+(++) PE+ Y+ PGP- t+ 5? X? R? tv-(--) b+ DI
D G e- h! !r !y

--- >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-dev-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.




More information about the Vorbis-dev mailing list