[theora-dev] My issues with ogg and directshow...

[Ralph Giles]

On Tue, May 11, 2004 at 08:40:53AM +0800, illiminable wrote:

> Because in any AV graph, the largest samples are giong to be the raw RGB or
> YUV coming out of a video decoder into a video renderer. These are of fairly
> predicatble size if you know the output format and frame size.

Hopefully so, though this souns like it's just an assumption DirectShow makes
that Ogg does not.

> Yes, kind of... but its a pain ! I have to keep track of the end time of
> previous passing pages and then maintain a local count of frames or samples
> processed since the last page granule pos. Which is no biggy for single
> stream... in fact it could (not ideally) ignore granule pos and just use
> it's own frame count.

Sounds like Aaron's suggestion of using native timestamps outside the
demux is a good one.

I guess using a page start time granulepos would help in your example?
Since the mux sees the whole page at once, can't it back-calculate from 
the contents and the end time? That would seem the easier possibility.

> > To clarify here, it's my understanding that format parameter lookup is a
> > feature of the AVI and ogm container formats (and asf, presumedly) not of
> > any of the specific codecs. Is this correct?
> 
> Yes... sorry container format not codec.

Ok, thanks.

> As i mentioned in the email reply a few minutes ago, this is all fine if you
> accept that every time you have a new codec, you need a new helper library.
> Doing the header parse itself is not a big deal, it's not that it's
> particularly difficult to wirte a helper library as a new codec is added,
> but from a practical point of view, this is not a good choice. Ideally you
> do it once and it works for all others (which ogm and avi do).

You're welcome to your opinion of course. Monty didn't do it that way, and
I like better the way Ogg works. But there's not much to be done about it
now.

> That's true, if you can't find an implementing .dll then it's no immediate
> help. But i don't see that this is a valid argument... in any container
> format, if you don't have the codec you can't play it, this holds true for
> all formats.
> 
> However if you have a GUID (globally unique identifer), you can
> automagically download it, install it and then you can play it.

This is a fair point. Of course, this would work within spec if you could
send the whole initial packet to the server and get back a pointer to an 
implementation. I won't hold my breath for MS to implement that, so your
demux needs to generate a mapping to FOURCCs or GUIDs for Ogg files. 
Presumedly anyone whose file won't play will contact you so you can support
their variant.

> At least if the header was null terminated or fixed size, this is not an
> issue andi don't see how that restriction imposes any great issues. Or in
> the reverse i don't see what advantage you get by having arbitrary
> identifiers. The whole purpose of the identifier is to identify, ideally
> uniquely. So why not enforce it rather than rely on people to *hopefully*
> create identifiers that don't cause conflicts. 

Does 4 bytes work for all the ogm variants? If so we can add that to the next
rev of the Ogg spec.

 -r
--- >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 'theora-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.