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

[Christian HJ Wiesner]

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

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