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

[illiminable]

----- Original Message ----- 
From: "ChristianHJW" <christian at matroska.org>
To: <vorbis-dev at xiph.org>; <ogg at illiminable.com>
Sent: Friday, March 26, 2004 6:04 AM
Subject: Re: New Directshow filters preview...

<p>> illiminable wrote:
> > Comments inline...
> >>Does DirectShow not have support for a separate demux plugin between the
> >>source and decoders? (I don't know anything about it) Seems like taking
> >>advantage of the graph would make your plugins more flexible in the
> >>future.
> >
> > 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

Firstly because i have my own demuxer which is far more intuitive to use
than libogg in an OO framework.

Secondly because i put a lot of effort into abstracting away all the
difficulties of directshow... for example... i have an abstractaudiocodec
class...
========================================================
Filter:
//PURE VIRTUALS
virtual bool ConstructPins() = 0;

Input Pin:
 //PURE VIRTUALS
 virtual long decodeData(unsigned char* inBuf, long inNumBytes) = 0;
 virtual bool ConstructCodec() = 0;
 virtual void DestroyCodec() = 0;

Output Pin:
 //PURE VIRTUALS
 virtual bool FillWaveFormatExBuffer(WAVEFORMATEX* inFormatBuffer) = 0;
========================================================

Both my speex and vorbis filter (and my soon to be finished FLAC filter)
derive from this common base class.

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.

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

Another reason is i intend to release source as BSD... i believe your vorbis
filters are GPL ? But that's a different issue.

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

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

// {25A9729D-12F6-420e-BD53-1D631DC217DF}
DEFINE_GUID(MEDIASUBTYPE_Speex,
0x25a9729d, 0x12f6, 0x420e, 0xbd, 0x53, 0x1d, 0x63, 0x1d, 0xc2, 0x17, 0xdf);

// {78701A27-EFB5-4157-9553-38A7854E3E81}
DEFINE_GUID(FORMAT_Speex,
0x78701a27, 0xefb5, 0x4157, 0x95, 0x53, 0x38, 0xa7, 0x85, 0x4e, 0x3e, 0x81);

truct sSpeexFormatBlock {
 unsigned long speexVersion;
 unsigned long samplesPerSec;
 unsigned long minBitsPerSec;
 unsigned long avgBitsPerSec;
 unsigned long maxBitsPerSec;
 unsigned long numChannels;
};

At this stage only samplespersec and numchannels are taken any notice of and
this was similar to my vorbis format block... it is likely to be changed by
the time i release.

One of the reasons i have not released the source yet, is that i haven't
stabilised how the apis and formats will be... so if you use it now, it's
possible it will break before i release source.

As a lot of the work is in providing a consist framework for implementing
demuxers and codec... i want to get it well sorted before release... if i
think somethings not right i can just change it without worrying about
breaking everyones code and having to retain compatability.

>
> 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/
> Christian
>
>
>
>

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