Request: Help with MCF-CD DShow filter [Archive]

DeXT

22nd April 2002, 21:22

Hi again. I think most of you already know what's the MCF-CD project about, and the benefit this may bring for all the community. This post is focused at the Developers, specifically those with some DirectShow programming knowledge.

The MCF-CD is a reality. The only problem is, for it to be usable, a special DirectShow filter must be developed. This is needed because of the way Windows access M2F2 discs. It adds a RIFF/CDXA header to every file written this way and reads the file in RAW mode.

Althought this may sound complex, for anyone with minimal DS programming skills this is a very simple task. What we need is a File Source filter, or a Transform filter, that is able to bypass all this extra data and pass the useful data only to the next filter in the chain. This task is as simple as:

a) From the beggining of the file, discard the first 44 bytes (the RIFF header).
b) From here up to the end of the file, pass 2324 bytes of data out of every 2352 bytes in the file to the next filter. Each sector has the following structure:

struct sector {
char header[24];
char userdata[2324];
char edc[4];
}

What wee need is the userdata[] block only, the rest is discarded. This filter would only be used with movies because any other file would be written in Form1, which don't need any additional work.

As you can see, this is very simple. We (avih & me) have been playing with some sample DShow filters but seems we just don't have the skills to do such a thing. So any help on this matter would be greatly appreciated.

The main problems I currently have is:

¿How to implement a simple TransformFilter-based filter? (and NOT TransInPlaceFilter-based one as seen in the sample filters)

¿How do you know what amount of data is being requested from the next filter in the graph? So you can read the needed sectors from the file and pass the user data only.

Thanks in advance.

Koepi

22nd April 2002, 21:34

I'm still a little reserved as it is called MCFCD.
I want to burn my OGG this way. So this format would be more or less EVCD (Enhanced [or Extended would suite as well] Video CD) instead of MCFCD.

Since not everybody is fixed and focused on MCF, you would get much more support if your focus wouldn't be just the one format that doesn't exist in "real world" yet.

Just my 2 cents,
Koepi

DeXT

22nd April 2002, 22:10

Hi again Koepi. Well MCF-CD is just a name. This is how it is known by the community. But MCF-CD is not subject in any way to a single format such as MCF, specially since MCF doesn't exist yet. I think I should have put this more clear.

Eventually, if I develop MCF-specific features for this format, I will split the project in two parts: one MCF-only and the other totally generic. Probably this would lead to a name change.

But anyways if changing the name is a condition for you or anyone else giving help to this, I will do it. If you prefer it to be called OGG-CD when coupled with OGG content, I have no problem with it, too. In fact as you know this is the first format likely to be supported with these CDs is OGG, since it's the most suitable one at this time.

But please help to make OGG-CD a reality! (as you seem very devoted to OGG :))

P.S: I don't like much this "EVCD" thing. I should seek for a better one.

avih

22nd April 2002, 22:12

i'm sure u're aware of it koepi, but maybe others aren't.

it's just the name that is 'specific' because it originated by mcf related developers.

however, this 'project' is completely general. the target is a dshow filter to parse files on the fly.
the files are stored as mode2 form 2 (this is already achieved, and we can burn 800M files to a cd). the only problem is that when openning the file in windows, we get extra information as de_xt described (the RIFF header is artificially generated by windows, the other extra data is raw data from the cd itself).

Gawen

22nd April 2002, 22:41

Hope this is not redundant, otherwise smile about silly me.

Did you check the source of Multiple_MPEG2_Source.ax ?
(A file reader ax, in nimo codec pack for instance.) Its
officially source only on http://fysx.acwu.com/Code/Code.html
and downloadable from Dooms Source page.

LIBRARY Multiple_MPEG2_Source.ax
DESCRIPTION 'I-Media Multiple MPEG2 Source Filter'

It should be able to show you what you asked for, or?

Koepi

22nd April 2002, 23:04

Hell, now you got me really wrong!

I just wanted to explain why there might be a lack of developer feedback.

As I wrote already, I'm stuck in some projects and can't afford the time to help in another one.

And: I'm not fixed on OGG. I just like it, it works, it is the best we have until now.

Until MCF becomes working reality it can take very long.

So don't misinterpret my lack of time with me not liking MCF.

Regards,
Koepi

int 21h

23rd April 2002, 05:10

Originally posted by Gawen
Hope this is not redundant, otherwise smile about silly me.

Did you check the source of Multiple_MPEG2_Source.ax ?
(A file reader ax, in nimo codec pack for instance.) Its
officially source only on http://fysx.acwu.com/Code/Code.html
and downloadable from Dooms Source page.

LIBRARY Multiple_MPEG2_Source.ax
DESCRIPTION 'I-Media Multiple MPEG2 Source Filter'

It should be able to show you what you asked for, or?

Nah, this isn't what they need. They need something that does some file parsing. Similar to the Mpeg-1 Demultiplexxer for Windows.

Neo Neko

23rd April 2002, 05:19

Nic has not put any visable time in on his AAC filter for a while and he has done such a good job on the Xvid filter maybey he might be a good person for this. I would jump on it in a heart beat if I could, but my programming knowledge tends to stear clear of OS specific issues. That and it is extreamly basic. ;)

Gawen

23rd April 2002, 06:25

@INT 21H
Silly, silly me,

and i thought the problem was reading a file stream from a M2F2 ISO layer 2 formated CD track, parsing the leading 44 RIFF/CDXA header bytes to a fitting DS output pin definition on file open, buffering the input data after stripping block header and EDC and sending data from the buffer to a DS output pin on demand of (for instance) the OGG DS splitter.

But i am shure you are right, its impossible. Demuxing must shurely happen bevore the OGG splitter. And silly me tought this was the demuxer. I am so sorry. :-)

P.S.: There is another, imho even better DS file reader source example in avienc 0.20 available from http://www.geocities.com/ej_999/avienc_src020.zip

ingoralfblum

23rd April 2002, 07:03

Originally posted by Koepi
I'm still a little reserved as it is called MCFCD.
I want to burn my OGG this way. So this format would be more or less EVCD (Enhanced [or Extended would suite as well] Video CD) instead of MCFCD.

Since not everybody is fixed and focused on MCF, you would get much more support if your focus wouldn't be just the one format that doesn't exist in "real world" yet.

I fully agree here. MCF-CD isn't a good choice for the name.

Regards,

Ingo

ingoralfblum

23rd April 2002, 07:09

struct sector {
char header[24];
char userdata[2324];
char edc[4];
}

Sorry for my unsuitable comment here. I don't know much about DirectShow, but don't do these

RIFFCDXAReaderFilter.hpp (http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/mediaxw/Src/MediaXW/AVI/RIFFCDXAReaderFilter.hpp?rev=1.1&content-type=text/vnd.viewcvs-markup)
RIFFCDXAReaderFilter.cpp (http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/mediaxw/Src/MediaXW/AVI/RIFFCDXAReaderFilter.cpp?rev=1.1&content-type=text/vnd.viewcvs-markup)

do exactly what you want. Perhaps they lack some functionality, but they should suffice at least for information purposes.

Kind regards,

Ingo

Gawen

23rd April 2002, 08:01

I don't know much about DirectShow, but don't do these ... do exactly what you want.

And i thought understatement was British, not German, Mr. Free Codec Pack. :cool:

oddball

23rd April 2002, 09:38

What is surprising me is the lack of takeup from any developers on making a DS filter for this format. Nobody appears to be leaping for the spec and trying to make one. I am sure everyone would love an extra 100 megs of available data on their 80 min CD-R's without sacrificing error protection (which should not be an issue with OGM etc). From what I have read it looks like it should be a simple enough task for anyone with DS filter programming knowledge. I may be wrong however as I cannot program to save my life (Well perhaps a little crappy basic) :)

Those last example files are from Ingo. Where can I find out more on what he is up to?

robUx4

23rd April 2002, 11:27

Yeah, the MCF dev team welcomes any skilled developpers to help us.

I'm also a bit disappointed to see that, even though many people are interrested in both our current projects (MCF and MCF-CD) we get more attention, but nobody working on it.

Hopefully this is an initial situation since everything is in alpha state. So when it becomes beta much more people will have access to it and might be willing to add their knowledge on it :)

As for the MCF-CD name, I don't think it's a problem. As it was created by the MCF-CD team. Maybe MCD (something like VCD) could be used. But, in my opinion, MCF still deserves credit for that :) (and mostly Tronic and Ingo)

DeXT

23rd April 2002, 11:48

@Gawen: thank you a lot for your help. I'm sure these sample filters will help us to understand a bit more how things works.

@Neko Neko: may God hear you... or is it Nic? ;)

@Ingo:
I fully agree here. MCF-CD isn't a good choice for the name.
surprisingly enough, since you are the "creator" of this format ;)

Anyways I think I should search a more-generic name, at least for the non-MCF related content. The problem is, it must be short and auto-explicative. CD/XA Bridge? Or just Mode2 CD? Or...
I don't know much about DirectShow
I assume you are just kidding here
but don't do these

RIFFCDXAReaderFilter.hpp
RIFFCDXAReaderFilter.cpp

do exactly what you want. Perhaps they lack some functionality, but they should suffice at least for information purposes.
Yes they should. The problem is, I can't understand a single line :) Seems this is part of a much larger project (with its own file reader and most DShow functions wrapped into your own ones -- at least this is how it appears to me). Anyways I wasn't able to make it work in its current form (sorry if I appear too dense; in fact I am :)). And since you said you were too busy to work on it I thought this was not suitable for us.

@oddball: Ingo's project is at http://mediaxw.sourceforge.net

ingoralfblum

23rd April 2002, 12:06

Yes they should. The problem is, I can't understand a line :) Seems this is part of a much larger project (with its own file reader and most DShow functions wrapped into your own ones -- at least this is how it appears to me). Anyways I wasn't able to make it work in its current form (sorry if I appear too dense; in fact I am :)). And since you said you were too busy to work on it I thought this was not suitable for us.

Yes it replaces the MS DirectShow classes and the MFC. The only thing that is much different is the media type negotiation. Since Nic is quite experienced with DirectShow, this shouldn't be the problem for him. Ask him if he can take a look at it.

The next thing is, that it uses the class ingo::InputStream for file access. First for the underlying file and second to expose the content to the base class. But this is exactly the same as the mcf::IOCallback. The next missing is the class for the registry key, but you can either copy it to the MCF library, because it should work the fine without many modifications, or you use another class. But the basic thing is that you create a filter with the IAsyncreader interface on the output pin. The current implementation reads the underlying file directly. Instead you should have an input pin, that connects to another IAsyncReader. This is simple. There's already a wrapper class that exposes a InputStream interface for a given IAsyncReader. So that probably takes about 20 lines.

Tip: You should use http://sf.net/projects/mediaxw instead.

Regards,

Ingo

Nic

23rd April 2002, 12:45

Ingo you're better than me at DShow :) I personally hate it, too much of a pain to debug :) but I always get asked to help with it.... :)

But this should be a relatively simple to do....Don't think I have the time right now though :(

I heard you'd given up a bit Ingo....I hope you'll be back coding with us soon/one day :)

Cheers,
-Nic

Koepi

23rd April 2002, 13:08

sorry for the off-topic again,

but:

robux,

this isn't about someone deserving the credits or anything like that. I dislike this "protektoristische scheuklappen" attitude (don't know any translation for that).
MCF-CD simply is a very special name that should forbid any further usage.
So even the name should be more generic.
That's what I'm talking about. Some OGG developers could be attracted as well as other DShow "gurus" if it wasn't for "MCF only".

I hope now the point gets a little clearer.

And Ingo, I too hope that you won't give up your efforts, I know how bad this work can be sometimes, but in the end there is some new, usable programs/codecs/... which do move/change things for the future.

Best regards,
Koepi

avih

23rd April 2002, 17:15

ok guys, 1st version of riff/cdxa is working.

sample usage:

0. register the filter asyncflt.ax (showed as 'Sample File Source (asynch)')
1. create a RIFF/CDXA cd image using de_xt's tool that is containing at least one mp3 file. (the tool is attached)
2. burn the image (or use deamon tools to mount it)
3. open graphedit, render a standard mp3 file from your HD.
4. insert the sample filter, select one of the AVSEQxx.DAT files from the cd (that was created from a mp3 file).
5. diconnect the original source file in the graph, and connect the output of the sample filter instead.
(you'll also have to reconnect the MPEG1 splitter output to the mp3 decoder).
6. press 'PLAY' :)

known issues: it won't work with avi or ogg files ... yet :), something to do with media types.
still have a lot of dshow stuff to learn. any help is welcome.

the only modified file from the sdk sample if asyncflt.h, which is attached.

the source and compiled filter + de_xt tool are attached. hope a moderator will approve it soon.

:)
avi

Gawen

23rd April 2002, 19:11

@DeXT Was a pleasure for me, even if i am not a c coder, i know how to google. I like this project.

@robUx4 OT: I read on hydrogenaudio you offered help building an aac DS encoder. Any news?

@all
Naming: What do you think of MoreCD, files saved as *.mcd.iso?

Would sound neutral, reflect the benefit and would fit into your (the mcf dev team) name portfolio.

MoreCD.org is available:
Whois Server Version 1.3

Domain names in the .com, .net, and .org domains can now be registered
with many different competing registrars. Go to http://www.internic.net
for detailed information.

No match for domain "MORECD.ORG".

>>> Last update of whois database: Tue, 23 Apr 2002 04:59:53 EDT <<<

The Registry database contains ONLY .COM, .NET, .ORG, .EDU domains and
Registrars.

avih

23rd April 2002, 19:31

ok.
managed to play AVSEQxx.DAT file that contain avi or ogg files :)

so i now know how to support (=playback on the fly using graphedit) mp3/avi/ogg files from a 800M cd burned using de_xt's tool.

still not automatically though.
i have to re-compile for every different media type i use :(

any help on automatic mediasubtype recognition (NOT by the file extention, since all the files are .DAT) is most welcome.

regards
avi.

robUx4

23rd April 2002, 20:02

Originally posted by Koepi
sorry for the off-topic again,
robux,

this isn't about someone deserving the credits or anything like that. I dislike this "protektoristische scheuklappen" attitude (don't know any translation for that).
MCF-CD simply is a very special name that should forbid any further usage.
So even the name should be more generic.
That's what I'm talking about. Some OGG developers could be attracted as well as other DShow "gurus" if it wasn't for "MCF only".
Koepi

I know I know. The thing is that we'd like both format to be successfull and they well fit together. That was the idea when it was created... So the historical name IS MCF-CD, you can't change that. Now we could change the name to something else, why not. If there is much pressure from other people. But I also hope these same people could take some time to help these projects and not just asking more and more ;) That's why I consider that for the moment the format is highly related to MCF : it comes from there and is only there (for the moment).

I'm a bit exagerating, of course. But I wouldn't like another company endorsing MCF-CD as if it was their own. We are in the open (source) world, so things are a bit different than that, for the moment.

Some OSS projects don't give much credits to contributors, others does it clearly. I prefer those who give credits, even as an inspiration.

robUx4

23rd April 2002, 20:04

Originally posted by avih
ok.
managed to play AVSEQxx.DAT file that contain avi or ogg files :)

so i now know how to support (=playback on the fly using graphedit) mp3/avi/ogg files from a 800M cd burned using de_xt's tool.

still not automatically though.
i have to re-compile for every different media type i use :(

any help on automatic mediasubtype recognition (NOT by the file extention, since all the files are .DAT) is most welcome.

regards
avi.

I'm not fully aware of the format, but before the "real" data there should be a header identifying what is in the file. Isn't that what the DirectShow parser would be for ? (I don't know the answer to this question)

robUx4

23rd April 2002, 20:07

Originally posted by Gawen
@robUx4 OT: I read on hydrogenaudio you offered help building an aac DS encoder. Any news?

Well, it wasn't a DirectShow encoder, just an ACM (Audio Compression Manager), that's the old way in Windows to use audio codecs.

But right now I'm VERY busy on implementing libmcf, the library to parse and create MCF files. And that's my top priority. So the AAC/MPC/FLAC codec will come (hopefully) later.

Originally posted by Gawen
Naming: What do you think of MoreCD, files saved as *.mcd.iso?

MoreCD.org is available

That would be a good name :)

Gawen

23rd April 2002, 20:32

@avih Seems the file type info is in the RIFF Header. I dont know what it means, but here you find M$ Riff header parsing:

Platform SDK: Windows Multimedia
MMCKINFO

The MMCKINFO structure contains information about a chunk in a RIFF file.

typedef struct {
FOURCC ckid;
DWORD cksize;
FOURCC fccType;
DWORD dwDataOffset;
DWORD dwFlags;
} MMCKINFO;

Members

ckid
Chunk identifier.cksize
Size, in bytes, of the data member of the chunk. The size of the data member does not include the 4-byte chunk identifier, the 4-byte chunk size, or the optional pad byte at the end of the data member.fccType
Form type for "RIFF" chunks or the list type for "LIST" chunks.dwDataOffset
File offset of the beginning of the chunk's data member, relative to the beginning of the file.dwFlags
Flags specifying additional information about the chunk. It can be zero or the following flag:

MMIO_DIRTY
The length of the chunk might have changed and should be updated by the mmioAscend function. This flag is set when a chunk is created by using the mmioCreateChunk function.
Requirements

Windows NT/2000/XP: Included in Windows NT 3.1 and later.
Windows 95/98/Me: Included in Windows 95 and later.
Header: Declared in Mmsystem.h; include Windows.h.
See Also

mmioAscend, mmioCreateChunk

http://msdn.microsoft.com/library/en-us/multimed/mmstr_57ci.asp?frame=true

The mmioOpen function opens a file for unbuffered or buffered I/O.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/multimed/mmfunc_665q.asp

@robUx4 I am happy you like it. :)

@Koepi Would MoreCD be neutral enough for OGG developers to support it? ;)

Koepi

23rd April 2002, 22:42

Erm, you _want_ to get me wrong?

MoreCD sounds absolutely ok to me (but I guess we get trouble with Sony there? Didn't they call their propietary system MCD as well?)

I don't mean _me_ by any kind of mentioned developers. It's meant general.

But I'm glad that you're progressing very fast and well here!

Big thumbs up for creating a nice new format! :)

Best regards,
Koepi

Gawen

24th April 2002, 01:09

So maybe it should be called More;-)CD ?

Scratch *.mcd.iso, set *.morecd.iso

MoreCD has a meaning, its programmatic, mcd is just another 3 letter thing, so consumers will not mix that up. At least those i know. :D

@Koepi
Peace, brothers! All here do what they do for the community and fame. You are allready famous and theres enough space for gods of coding on mount olymp. I understand what you mean and i understand rob too. The name of a format usable for all should fit to their progs for their pride and still be usable for others without looking like thiefs. If i understand your sig well from a more emotional point of view: You know what pride is, so let them be proud. If they are, they will take good care of that baby and thats good for all.

ingoralfblum

24th April 2002, 02:24

any help on automatic mediasubtype recognition (NOT by the file extention, since all the files are .DAT) is most welcome.

If you look at the source that I pointed to already several times you see how this can be done. For the lazy here's the link:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/mediaxw/Src/MediaXW/Base/ReaderFilter.cpp?rev=1.1&content-type=text/vnd.viewcvs-markup

Try a look at the ReaderFilter::detectType() method.

I know, that my code lacks a good design, but is this single method really that difficult? Perhaps you should ask Steve (robux4), if he can help. He should be already familiar with my naming convention.
You probably want to read the part about how to register custom file types in the SDK first. There you see, that you can do it either by content or by extension and the method in the filter simply checks the content, based on the registry, first and if nothing matches it tries the extension.

Another question: Why do you name all files with the .dat extension?

Regards,

Ingo

ingoralfblum

24th April 2002, 02:29

All here do what they do for the community and fame.
Ahh, the buzzword comunity. I certainly do nothing for the community, whatever that community might be. When it's time for making profit the glorious community is gone faster than you can think.

Regards,

Ingo

Gawen

24th April 2002, 02:44

Originally posted by ingoralfblum

Ahh, the buzzword comunity. I certainly do nothing for the community, whatever that community might be. When it's time for making profit the glorious community is gone faster than you can think.

Ingo, imho there is nothing bad in earnig fame from a community of users of free software and there is also nothing bad in earnig money from customers. "You can not make a living from love alone, but if there was no love, nothing would live." (From an old stiched picture on my mothers kitchen wall) You say you certainly do nothing for whatever community. So what makes you visit this forum here in the middle of the night, pushing "lazy" people with their noses onto a solution they were asking for? And why does your work reside on a public server and not only on your local harddisk? In fact you do something for some users. When i try to support developers here i do in fact the same i do at work, where i ow money for it. Here i learn new things and i try to give something back. Scratch community, set exchange by free will.

ingoralfblum

24th April 2002, 03:42

You say you certainly do nothing for whatever community.

Yes, perhaps I do something for mankind, but not for a community, which is not there.

So what makes you visit this forum here in the middle of the night,

The fact that I went to bed at 17:00 yesterday.

pushing "lazy" people with their noses onto a solution they were asking for?

It is only a tip and be sure that they are not asking for what I posted. The source behind that link was already there 9 days ago and the people, that are now asking for it, already know that and already looked at it days ago.

And why does your work reside on a public server and not only on your local harddisk?
Yes, the old code resides there. Fortunately I canceled my SourceForge account and I'm happy with it. And the reason, that the code is still in a public CVS is the fact, that I have neither the time nor the resources to force OSDN to remove that code.

In fact you do something for some users.

Perhaps I try, but there's no effect. It's like running against a wall. Unfortunately it took years to recognize that - lost years.

Regards,

Ingo

Neo Neko

24th April 2002, 04:31

Ingo you give yourself to little credit. You may have been butting your head agianst a wall with this. But it was not anything the average joe could even begin to tackle. It was your project that really generated intrest in Vorbis for multimedia files in the first place. Everything that is today on this topic is partly because of you. So it was a near impossible task to get AVI to accept it. No one blames you. In fact we all understand even if in a limited way the dificulties you were facing. AVI ain't none to frindly to that type of data. It makes me sad when such good coders as yourself just throw in the towel like this. I hope that we have not seen the end of you even if you have discontinued your SF account.

You may not count yourself among the community. But be assured that there was one following your work. :)

Gawen

24th April 2002, 05:58

Originally posted by ingoralfblum
Perhaps I try, but there's no effect. It's like running against a wall. Unfortunately it took years to recognize that - lost years.[/B]

Ingo, if a job searches you, (and not you a job), you take it, you love it, you fight for it, you are the frontrunner ... then you will always be alone. Its in the nature of that kind of fight. It was your heart that kept you running on a road your intuition showed you. Thats why the job chose you. Next time simply give others a chance to follow and there will be a community around you. Or is there someting left you have to show yourself? If not come down from K2 take your seat on the fire and tell the others how it feels to be up there. ;)

(Been there, went back, was worth it)

avih

24th April 2002, 09:19

Originally posted by ingoralfblum

If you look at the source that I pointed to already several times you see how this can be done. For the lazy here's the link:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/mediaxw/Src/MediaXW/Base/ReaderFilter.cpp?rev=1.1&content-type=text/vnd.viewcvs-markup

Try a look at the ReaderFilter::detectType() method.

I know, that my code lacks a good design, but is this single method really that difficult? Perhaps you should ask Steve (robux4), if he can help. He should be already familiar with my naming convention.
You probably want to read the part about how to register custom file types in the SDK first. There you see, that you can do it either by content or by extension and the method in the filter simply checks the content, based on the registry, first and if nothing matches it tries the extension.

Another question: Why do you name all files with the .dat extension?

Regards,

Ingo

ingo, you are right. i didn't look at the code, although i could have, few days ago, as you noted.

i guess i should take the blame on me for beeing 'lazy'. and yes, i did start reading the sdk about registration and association yesterday, before i saw your post. i downloaded a hex editor and checked the content of different media files (to find that .avi i.e. is a riff file that can be recognized by it's riff type). so now i know we have riff (avi file) inside a riff (cdxa file). i was just excited that it worked, that i wanted further info to improve it. i started to look at the documentation as soon as i posted my question. either i will find the answer, or someone with more experience help me. thanx for your links.

regarding the files with .dat extention. well, i didn't make the imaging application (i think de_xt modified it from vcdimager or something), so it's based on s/vcd imaging applications, and it generates all the files as .DAT. i did a quick search through the code and couldn't find 'AVSEQ', so i figured the name is automatically generated by windoes when it mounts a m2f2 cd. i was just called for help with specific problem (non-existant dshow parser for this format) and that's what i started to work on. i didn't go to it's roots, bacause it seemed working and because i don't have too much knoledge of cd formats.

regarding open_source/audio/video 'community', well, u can't ignore the fact that one exists. for open source, well, i guess some do it for the fame, but some do it as a personal challange. no doubt some do it for both. i wouldn't mind getting some fame on the way, but it's not the purpose of my programming. i like the CHALANGE and i like the usable result and it's just FUN for me. i think many would agree with that way of thinking.

i came to this forum just couple of months ago, because i needed help. now i sometimes help others. before some months ago i've never done any video coding/postprocessing/editing/anything else, not as a user and not as a programmer. now i know what colorspaces are, what interlacing is and what dshow is and much more. i could have learned it all from reading manuals and web pages, but u just can't compare it to human feedback. that's the community.

i do hope you'll stay around, and code for your pleasure, and that others will be able to enjoy your work.

best regards
avi.

DeXT

24th April 2002, 10:13

Well tonight I was playing with the code avih posted here and now I've up and running the auto association with RIFF/CDXA content. What this means is, now you don't need to manually load the filter in GraphEdit but a simple double clic on the DAT file will load this filter. So this makes things much easier to test now.

I've also changed some things that needed to be done: create a new GUID for it, change its Friendly Name (now it's called "RIFF/CDXA Source"), tweak the Load() function to work with the new Media Type.

Below is the modified code. I've added two BAT files to (un)register it easily.

I had to do a small "hack" with the RIFF media type because, as I suspected, it broke VCD/SVCD compatibility (men you never listen to me). So this currently works only with CDs made with mcfcdmaker (anyways this isn't a big problem, isn't it? ;)).

About the problem Avih talked about (the Media Subtype passing to the next filter) I think we'll have it solved soon. Thanks Ingo for the tips. I already knowed how to create a custom type, I was only hoping that Windows were smart enough to re-create the Media Type out of the output stream. I now see this must be done manually by us, the same way you did in the detectType() method.

BTW, the DAT extension, I simply chose not to change it, because a DAT file is commonly a RIFF/CDXA one, and many people already has associated it with their Player. For the MCF content (and/or OGG) perhaps I should change it for a more suitable one. But this is part of the future MCF-CD specs, which I'd like someone start discussing with me ASAP.

PS: Ingo, I'm sad you are leaving, I only hope you really don't think all these years' work is lost lime.

[BTW i hope a moderator will approve this attachment soon]

avih

24th April 2002, 10:24

>"About the problem Avih talked about (the Media Subtype passing to the next filter) I think we'll have it solved soon. Thanks Ingo for the tips. I already know how to create a custom type, I was only hoping that Windows were smart enough to re-create the Media Type out of the output stream. I now see this must be done manually by us, the same way you did in the detectType() method."

i've found out that windows can render the chain automatically if it has a compatible mediasubtype. i.e. when it was compiled with mediasubtype_ogg, loading the filter with ogg-riff-cdxa file, and clicking 'render pin' will render a functional ogg chain that will playback ok.

nice work dext. these are indeed exciting times :)

tg0021

24th April 2002, 12:05

@ DeXT : tryed your DS-filter with a 15 MP3 files MCFCD. We tryed then to open the file with WMP6.4. It works for the first file (AVSEQ01.dat) but the others sounds jerky. Sometimes WMP craches with the first file after trying another one. Anyway, your work is really impressive... :cool: Keep going : I'm a fan ! :D :D

ChristianHJW

24th April 2002, 13:06

Originally posted by avih
regarding open_source/audio/video 'community', well, u can't ignore the fact that one exists. for open source, well, i guess some do it for the fame, but some do it as a personal challange. no doubt some do it for both. i wouldn't mind getting some fame on the way, but it's not the purpose of my programming. i like the CHALANGE and i like the usable result and it's just FUN for me. i think many would agree with that way of thinking.

Originally posted by de_xt
PS: Ingo, I'm sad you are leaving, I only hope you really don't think all these years' work is lost lime.

Guys, i dont think ingo is talking about the same thing as you do. In Germany the word 'community' does not only mean a bunch people living in the same village or interested in the same topic, but from the historical understanding of the word it means people helping and respecting each other.

After having had several conversations with ingo about this subject i do have the impression he is very disappointed about the way things were working out for his ambitious MediaXW project and the way cooperation is generally working in the video/audio encoding scene.
He had been investing a lot of time into his libraries ( forgive me if i post rubbish, i'm no coder ) to replace the Windows libraries to allow compilation of the MediaXW sources on different platforms. Tobias had released his Vorbis DirectShowFilters same time ( of course its much easier if you can use the Windows DirectShow SDK i guess ) and the whole community started using them as we all ( including me ) here and on powerdivx.com pushed it a lot as the long expected alternative to AVI. Ingo mentioned to me one day he was a bit disappointed why Tobias had not tried to approach him for cooperation, as he knew well about the existence of the MediaXW project. Well, i asked Tobias this question one day and he said he didnt believe AVI was a good container for Vorbis ( being true ) ..... but of course ingo was aware of this also, so they for sure could have started a cooperation with mutual benefit instead of both being 'the lonesome cowboy fighting for justice..' .

So, now, and this is not the 2nd but the 3rd or 4th time this happens to him, people again start to reinvent the wheel instead of looking at his sources where he has been investing so much precious time .... can you understand his reaction now ??

Whats under the bottomline ? Again its all about communication ... misunderstandings and misinterpretations everywhere ! Thats why i am still convinced people like myself, being no coders, can contribute to a project like MCF or Ogg by doing nothing else than keeping up a good communication about it, making sure relevant informations are digged out and passed to the right people.

And folks ..... its not too late ;) !! You wonna motivate ingo to keep up the incredible work he did ? Well .... start using his sources and give him feedback !!

robUx4

24th April 2002, 13:21

The sadest part is that you can't even blame Ingo for not giving more documentation on his work, because he has collected an impressive collection of documentation on the subject he was working on. And it was published on the web (I think it still is).

Now maybe the sources are a bit hard to get into. I know because he uses all the great possibilities of C++ so you have to know and understand them to really be able to read the code.

Anyway, this is not a topic about Ingo ;)

BlackSun

24th April 2002, 13:25

Agreed. Ingo is an incredible coder and he has done a lot. His project is certainly as big as VirtualDub and I really like what he has done.

He has done a lot for the community, it's sure, and we still need him !!

Ingo, I am your 1st supporter and can appreciate what you have done/you are doing...

robUx4

24th April 2002, 13:39

Originally posted by BlackSun
Coming Soon... The Concentric Circles of Audio and Video
http://www.corecodec.com

Which circle is inside the other ? :devil:
:D

BlackSun

24th April 2002, 13:41

Stop bugging me :D

Edit: this section has not yet been uploaded/updated
mouhaha :) lol

DeXT

24th April 2002, 14:47

@Chris: yes I also think the way the "multimedia" scene works is far from perfect. But I think we cannot be blamed of "reinventing the wheel" with this filter. I've TRIED to get help from anyone, but no one had time to do the work, or give some help. And it should be noted that I started working on this only after Ingo leaved, and after realising no one would continue the work on his filter.

In fact I also tried to reuse his code but as I said, this is too difficult for me. I didn't even know where to start. So the only thing I could do is write a new filter based on a sample code. At least I have a clear idea on how to do it this way.

So yes, we've also suffered from lack of help from the "community". We (avih & me) are not DS experts, and still have several problems. But we have resigned this is the only way of making things go ahead. Anyways I still hope that a good C++ programmer will take Ingo's work and continue it.