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

[ozone at algorithm.com.au]

On 26/03/2004, at 9:04 AM, ChristianHJW wrote:

> illiminable wrote:
>> Yes it does... but as i mentioned there were significant problems i 
>> found
>> with this approach because it means you have the link between the 
>> source and
>> the demux as being a  pull model and then all the downstream filters 
>> being a
>> push model. In particular when it comes to seeking in ogg, this 
>> turned out
>> to be a lot more difficult to implement using the "Demux as transform
>> filter" approach. Also... the source filters have forced alignments 
>> of 512
>> bytes, which causes you to have to included all kind of offset 
>> corrections
>> all through the code to account for.
>
> 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 
> 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 ) ?
>
> No offense, i just will never understand why developers tend to 
> rewrite stuff completely, instead of taking other people's existing 
> code ....

As one of the people who helped illiminable write his Windows 
DirectShow Ogg Vorbis filters, I hope I can answer some of your 
concerns:

1.  We didn't know about the existence of the DirectShow filters at 
CoreCodec.org :).  That said, there are two other good reasons ...

2.  The source filter that we are referring to only concerns the Ogg 
filter: unlike many other filters, we have separate filters for the Ogg 
demuxer and the Vorbis decoder.  This is a more extensible and better 
design than putting everything in the one filter: it makes it far 
easier to support any future codecs that xiph.org bring out.  e.g. 
Putting in support for Ogg FLAC will be trivial compared to extending 
one monolithic Ogg filter.  The eventual goal will be to have 
corresponding muxing and encoding filters, so that e.g. you can encode 
XviD in Ogg painlessly using a standard DirectShow filter graph.  While 
the current filters have problems, a lot of the heavy lifting work has 
been done, so now we have a better architecture to build on than what's 
provided by other existing DirectShow filters.

3.  Like many of the core xiph.org projects, our filters are 
BSD-licensed, and not GPL-licensed.  (This is important for some 
people, since I personally plan to use these filters in contexts 
outside of open-source projects.)  I don't want to get into a license 
war, I just wish to point out that the difference in licensing may be 
the deciding factor for some users.

> We could have used your Speex decoder filter to play Speex from 
> matroska container, but right now its unusable for us as it is.

As I mentioned above, one of the ideas of the design of illiminable's 
filters is to be able to play Speex no matter what file it is contained 
in -- if you are having trouble playing Speex in Matroska, please send 
him (or myself) feedback, so that we can work things out.  (I should 
also point out that the behaviour you want would be much harder to 
obtain from the filters hosted at CoreCodec.org, due to their tighter 
coupling with Ogg.)

<p>
-- 
% Andre Pang : trust.in.love.to.save
--- >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.