Editor Tools Programmer Project (split)

[kmv]

I would like to apologise to everyone who has been stuck in limbo for the last week.

I have been very aware during the last few days that I had become a bottleneck and that because of the timing no one was even able to takeover - which is part of the point of open source in the first place.

For those interested, I had an RFI (more of an RFP actually) drop in my lap suddenly. These things normally take about 4 weeks to respond to - we had 2 weeks. Many late nights.

In any case I have added the developers to the project and added a couple of administrators, so with any luck someone suddenly becoming busy shouldn't cause this upset again.


Modules:

I have the following module list I'd like you to consider:

Code: Select all

Huffy
	HuffyQT
	HuffyAVI
PremiereAVSPlugin
	Premiere5
	Premiere7
VideoSizer
AviHeditor
IVTC
CodecControl

If you like them, then let's run with them.


Module Structure:

I would like to propose the following module structure:
root

Code: Select all

+---Module1/
|   +---Build/
|   |   +---Generic/
|   |   |   +---[build files for generic src]
|   |   +---platform1/                                       
|   |   |   +---[build files for platform1]
|   |   +---platform2/
|   |       +---[build files for platform2]
|   +---Doc/
|   +---Minor_Component1/
|   |   +---src/
|   |   |   +---[generic src]
|   |   |   +---platform1/
|   |   |   |   +---[platform1 specific src]
|   |   |   +---platform2/
|   |   |       +---[platform1 specific src]
|   |   +---authors.txt
|   +---Major_Component2/
|       +---Sub_Component2.1/
|       |   +---src/
|       |       +---[generic src]
|       |       +---platform1/
|       |       |   +---[platform1 specific src]
|       |       +---platform2/
|       |           +---[platform1 specific src]
|       +---Sub_Component2.2/
|       |   +---src/
|       |       +---[generic src]
|       |       +---platform1/
|       |       |   +---[platform1 specific src]
|       |       +---platform2/
|       |           +---[platform1 specific src]
|       +---[component_level src]
|       +---authors.txt
+---Module2/
etc...

What do people think?

[Kalium]

I was thinking more along the lines of

+Platform_1/
| +Module_1/
| +---Generic/
| +---Doc/
| +---Minor/
| +---Major/
+Platform_2/
<etc>
...
|
+Source/
<etc>

But I think either would work.

[trythil]

I like kmv's organization -- as the majority of the code can (and should be) as cross-platform as possible, we should make any code that needs to be rewritten for different platforms subsets of the larger modules.

I'm reading up on SourceForge.net services now -- it's all pretty familiar stuff, so I can at least get modules organized.

We will be importing quite a bit of existing source for Huffy and PremiereAVS -- how should that be organized?

[Kalium]

I like kmv's organization -- as the majority of the code can (and should be) as cross-platform as possible, we should make any code that needs to be rewritten for different platforms subsets of the larger modules.

Yeah, you're likely right. It does make more sense that way. I was thinking more along the lines of how the user wants to see the builds organized.

We will be importing quite a bit of existing source for Huffy and PremiereAVS -- how should that be organized?

Wouldn't that be under generic?

[trythil]

Wouldn't that be under generic?

I dunno -- from what I can see of kmv's setup, "generic" refers to code that is common to all platforms, and neither HuffYUV nor the Premiere AVS plugin are really that. (Well, obviously, the Premiere AVS plugin will be a Windows thing.)

[kmv]

Yeah, you're likely right. It does make more sense that way. I was thinking more along the lines of how the user wants to see the builds organized.

The CVS module organisation actually has nothing to do with the release organisation, so we can organise CVS in whatever way makes sense from a development perspective.

We will be importing quite a bit of existing source for Huffy and PremiereAVS -- how should that be organized?

Wouldn't that be under generic?

The generic source is, by definition, generic - i.e. platform independent. I anticipate quite a bit of code will actually be platform independent, most of the algorithms for example.

I would expect the majority of platform specific code will be UI related, with some obvious extras.

As for the existing code that gets "imported" into the project it should go wherever it is appropriate: if it is generic then in a source root, if it is specific it should go in a platform specific sub directory.


The Premiere plug-in is an interesting case: Quite a bit of it could be generic if Premiere uses the same plug-in interface on both the Mac and the PC. The resource and build information would be platform specific of course. However this whole point is moot because there is no AVISynth port on the Mac, and there is no Unix version of Premiere.

[trythil]

Update:

I've committed the original sources of HuffYUV v2.1.1 and the Premiere AVS import plugin. The module structure is as kmv proposed with some minor changes:

(top-level names are modules; the rest are subdirectories)

Code: Select all

Huffy
   HuffyuvOriginal
   HuffyQT
   HuffyAVI
PremiereAVSPlugin
   Original
   PremierePro

I have not yet included the other four modules, but Ian or kmv can make them when the time comes. HuffyQT, HuffyAVI, and PremierePro are all empty subdirectories at the moment.

I think this'll work -- all we really need the original source for is as a base; when we start developing generic and platform-specific code, this module structure will easily be able accommodate such changes.

Hacking time

[Kalium]

Hacking time

This is where the fun stuff starts!

[trythil]

Hacking time

This is where the fun stuff starts!

Well, for me, it'll be a while.

I need to finish up schoolwork and get cracking on my stuff for DDR4 first, or else I'm going to get flogged

[AbsoluteDestiny]

OK, here's something.

The Premiere Pro code works just fine with premiere 6 and hopefully too with premiere 5 (I can test that later) which means that we can have one version. I'll check cvs in a bit to see what version we have up there.

The main problem at the moment is that it can't accept 24bit RGB. In this code:

Code: Select all

	bi.biBitCount = 32;
    fi.getframe = AVIStreamGetFrameOpen(fi.video, &bi);
		if (fi.getframe) {
			fi.bpp = 32;
			//MessageBox(NULL, "32-bit", "analysis", MB_OK | MB_ICONINFORMATION);
		}
		else {
			bi.biBitCount = 24;
			//MessageBox(NULL, "24-bit", "analysis", MB_OK | MB_ICONINFORMATION);
			fi.getframe = AVIStreamGetFrameOpen(fi.video, &bi);
			if (fi.getframe) {
				fi.bpp = 24;}
			else {
				return imBadCodec;
			}

It used to work... I'm sure it did. However, uncommenting the messagebox reveals that it isn't detecting 24bit rgb and that it's presuming it's 32 bit.

I'm not entirely sure what is causing this but it's really annoying

The only other thing that would be nice to work on would be a better resizer. I'm going to include the Pro version in the new amvapp later this week, so it would be nice to have 24bit working again.

Any ideas anyone?