Open source development

[DaveEL]

Now the source is out it seems a good idea if several people want to work on enhancing gordian knot it should be done as a group so we dont end up with loads of different gordian knots each dealing with different things (or worse several people waste time developing the same thing). So if anyone who would like to work on the program please post here so we can all work together.

DaveEL

[DSPguru]

@Dave
i think you should found a new project @ sourceforge.

go 4 it!

[OBcecado]

Sorry, but could you post the project name here ? So everyone as dumb as me can see the progress ? searched under knot and gordian and found nothing :confused:

Thanks and best luck developping what will succeed gordian knot.

[DaveEL]

Yeah i was going to look at sf but i havn't registered anything yet was trying to work out whos intrested (i dont have a lot of time so if im on my own i probably wont bother).

DaveEL

[irasnyd]

I'm very interested.

I just got the source, and I'm gonna start looking at it tonight, and see how it works. I think sf.net would be a good idea too. I sorta like the CVS.

Feel free to contact me anytime.
AIM: ClamChwdrMan
email: irasnyd@athlonoc.com

Ira

[dago]

I'm interested too.

I can setup a sf.net project right now if you want... but i don't know if it's a good thing me being the sf project owner (i really lack organization & discipline :rolleyes: ).

anyone up for the task?

[PowerMacG4]

I like SourceForge. Go for it. I already made a previous project that is 100% completely useless, so it is do-able to make a project, especially with source code...

[OBcecado]

Hi, is this project related to someone in this forum ?http://sourceforge.net/projects/gordianknot/
Best luck with gknot's developpement.

[binky the stunt cat]

i could help out...mainly from a suggestions/testing point of view, since my coding skills are rather lacking...

first suggestion: using the comptest method from the excel file someone posted a while ago. gives me much nicer results.

[len0x]

OK, guys. It's the only feature missing in my internal version of GK.
After I'm done with it I can finally give you some toy to play with (i.e GK with 5.0.3/4 and YV12 support) :)

But the question is: which comp test should I do:
1) is there a way to do that still using log files (the structure changed completely...)
2) that excel spreadsheet - if it is good and precise method for doing the test (including for b-frames)- I can try, but can I actually get AVG bitrate value from AVI file using low level access procedures ?

[DaveEL]

Originally posted by len0x
OK, guys. It's the only feature missing in my internal version of GK.
After I'm done with it I can finally give you some toy to play with (i.e GK with 5.0.3/4 and YV12 support) :)

But the question is: which comp test should I do:
1) is there a way to do that still using log files (the structure changed completely...)


Yeah you have to write somethng to parse the new format.

The other option is to abandon the log file parse and read the frame sizes via vfw which is also more general(works with any vfw codec) so this is probably the way to go.

DaveEL

[maurus]

That is my conversation with Lenox through e-mail, for interest of all.

I believe that a forum "Gordian Knot Development" would be created for treat these subjects.

...
--------------------------------------------------------------------
Lenox
--------------------------------------------------------------------
> FYI what I've done:
> to sum up: Full support 5.0.2/3/4 (including Nth pass) + AVS 2.5 support
> (YV12 mode)
>
> the only thing left and quite BIG one - compressability test with 5.0.3
and
> up...
>
> Changes:
> 1) Cropping is done with multiply of 2 for all modes (manual, auto, smart)
> so that it is
> YV12 compatible.
> 2) Added Lanczos to resize filters, Bob, FieldDeinterlace(blend=false) to
> deintrelace filters
> 3) TemporalSmoother changed to TemporalSoftener (noise filters)
> that brings everything to work for YV12...
> 4) Codec settings window is available on Compressability test form as well
> as on encoder
> from (I'm saving settings for two passes into file, and don't set
> SetCompData anymore)
>
> All this works fine with every version of divx5 including 5.0.4 beta. But
> unfortunately comp
> test cannot cope with new structure of log files. So if anyone knows how
to
> do that with
> new log files please tell me :)
>
> Best wishes,
> Tony.
>
>
--------------------------------------------------------------------
Maurus
--------------------------------------------------------------------
Very interesting. Congratulations!.
Perhaps jonny (nontelodiromai@msn.com) can help you.

We can have (I popose) a first new version with:

1) Cropping is done with multiply of 2 for all modes (manual, auto, smart) so that it is YV12 compatible.
2) Added Lanczos to resize filters, Bob, FieldDeinterlace(blend=false) to
deintrelace filters.
3) TemporalSmoother changed to TemporalSoftener (noise filters). ¿can we add
Convolution3D to noise filters? (all for YV12).
4) Full support DivX 5.03/4 (including Nth pass) + AVS 2.5 support.
5) Compressibility test for 5.03/4
6) ResizeFilter for Credits Bilinear by default.
7) No need to rename VDubMod anymore.
8) Minor changes:
8.1 Save and Save&Encode buttons in both SaveAVS and Edit windows
proposed names for Frameserver script and for Credits Framserver script (Movie.avs and Movie_Credits.avs).
8.2 Tittles for the Edit script window, adapted to the frameserver that it is edited (titles: Avisynth Frameserver, Avisynth Credits Frameserver and Avisynth comp.test Frameserver).

Maurus

---------------------------------------------------------------------
Lenox
---------------------------------------------------------------------

> 1) Cropping is done with multiply of 2 for all modes (manual,
> auto, smart) so that it is YV12 compatible.
> 2) Added Lanczos to resize filters, Bob,
> FieldDeinterlace(blend=false) to deintrelace filters.
> 3) TemporalSmoother changed to TemporalSoftener (noise
> filters). ¿can we add Convolution3D to noise filters? (all for YV12).

can someone provide me with specification for Convolution3D filters?
(i.e. which dll, which functions and avs example)

> 4) Full support DivX 5.03/4 (including Nth pass) + AVS 2.5 support.
> 5) Compressibility test for 5.03/4
> 6) ResizeFilter for Credits Bilinear by default.

I remembered that I didn't test credits yet (since I never actually used
that feature)

> 7) No need to rename VDubMod anymore.

actually I did fix that as well (forgot to mention) - now my version works
only
with VDubMod both for encoding and muxing audio...

> 8) Minor changes:
> 8.1 Save and Save&Encode buttons in both SaveAVS and
> Edit windows proposed names for Frameserver script and for
> Credits Framserver script (Movie.avs and Movie_Credits.avs).
> 8.2 Tittles for the Edit script window, adapted to the
> frameserver that it is edited (titles: Avisynth Frameserver,
> Avisynth Credits Frameserver and Avisynth comp.test Frameserver).

Once I made comp test working I'm ready to release it for testing
and upload to CVS as well.
Mauricio - if you want to send me the modifications for minor things you did
I can try merging them into my code...

P.S. someone should make updates to the syspack as well...

--------------------------------------------------------------------
Maurus
---------------------------------------------------------------------
That is the information for Convolution3d.

http://hellninjacommando.com/con3d/

> 6) ResizeFilter for Credits Bilinear by default.

Very interesting. There is people (Jonny) who add in addition
TemporalSmooter(10). The size of the credits is smaller and increases
bitrate with the movie (re-calculate).

With my change, Credits Frameserver use BilinearResize selecting both
"Credits only" or "Both" in Trim section.

> 7) No need to rename VDubMod anymore.

OK

8) Minor changes:

The 6) and those minor changes 8) are in the attached file (SaveAvs.pas). I add a comment " // Added Maurus Minor changes" before de changes. I added also de Filter Lanczos. You can merge them, if you want.

Thanks.

[len0x]

Originally posted by DaveEL
Yeah you have to write somethng to parse the new format.


it's not a problem to parse something, but rather a problem
of interpreting what you've parsed :)
Old comp test was based on calculation of "quant" field of log files.
Now with 5.0.3 we don't have this field at all...

Originally posted by DaveEL

The other option is to abandon the log file parse and read the frame sizes via vfw which is also more general(works with any vfw codec) so this is probably the way to go.
DaveEL

I'd like that, just wonder how fast that would be?
Do you know which function of vfw can get me frame sizes?
(and what should I do with those sizes afterwards to do comp test...)

[jonny]

@DaveEL:


The other option is to abandon the log file parse and read the frame sizes via vfw which is also more general(works with any vfw codec) so this is probably the way to go.


From VdubMod changelog:

- Added jonny's mods (Doom9 forum, DivX 5 Enc author) - commandline options :
* /log : generates (in the same directory) a vdenc.log file containing
some information (type and size of frame) about the clip
* /nowrite : prevent VirtualDubMod from writing video data in the output file
Nb : those options must be placed before any other because VirtualDub(Mod)
parse the commandline on sequence.


This is the way to go ;)
(latest divx5enc versions use this log... my new app (working with all divx-xvid versions, not yet released)... use this log too)

OT: my cpu cooler had broken yesterday... my cpu... burned :( :( :(
atm i can only browse the forum when i'm at work :( and i can't release the new app :(

[maurus]

Originally posted by len0x

2) that excel spreadsheet - if it is good and precise method for doing the test (including for b-frames).



I created that excel spreadsheet for the comp.test based in the Jonny's method (http://forum.doom9.org/showthread.php?s=&threadid=44414).

He says:

"This method is not 100% accurate with b-frames enabled.
With b-frames the predicted size will be oversized and the resulting comp.test value will be lower than the real value (i think something like 10%-15%)".

I think that Jonny can help us, since its DivX5Enc tool makes a good and accurate compresibility test with codecs 5.03.

Thanks.

[DaveEL]

Originally posted by len0x

I'd like that, just wonder how fast that would be?
Do you know which function of vfw can get me frame sizes?
(and what should I do with those sizes afterwards to do comp test...)

Should be fast as you dont need to decode any of the frames just read them. AviStreamRead is the function you want if you dont give it a buffer to read the frame into it will give you the size of the frame. The just treat it as if you are reading from a stats file.
(add up all the sizes(dropping the false keyframes as you normally do for a comp test). divide by number of frames. divide by number of pixels in a frame and you have your bpp value.

DaveEL

[jonny]

@DaveEL:

Don't you like my suggestion?

1) It's basically the same, hook vfw in VDubMod in order to write the log with frame sizes.
2) Faster, because you read a txt file.
3) Better, you don't need to write any temp avi file (using /nowrite); and you can do, for debugging pourpose, comptest with 100% of the movie, without taking care if the final size is >4GB.

PS: You must discard 2 frames every snip, do you know this?

cheers
jonny

[TheWEF]

- Added jonny's mods (Doom9 forum, DivX 5 Enc author) - commandline options :
* /log : generates (in the same directory) a vdenc.log file containing
some information (type and size of frame) about the clip
* /nowrite : prevent VirtualDubMod from writing video data in the output file
Nb : those options must be placed before any other because VirtualDub(Mod)
parse the commandline on sequence.

yea, that's the right way to go - because it works with any codec!!!

DEFAULT_SNIP_SIZE = 14;

do not take frames into account that are before and after an "artificial" scene change. they are bigger than in a normal encoding session and would ruin the calculation.

0
1
2
3
4
5
6
7
8
9
10
11
12

15
16
17
18
19
20
21
22
23
24
25
26


29
30
31
32
33
34

in this example you have 35 frames, but only 31 are counted. you add up their size, div 31 you get an average framesize (bits/frame).
e.g. the resolution is 640*272 = 174080 pixels.
div again and you get bits/(pixel*frame)

wef.

[len0x]

Originally posted by DaveEL
Should be fast as you dont need to decode any of the frames just read them. AviStreamRead is the function you want if you dont give it a buffer to read the frame into it will give you the size of the frame. The just treat it as if you are reading from a stats file.
(add up all the sizes(dropping the false keyframes as you normally do for a comp test). divide by number of frames. divide by number of pixels in a frame and you have your bpp value.

DaveEL

Sounds simple enough for me! The only question - what does "dropping the false keyframes as you normally do for a comp test" mean ?

Edited: sorry now I can see ppl already explained that :)

[len0x]

in which version VDubMod those options appeared ?
I just tried 1.4.13.2 - no log file output...

[DaveEL]

Originally posted by TheWEF
yea, that's the right way to go - because it works with any codec!!!


Except that is doesnt work with nandub rips which the other method does. Plus virtualdubmod is not the fastest way to encode.


DEFAULT_SNIP_SIZE = 14;

do not take frames into account that are before and after an "artificial" scene change. they are bigger than in a normal encoding session and would ruin the calculation.


Why does the frame before need to be dropped? i guess this is somthing to do with b-frames but i cant see what.

DaveEL

[jonny]

VirtualDubMod 1.4.13.1 + VirtualDubMod_310103.zip

OR

VirtualDubMod 1.4.13.2

- Call VDub with /log command line option.
- Run an encode (selecting a codec, doesn't work with uncompressed format or direct stream copy).
- At the end you'll find "vdenc.log" in the current directory.

[len0x]

I see log if I run a script rather then a job.
Please don't tell me that this doesn't work in batch mode! :)

P.S. What do 0 and 1 mean in the first column of the log file ?

[TheWEF]

Originally posted by DaveEL
Except that is doesnt work with nandub rips which the other method does.

true, but sbc really is an exception and gknot's stats file reader still works fine.

Originally posted by DaveEL
Plus virtualdubmod is not the fastest way to encode.

what is the fastest way and how much faster is it?

Originally posted by DaveEL
Why does the frame before need to be dropped? i guess this is somthing to do with b-frames but i cant see what.

jonny is the expert in this field...
IMHO 1st frame in a snip is not an i-frame all the time, can be a big d-frame as well. a b-frame before that would be bigger as well.

wef.

[jonny]

@DaveEL:

read my last post here:

http://forum.doom9.org/showthread.php?s=&threadid=29357


Except that is doesnt work with nandub rips which the other method does. Plus virtualdubmod is not the fastest way to encode.



Plus virtualdubmod is not the fastest way to encode.


Do you want to rewrite the encoding part without using VDub? (or using avs2avi?)

[TheWEF]

Originally posted by len0x
I see log if I run a script rather then a job.
Please don't tell me that this doesn't work in batch mode! :)

i think it's better to use vfc files than writing in the jobs file anyway. don't remember why i implemented it that way.
it should be relatively easy to change that, vcf works exactly the same way... :p

wef.

[jonny]

@len0x:

0 = delta frame
1 = key frame


Please don't tell me that this doesn't work in batch mode!


I've tested this only with vcf files (and you can to batch encoding with vcf :devil: :))
Running VDub jobs should work too (take care to specify /log before any other options)

[maurus]

Also can be interesting this thread (http://forum.doom9.org/showthread.php?s=&threadid=44621&highlight=comp.test) where Jonny explains some things for the compressibility test.

[DaveEL]

Originally posted by jonny
@DaveEL:
Do you want to rewrite the encoding part without using VDub? (or using avs2avi?)

avs2avi could be used (and i can still get a little more speed out of it i think).

DaveEL

[len0x]

Originally posted by TheWEF
i think it's better to use vfc files than writing in the jobs file anyway. don't remember why i implemented it that way.
it should be relatively easy to change that, vcf works exactly the same way... :p

wef.

"relatively" is good word :) I wanted to change as little as possible and just to get it running :)

But I just managed to find where I was wrong - batch mode working fine!

[len0x]

Originally posted by jonny
@len0x:
0 = delta frame
1 = key frame


I'm guessing we don't want to count keyframe when doing compr test, right?

And are those values already in the form that theWef described (with missing 2 frames around multiply of 14) or I still have to drop them myself ? (key frames can really complicate things here as well...)

[DaveEL]

Originally posted by len0x
I'm guessing we don't want to count keyframe when doing compr test, right?

And are those values already in the form that theWef described (with missing 2 frames around multiply of 14) or I still have to drop them myself ? (key frames can really complicate things here as well...)

You do want to count keyframes. Just the frames around 14 need to be dropped and you have to drop them.

DaveEL

[len0x]

Originally posted by DaveEL
You do want to count keyframes.

Got it. But not sure why do we want to keep key frames, since
their appearence is almost random... (they indeed do weight towards the size of the file, but rather constant value I believe, since codec has settings for maximum non-key frames length...)

[TheWEF]

Originally posted by len0x
Got it. But not sure why do we want to keep key frames, since
their appearence is almost random...

as random as in the movie that the comp-test should be a statitical representation of.

what a sentence... :p

DaveEL is right - keep them.

wef.

[TheWEF]

Originally posted by DaveEL
avs2avi could be used (and i can still get a little more speed out of it i think).

why not?
but what about enabling * /log and * /nowrite in avs2avi?

wef.

[len0x]

are those frame sizes are in bytes or in bits ?
coz if in bits I get too much compression...

But if in bytes, then - yes, I have it done ! :)))

[TheWEF]

you are a fast one, aren't you! :D

but just wait, till everybody is compaining about the bugs... :p

wef.

[len0x]

Originally posted by TheWEF
you are a fast one, aren't you! :D

but just wait, till everybody is compaining about the bugs... :p

wef.

yeah, I'm fast - I like hacking without any responsibility :)
(I still think it's better than people talking "we need to create
SF project, who want to be in charge?" :) )

I'm sure ppl will find bugs (I'll never say I'm producing something without them) - and probably half of them will be yours anyway :)
But as long as I don't have to test my stuff and have enough ppl to do that for me - it's fine...

p.s. tomorrow I probably publish executable for testing somewhere. Does someone have a place to put it on the web ?

p.p.s comp test seem to be working fine - results from GK 0.27 + 5.0.2 is the same as my new version with the same codec.

p.p.p.s And yes Nth pass is working perfectly as well :) (just finished trying with 5.0.4 beta)

[jonny]

@len0x:

Fast!!! :)

ok, sizes are in bytes.
keyframes infos are mainly for debugging pourpose.

correct sequence of discarding is (in vdenc.log):
(snipsize=14)

0 [D]
1
2
3
4
5
6
7
8
9
10
11
12
13 [D]

14 [D]
15
16
17
18
19
20
21
22
23
24
25
26
27 [D]

and so on...

i've made experiments discarding keyframes inside the snip, so discarding first_frame+last_frame+all_keyframes and this gives sometime better results, sometime really bad results (so it's better to use the simple method above)

@DaveEL:
i don't know if you have fixed this, anyway when i've tryed avs2avi, the load state option was not working with divx5.
So, if -l options don't work correctly, we can't pass divx5 parameters to it (i've pointed out a fix to Toff, long time ago: ICClose/ICOpen after ICSetState seems to fix this... but seems to broke xvid ^^')

if you add something like /log /nowrite to avs2avi and you have some more time, could be nice to add another option to get the snips not sequentially (example first snip at the start, second in the middle, third at the start and so on- this should produce more artificial keyframes and probably help the xvid comp.test field... ok i should test this :p)



OT1: my cpu have a nice black big burn on the top :(
OT2: i'm writing from my brother crappy pc :devil:
OT3: comp.test with xvid+bframes = HELL :D (not easy as the divx5 one)

[DaveEL]

Originally posted by jonny
@len0x:
@DaveEL:
i don't know if you have fixed this, anyway when i've tryed avs2avi, the load state option was not working with divx5.
So, if -l options don't work correctly, we can't pass divx5 parameters to it (i've pointed out a fix to Toff, long time ago: ICClose/ICOpen after ICSetState seems to fix this... but seems to broke xvid ^^')

Ill take another look can you send me the fix so i can take a look and try to see whats going on.

if you add something like /log /nowrite to avs2avi and you have some more time, could be nice to add another option to get the snips not sequentially (example first snip at the start, second in the middle, third at the start and so on- this should produce more artificial keyframes and probably help the xvid comp.test field... ok i should test this :p)


might be better to do this in the avs script or as a avisynth plugin anyway.

DaveEL

[jonny]

Ill take another look can you send me the fix so i can take a look and try to see whats going on.

I'm sorry Dave, i'll don't have access to my hd for the next 2-3 days until i buy a new cpu.

The fix is easy, after the ICSetState function you must put an:
ICClose(..)
ICOpen(..)
(so you must actually close and reopen the codec)
You can also try to ask Toff for this (i've send him the mods some time ago)


might be better to do this in the avs script or as a avisynth plugin anyway.

Yes, probably an avisynth plugin will be the best solution.
(actually i was making experiment via vcf scripting, selecting the different ranges... if the method gives good results, i'll think about a better implementation ;))

[DaveEL]

Originally posted by jonny
I'm sorry Dave, i'll don't have access to my hd for the next 2-3 days until i buy a new cpu.

The fix is easy, after the ICSetState function you must put an:
ICClose(..)
ICOpen(..)
(so you must actually close and reopen the codec)
You can also try to ask Toff for this (i've send him the mods some time
ago)


Its not a very nice solution, especially if it breaks xvid it looks like the load codec state function doesnt set ICMF_COMPVARS_VALID which it should do according to the api docs might explain it so ill try that next time i boot into windows. Aside from that i can't see what its doing wrong.

DaveEL

[TheWEF]

@len0x: well done! :)
is it possible for you to upload stuff to the sourceforge project? do you have an account? you could send your code to christof so he can upload it.

i tried to create an account two times, but i never got a confirmation e-mail to activate that account. does anybody know what i could be doing wrong? or does it take a few days until you get that mail?

anybody familiar with sourceforge?

wef.

[irasnyd]

This is looking really good :)

I asked on the email list about packaging:
1) What created the original installers? (it looks like one of the Nullsoft installers to me)
2) Do we have the scripts used to make the installers (I dont see them
in the source)
3) What programs, etc. need to be in the packs

I'd be happy to package them up.

I have web hosting if anyone needs it to host a testing build or something.

irasnyd
irasnyd@athlonoc.com

[maurus]

Perhaps DSPGuru can help us for the convenience of updating BeSweet 1.5b8 to the last BeSweet 1.5b16 and if we must change some parameter by default (OTA section, AZID section, LAME section, ...).

I would add to the hip.dll to qualify to Gknot to work with audio MPA. Can you see here (http://forum.doom9.org/showthread.php?s=&threadid=45127).

In the "new SystemPack" I would also add the last ac3filter 0.6.6.

Thanks and congratulations to all.

[len0x]

Originally posted by TheWEF
@len0x: well done! :)
is it possible for you to upload stuff to the sourceforge project? do you have an account? you could send your code to christof so he can upload it.

i tried to create an account two times, but i never got a confirmation e-mail to activate that account. does anybody know what i could be doing wrong? or does it take a few days until you get that mail?

anybody familiar with sourceforge?

wef.

I became a project admin at SF, apparently :)
And yes I used SF before (was AAC codec developer 3 years ago...)
by the end of the day I'll fugure out how to create & upload stuff there (never was admin before :) )

[jonny]

Its not a very nice solution

Yes i know, it's a really dirty solution (when i've tryed i've only found this solution, so let me know if you find a more clear one).

jonny

PS: iirc the problem was only related on setting 1st-pass or 2nd-pass encodes ( this is the strangest thing! :confused: )

[len0x]

Originally posted by irasnyd
This is looking really good :)

I asked on the email list about packaging:
1) What created the original installers? (it looks like one of the Nullsoft installers to me)
2) Do we have the scripts used to make the installers (I dont see them
in the source)
3) What programs, etc. need to be in the packs

I'd be happy to package them up.

I have web hosting if anyone needs it to host a testing build or something.

irasnyd
irasnyd@athlonoc.com

Can please Wef comment on all that - did you do installers yourself or somebody else ?

In order to make a proper installers we need to update AVS, filters and VDubMod. This is essential. The rest have to be just checked for most recent versions of tools but it's not crucial yet...

[TheWEF]

hi!

Originally posted by irasnyd
I asked on the email list about packaging:


what email list?

Originally posted by irasnyd
1) What created the original installers? (it looks like one of the Nullsoft installers to me)

yes, it's a Nullsoft installer.

Originally posted by irasnyd
2) Do we have the scripts used to make the installers (I dont see them in the source)

i wrote and have the scripts.

Originally posted by irasnyd
3) What programs, etc. need to be in the packs
I'd be happy to package them up.

i could upload the scripts to the sf project. on the other hand i think it's better if i do the packing myself. why?

gknot source code is GPL now and everybody can do with it whatever he/she wants. but me and doom9 still do want to have control over the program that is published under the name "Gordian Knot". doom9 can tell you how many people are downloading the packs, the traffic that it creates is enourmous.
there has always been some kind of quality control, beta testing period before we decided to release something.
so i suggest this: small and regular updates (nightly builds ;) ) are published on sf, but as exe-only releases with no support in this forum what so ever.
sf-admins, feel free to do so right away. the program title should clearly state that this is a test-build without support!!!
this is for experienced users only, they do not need the installer anyway. whenever we reach the point of a stable build i will create a new pack and it will be published exclusively over here at doom9.
this will make it easy for people to differentiate between stable releases and testbuilds - it's like me and doom9 putting our stamp of approval on it.

all right?

Originally posted by irasnyd
I have web hosting if anyone needs it to host a testing build or something.

if possible we will use sf for now, but we'll keep your offer in mind. thank you!


wef.

[DaveEL]

Originally posted by TheWEF
what email list?

Ive been collecting peoples e-mails ill add your address if you want we really should set up a sf mailing lists and move discussion to that no need to bloat the forum with stuff most users are not intrested in.

DaveEL