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

Christian HJ Wiesner
2004-03-26T06:53:12Z

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.

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

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

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

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

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.


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

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

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

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 ?

3. What about a Theora en/decoder filter ?

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

Best regards

Christian