PDA

View Full Version : ideas for codec configuration


TheWEF
2nd April 2003, 09:50
on one hand we want to keep it simple so that we do not have to mess with the codec configuration window all the time.
on the other hand everybody has settings he likes best and wants to have full control over the configuration.

a solution for both would be to introduce codec profiles.

e.g.:

all codec profiles are stored in a gknot sub-folder called "profiles".
a codec profile consists of up to 8 files:

DivX504pro.ini
DivX504pro_pass1.reg
DivX504pro_pass2.reg
DivX504pro_passn.reg
DivX504pro_credits.reg
DivX504pro_single.reg
DivX504pro_compcheck.reg
DivX504pro_default.reg

minimum is 6 files:

XviD.ini
XviD_pass1.reg
XviD_pass2.reg
XviD_credits.reg
XviD_compcheck.reg
XviD_default.reg (that's what is restored after encoding)

the reg files are standard reg files that represent a branch of the registry and contain the codec settings. they can easily be created manually with regedit and easily be remerged with the registry using "regedit.exe /s c:\myreg.reg"

gknot detects all ini files in "profiles" on startup.
in the encoder window all you have to do is select a codec configuration from a dropdown menu, that's as easy as it can get.

now what has to be in the ini file:

[codec profile]
Name=XviD_Example ; maybe the filename is enough?
Description=something ; could be displayed below the dropdown.
CodecID=0x64697678 ;for SetCompession() in vdubmod script.
BitrateKey= ;not available for XviD, here gknot can set bitrate after the regfile has been merged.
BitrateMult= ;something to define whether the value is in bit, kbit,...
SizeKey=HKEY_CURRENT_USER\Software\GNU\XviD\desired_size ; here gknot can set video size after the regfile has been merged.
SizeMult= ;same

... maybe more, the rest is just to create filenames that are needed (input filename gets new extension):

[file1]
Key=HKEY_CURRENT_USER\Software\GNU\XviD\stats1
Ext=_stats1.stats
[file2]
Key=HKEY_CURRENT_USER\Software\GNU\XviD\stats2
Ext=_stats2.stats
[file3]
Key=HKEY_CURRENT_USER\Software\GNU\XviD\hintfile
Ext=_hintfile.stats
[file...as many as needed]


doing it like that you get:
XviD support right away.
you can store as many codec configurations as you like.
this is future proove - you don't even need to update the program for a new codec - just distribute the new profile.


just a proposal...

wef.

len0x
2nd April 2003, 11:15
Nice suggestion.
Moreover I have a new unit in the project to load and save .reg files already. So it'll be even possible to create profiles withing GK quite easy.

But this stuff should go for 0.29 and up... we really need to have something working stable when 5.0.4 final is released (may be in two weeks already...)

DaveEL
2nd April 2003, 11:51
[QUOTE]
a few things

A seperate directory for each profile and standard naming of files would make this a little easier i think (eg gordian knot\profiles\some profile\codec.ini, pass1.reg etc)

We should make utilities to create the profiles so people can tweak them (eg enable different divx pro features or use the old two pass code or the new multipass code in divx 5.03 in different profiles. Seperation of codec config from the main program sounds like a good idea to me and multiple profiles per codec).

The defaults should not be a stored set a better way would probably be to specify which registry tree to backup and restore.

Perhaps internally two classes (well if we do OO stuff) to handle all this stuff which can each return multiple profiles for the gui. One which handles this stuff via vdubmod and one for nandub. so the profiles you choose does more so they include the encoder setup and run too. This would allow say real video 9 support to be added at some point as well. Plugins would work well here too. so we have 2 default plugins divx3 and everything that can be done in vdubmod/registry hacks(by the above) but others could be added. (i can give someone help if they want to loading of plugin dlls and dont know how)

Would be nicer to store the codec id as the fourcc rather then a number too.

Would be nice for the system to check which profiles are valid (which have the needed codec installed).


As only one of bitrate and size is valid these two could be merged by setting more info in the multiplier flag (or a seperate flag to make it easier to parse). so you have a multiplier size and type (bitrate/size) flags.

Need some way to specify number of passes also (divx 5.03).

DaveEL

Emp3r0r
2nd April 2003, 18:51
great idea the wef, I am changing settings in the registry with DVD2XCD for use with XviD and it saves tons of time. Really, all you need to be able to do is read from and write to

[HKEY_CURRENT_USER\Software\GNU\XviD] and
[HKEY_CURRENT_USER\Software\DivXNetworks\DivX4Windows]

The settings to be set automatically for XviD
mode,
desired_size,
credits_start,
credits_start_begin,
credits_start_end,
credits_end,
credits_end_begin,
credits_end_end,
hintfile,
stats1,
stats2

edit: a button to open the VFW GUI should be sufficient for the rest

len0x
3rd April 2003, 11:53
Well, I though about it and I think I can meet you guys in the middle for a time being:

Having three default files for first, Nth, and credits in the GK folder
and allow to edit the defaults from GK options tab. And then I can remove restriction when pressing encode: if in the ouput directory doesn't contain settings, I'll just copy defaults substituting bitrate and quant (for credits).

How does this sound? (I mean for now, not for the future :) )

TheWEF
4th April 2003, 01:32
Originally posted by len0x
How does this sound? (I mean for now, not for the future :) )

perfect! :cool:

wef.

stax76
4th April 2003, 16:02
the good thing about the registry method is it's 100 % reliable
don't matter which codec build is used and a new codec can be
added in five minutes. I use it since more than a year. Only
problem is not all codecs save in the registry, XviD don't save
the CPU settings and Microsoft WM9 beta don't save at all

len0x
5th April 2003, 16:22
Originally posted by TheWEF
perfect! :cool:

wef.

done in alpha 6 (as well starting encode via script(vcf) rather then job)
Should be more user friendly now :cool: