[vorbis-dev] Re: New Directshow filters preview...

[illiminable]

----- Original Message ----- 
From: "Christian HJ Wiesner" <chris at matroska.org>
To: "illiminable" <ogg at illiminable.com>
Cc: <vorbis-dev at xiph.org>; <toff at corecodec.com>; <gabest at matroska.org>;
<haali at matroska.org>; <robux4 at matroska.org>; <mosu at matroska.org>;
<jcsston at matroska.org>
Sent: Friday, March 26, 2004 10:53 PM
Subject: [vorbis-dev] Re: New Directshow filters preview...

<p>>
> Hi,
>
> me again with some comments ( find below ) :
>
> illiminable wrote:
>
> >Comments inline...
> >
> >
> >> Did anybody point you to CoreVorbis already ?
> >>
> >>http://corevorbis.corecodec.org . I also wonder why you didnt modify
> >>Tobias Waldvogel's existing, and well working, filters, but decided to
> >>
> >>
> >Firstly because i have my own demuxer which is far more intuitive to use
> >than libogg in an OO framework.
> >
> It will be hard, if not impossible, for the Xiph people to add your
> filters to the official Xiph CVS if you dont make them based on
> libogg/libvorbis ? How could they maintain your code if you cant care
> about it anymore ? Not that i am involved here, its just a remark.
>

That's not really my primary concern... i'm doing it because i enjoy it, and
because i'm enjoying learning about the codecs and directshow. It will be up
to xiph if they want to give it some official "stamp of approval" or not.
Either way i'll still be developing them because i have other uses for them.
If they want to rip out my demux and put their own in, i can't stop them.
I'm just interested in providing support for the codecs under windows in the
best way i can.

I would have thought it couldn't hurt to have another implementation of
libogg... not everyone likes C you know :)

> For my understanding, did you code the Ogg demuxer from scratch, or
> based on some exising code from another project like FFMPEG ?
>

No the demuxer was written totally from scratch. It's a pretty simple demux
process anyway.

It operates in three main modes.
1) Feed and Call (what use with virtual interface dispatching)
2) Pull and Pull
3) Feed and Pull

Theres also a few dump tools i have which will go in in a release or two
once they get some error checking in them :)

> >secondly because i put a lot of effort into abstracting away all the
> >difficulties of directshow... for example... i have an abstractaudiocodec
> >class...
> >========================================================
> >snip
> >========================================================
> >
> >Both my speex and vorbis filter (and my soon to be finished FLAC filter)
> >derive from this common base class.
> >
> >
> This sounds like a great idea, and Toff and jcsston made something
> similar when doing CoreAAC, CoreFLAC and CoreVorbis IIRC. Looking
> forward to more filters from you .....
>

Heh... never know i might write a matroska demux too :) It sounds
interesting !

> >One of the reasons IMO that there aren't more directshow filters around
is
> >becuase they can be a real pain to write... my goal is that by providing
an
> >abstract class which does all the administrative work for you and you can
> >fill in the blanks with the important codec stuff. I've even been toying
> >with the idea of a code generation wizard to make most of the codec
classes
> >too. Just as an example... (and granted they are incomlpete)... the speex
and
> >vorbis filters are each less than 500 LOC.
> >
> >
> Yeah, DirectShow filters can be tricky, we can sing a song here .....

I've been singing some songs alright :) They may not be fit for the radio
though !

>
> >They also use libfishsound as an abstraction to vorbis/speex. Again i
find
> >this much easier to use and more intuitive than using libvorbis
directly...
> >
> >
> ... ACK, but this may prevent the adoption of your code as official
> DShow filters by Xiph, as stated above
>
> >Another reason is i intend to release source as BSD... i believe your
vorbis
> >filters are GPL ? But that's a different issue.
> >
> >
> Really, for a DShow filter the license of the sourcecode is not so
> important IMO. The compiled plugin itself can easily be used by any
> closed source player, because thats what the plugin idea is about. The
> app calls DirectShow, which is a part of the OS itself and as such
> covered by the OS exception of the GNU, and DShow itself will call the
> filter and build the playback graph, so the app itself doesnt really
> interface with the filter and is not restricted by any license
> contraints if the filter is opensource, while the app ( player, capture
> program, whatever ) is not.
>

That's a good point...

> We originally made all the DirectShow filters on corecodec GPL because
> they were using some classes from another filter, which was released
> under the GPL itself. Those classes have been rewritten over time, and
> we added QPL as 2nd license, in case any commercial companies would be
> interested to distribute the filter in their package ( there werent ;-)
> ), against some form of compensation like a donation to corecodec or
> whatever.
>
> For Xiph it makes a lot of sense to release everything they do under
> BSD, to help the spreading of the format itself, and even in commercial
> packages and without receiving any compensation for that. IMO they
> should be more interested in a proper DShow implementation of their
> stuff, but thats really just IMO. Please announce here if you have any
> working encoder filters for Speex in combination with a Ogg muxer that
> can connect to it, i know there are a couple of apps which could be
> really interested in this. Christian Buchners ACM codec can not really
> act as a full substitute here, as the result of the ACM codec will
> always be a WAV or an ( async ) AVI, and not a valid Ogg Speex file.
>

The ogg muxer and encoders for speex and vorbis are not too far away... the
speex and vorbis encoders at least i could knock up in a day or so. At the
moment i'm debugging a FLAC decoder... that's taken a bit of fiddling... as
it wants use readCallbacks to get it's data... and thats not really going to
gel with directshow. Though Josh did give me a tip on how to work around
that which looks like it's going to work.

>
> >>rewrite them completely, and even using an inderior approach by
> >>including the source filter into the decoder filter ( which is clearly
> >>against the standard DirectShow approach BTW ) ?
> >>
> >Maybe you misubderstand my approach... the source is a demux not a
> >decoder... the audio codecs are not part of the source filter (that would
be
> >silly !!).
> >
> >
> Great, so i misunderstood :-) !!
>
> >Also it's not against the directshow standard... look at the WMV Demux
> >Source filters or the WAVE source filter. There are very good reasons for
> >making a demux a source to have greater control over the file source. I
> >originally did it the source->demux->codec->render way, but it was a real
> >pain in the ass ! CPullPin was not my friend :)
> >
> >
> We originally had timing problems when calling Tobias' Vorbis decoder
> filter from the matroska demuxer, but IIRC this was more a problems with
> Tobias decoder ignoring DShow's timestamps completely, and not a push -
> pull conflict. These timing problems were more or less forcing us to
> make CoreVorbis ( Toff really made an excellent job here ), i wonder how
> your decoders will deal with it ?
>

Hmmm... we'll have to see :) If it doesn't work i'll happily change it !!

> >>We could have used your Speex decoder filter to play Speex from matroska
> >>container, but right now its unusable for us as it is.
> >>
> >>
> >No it isn't ! Have you even tried ? Load it into graphedit and check it
out
> >yourself.
> >
> >
> No, i didnt try it, i cant because we have no means to mux Speex into
> MKV right now. If your Ogg demuxer works for Ogg Speex files, we can try
> to connect with the MEDIASUBTYPE you defined for it and define a new
> matroska codec ID like 'A_Speex' , the adaption work should be quite
> trivial i guess.
>

Yes the demuxer does work for speex... it spits out data as one ogg packet =
one directshow sample.

Though i'd hold off on that for now... The next release the vorbis and speex
filters have been split... and for now it'd probably pay to wait a little
longer... who knows what i'll change or what i've broken :)

> >>No offense, i just will never understand why developers tend to rewrite
> >>stuff completely, instead of taking other people's existing code ....
> >>
> >>
> >And no offense to anyone elses code... but sometimes projects get
modified
> >to do tasks they weren't really designed for. Often it is much cleaner to
> >start a fresh with a clearer goal and the benefit of experience.
> >And yes as i just noticed Andre pointed out, all the other filters are
> >tightly coupled to libogg/libvorbis.
> >Zen/
> >
> ACK ......
>
> Some more question :
>
> 1. What GUIDs did you choose for Vorbis and FLAC ? What would you think
> of using the same GUID as CoreVorbis and CoreFLAC, or OggDS ? anything
> voting against that ?
>

I chose new ones... primarily because i didn't want there to be conflicts
with other filters trying to connect if they were only designed to work with
their own filter set. Because that just provides confusion for end users
when they install them and they don't work because another filter is
stealing the connections.

That said, i do think it would be a good idea for the various people working
on DS stuff for xiph codecs to come to some agreement on standardising the
GUID's for media types at least.

A properly imlpemented filter should only accept a conection if the three
params match mediatype, mediasubtype and format. Though it's not
inconceivable that in the future (or possibly already) people may implement
filters that only connect based on the first two. This would be bad !

So if there does become a common GUID for the mediatypes we need some way to
make sure that people don't implement filters with them unless they
negotiate connections correctly.

As for the format GUID... that may be more tricky...

However i would prefer the approach of just supporting multiple
mediasubtypes/format blocks in my demux/codecs. This way they only connect
to other filters that are known to interoperate... and i feel this is the
best approach. Basicly i'd test filters together if they work and i can do
an appropriate translation i have no problem to make it accept their
conenction

It's not that hard to accept/offer either my GUIDs or some other ones... and
even to do a format block translation if the other filter wants a different
format.

> 2. Are you planning to support VCM/ACM tracks in Ogg one day ( = OGM ),
> or will your filters be focussing on the official Xiph specs ?
>

I'm focussed on whatever end users will want. If end users are interested in
it, i'll imlpement it. Though i have to say that getting the core spec done
first is more important.

> 3. What about a Theora en/decoder filter ?
>

The decoder is in progress... slowly i might add... i started... then i
looked at FLAC and it looked much easier so i did that first. :) FLAC has a
C++ api :)

Also i don't know buggar all about theora :) Well to be honest i know pretty
much buggar all about the internals of the other codecs too... i just know
how to munch bits :) Theora neesd me to sit down and and have a good look at
it.. whereas FLAC i already have the abstractaudiodecoder class which did
95% of the work. Though it will mean i'll end up with an
abstractVideoDecoder class too :)

> 4. Gabest has made his own Ogg demuxer code for his great Mediaplayer
> Classic ( http://sf.net/projects/guliverkli ) recently, but couldnt
> finish it, due to time constraints. This is just a pointer to another
> project doing something similar, i thought i let you know ....
>

Thanks i may have a look but my demuxer is pretty stable now... the muxer
still needs some work.

Cheers,
Zen.

> Best regards
>
> Christian
>
>
>
> --- >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.
>
>
>

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