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

[illiminable]

----- Original Message -----
From: "Ralph Giles" <giles at xiph.org>
To: <theora-dev at xiph.org>
Sent: Tuesday, May 11, 2004 9:08 AM
Subject: Re: [theora-dev] My issues with ogg and directshow...

<p>> 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.
>
You can specificy different buffer sizes for each pin connection.. so the
connection from the video decode output to the video render input has the
largest sized buffer, but the sizes of the other buffers don't have to be
that large. The buffer size is negotiated between the two filters... if a
particular filter asks for a bigger buffer it will generally get it.

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

Yeah... i wanted to do that originally, the reason i didn't is that some of
the decoders still need a granule pos... i think theora and flac from
memory... vorbis and speex just ignore the granule pos field in teh packet
anyway. Which just meant converting back to granule pos straight away.

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

It can... but only the demux sees the whole page, the decoder doesn't know
where the page boundaries lie. And the demux can't just send the decoder
filter a page full of data and say... don't pass this on, just see how big
it is then get back to me. Which would probably mean the demuxer would have
to do this, which means the demuxer also has to know how to decode each
codec too, or at least call out of directshow to decode it. Honestly it's
probably easier to just keep seeking back to find a previous page.

ie the demux gets a page with 10 packets... even if the decoder could
identify the page end at 10 packets, by the time the decoder sees the 10th
packet, the first packet has already been sent for rendering and have with
no timestamp.

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

If xiph wants to set up such a system on their server such that i can send
it a packet and it will tell me where to download and install a codec from,
it's probably possible with no intervention from microsoft. But that forces
the issue of remote intervention rather than making it a last resort.

With a GUID, you can do it locally if possible. Lets say someone is mucking
around with new format that's not complete. With a guid mapping they can
happily let it work on their local system, without changing the demuxer.
With remote identification the demuxer won't recognise it, and the xiph
server won't have heard of it.

But it's definately a reasonable compromise. But it also means that xiph can
effectively disallow a codec by not putting an identifier on the system,
that could be a good or a bad thing.

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

OGM uses 8 byte major type identifiers and 4 byte fourcc minor type
identifiers... but as far as  i know all the 8 byte major types in use are
unique in their first four bytes.

\000video\000\000\000 , \000audio\000\000\000 and a couple of others i can't
think of i think text and image padded out with nulls.

Zen.

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

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