Log in

View Full Version : MeGUI development


Pages : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 [31] 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92

Richard Berg
24th January 2006, 16:10
Thanks for your help. I've tried it several times now to login to the megui cvsroot. Without any succes. There's everytime a timeout. Think I've read something about it before. Does anyone know how to get it working?
In my experience the last few weeks, it's down about half the time. I just wait a few hours and try again :(

klicker4546
24th January 2006, 16:28
Ok, I see. Think I will manually downlaod the changes, so far I can find them in the webcvs. :)

In my experience the last few weeks, it's down about half the time. I just wait a few hours and try again :(

dimzon
24th January 2006, 17:15
Does we need mediaInfo.dll wrapper? I can write it.
there alredy are C# wrapper bundled with Dll

dimzon
24th January 2006, 17:36
2 all devs
this.path = Environment.CurrentDirectory;
peoples are confused when they start MeGUI from command line and does'nt see their settings/jobs/etc...
I propose such replacement:
this.path = AppDomain.CurrentDomain.SetupInformation.ApplicationBase;
what does You think about?

Mutant_Fruit
24th January 2006, 21:29
Wouldn't this work better:

string path = Application.StartupPath;

I believe it returns the path that the exe is in.

ChronoCross
25th January 2006, 00:17
for those of you who want it:

http://www.chronocrossdev.com/apps/megui/MeGUI-0.2.3.2045.rar

Includes the source files.

dimzon
25th January 2006, 11:37
Wouldn't this work better:

string path = Application.StartupPath;

I believe it returns the path that the exe is in.
Yes, it's better ;)

dimzon
25th January 2006, 12:17
0.2.3.2046 25 Jan 2006
Commit by dimzon:
-FAAC Settings && FAAC Settings Dialog - performed little cleanup && bugfix

dimzon
25th January 2006, 12:28
0.2.3.2046 25 Jan 2006
Commit by dimzon:
-nothing, just marked AviReader by [Obsolete] attribute (it's time to switch to AvsReader). not affected anywhere except you get warnings during compilation now

stax76
25th January 2006, 12:39
Yes, it's better ;)

Funny to see that even devs with deep .NET knowledge didn't knew this one ;)

dimzon
25th January 2006, 12:55
Funny to see that even devs with deep .NET knowledge didn't knew this one ;)
Impossible to know everything... ;)

Doom9
25th January 2006, 13:44
-Modified AvsReader are now used for Avs preview ;) Everyting works fine...Now you could go all the way and change the input checking prior to encoding to make use of it and even check for YV12 input and give the user a specific warning about the colorspace if it doesn't match the one required..
I'll have a look at the avsaudioencoder tonight.

dimzon
25th January 2006, 14:10
0.2.3.2047 25 Jan 2006
Commit by dimzon:
- VideoPlayer can play avs via string (does not need temporaly avs files)
- AviSynth generator does'nt create preview.avs && temp.avs more

http://img93.imageshack.us/img93/5926/untitled2cc.png

dimzon
25th January 2006, 14:13
@Doom9
Hello
Can I perform this modification: http://forum.doom9.org/showthread.php?p=774275#post774275

(I'm asking bcz I do not know -it is a bug or a feature)

dimzon
25th January 2006, 14:20
2 all devs

found such code:
// Directshowsource needs the FPS information to be supplied.
// Without a lot of restructuring of code this is the best way of finding the FPS
// If anyone knows a better way of obtaining Framerate info, change this.
AVIReader reader;
try
{
reader = new AVIReader(fileName);
}
catch (Exception) // Some files can't render because you have no VfW codec (like DV sources)
{
reader = null;
}

AFAIK DiresctShowSource reques explicit fps information in very rare cases. And can't believe AVIFile32 API can return fps for such rare cases at all (AFAIK it even can't read such files)

Correct me if I'm wrong, please! I'm suggesting to remove this code!

Doom9
25th January 2006, 14:25
use string path = Application.StartupPath; please.. and for such small things... just do them. Come to think of it feel free to refactor the classes deriving from audioencoder to improve efficiency..

dimzon
25th January 2006, 14:49
use string path = Application.StartupPath; please.. and for such small things... just do them.
As I said before I just dosn't know - it's a bug or a feature. Using enviroment.CurrentDirectory allows to use multiple MeGUI settings set using different startup folders ;)

By the way - what about my proposal about IAudioSettingsProvider in ComboBox? It will reduce code complexity a lot.

@All Devs (incl Doom9)
Don't get me wrong, I'm looking @ current sources and I have such proposal.
At first let's read such 3 truth:

Every encoder use AviSynth script as input - so we can encode only openable via AviSynth sources
Now MeGUI contains good AVS wrapper with rich diagnostic capabilities
AVS wrapper can parse avisynth scripts from string (you doesn't need temporaly files anymore)

According this staments i propose to remove such unnecesary code from MeGUI. At first I must say - I know You spent time to write it and You are proud by it (and You have a reason to be proud of it bcz PInvoke code sometimes is not easy). But removing such code allows us to simplify MeGUI and improve code maintenance. Less lines of code - less amount of bugs, is'nt it?

So I propose to remove such code:

AviReader.cs - actually we does not need it, AvsReader works fine. Even if you need to open non avisynth file you can use "AviFile(fileName)" without creating temporaly file
DirectShow.cs - now we can just use "DirectShowSource(fileName)"
d2vReader.cs - now we can just use "LoadPlugin(...)\r\nMpeg2Source(fileName)"

dimzon
25th January 2006, 15:30
0.2.3.2048 25 Jan 2006
Commit by dimzon:
- fixed improper path detection when running MeGUI from commandline
- add support for improved accuracy for audio processing via AviSynth
- workaround bug (noise @ the beginning) when using normalization for 16 bit audio
(now if AutoGain is checked 32bit transformation is forced )

klicker4546
25th January 2006, 16:01
Hi dimzon,

is there any guide for the audio processing via Avisynth within MeGUI? I guess I will need behappy to make it work. But how??? :confused:

0.2.3.2048 25 Jan 2006
Commit by dimzon:
- fixed improper path detection when running MeGUI from commandline
- add support for improved accuracy for audio processing via AviSynth
- workaround bug (noise @ the beginning) when using normalization for 16 bit audio
(now if AutoGain is checked 32bit transformation is forced )

Doom9
25th January 2006, 16:03
is there any guide for the audio processing via Avisynth within MeGUI? I guess I will need behappy to make it work. But how???Actually.. just drag & drop an audio file into megui, select the codec, configure the codec.. and suddenly it will become clear ;) Trying just once never hurts.. and this is a thread for developers...

klicker4546
25th January 2006, 16:15
Thanks for your reply Doom9. I've already tried it, without success. That's why
I was asking. I will ask in another thread then. Sorry!

Actually.. just drag & drop an audio file into megui, select the codec, configure the codec.. and suddenly it will become clear ;) Trying just once never hurts.. and this is a thread for developers...

dimzon
25th January 2006, 17:16
Now you could go all the way and change the input checking prior to encoding to make use of it and even check for YV12 input and give the user a specific warning about the colorspace if it doesn't match the one required...
Maybe better way is to patch x264 and xvid_encraw to invoke ConvertToYV12 if colorspace doesn't match the one required?

if (!inf.IsYV12() )
{
res = env->Invoke("ConvertToYV12", AVSValue(&res, 1));
}

Easy, isn't it?

Doom9
25th January 2006, 17:18
well.. considering how many times the error has come up and nothing had been done I doubt there ever will.. we should proceed under the assumption that encoders stay the way they are, and editing and reloading the avs input file.. that's not really the job of an encoder.

dimzon
25th January 2006, 17:27
we should proceed under the assumption that encoders stay the way they are
It means nobody ask encoder developers to add such workaround. It's really easy and costs approx. 5 lines of code in C++ and 10 minutes of time. I can do it myself, just need access to encoder sources ;)
really, it encoder reques avs with yv12 support it means encoder are working with avs via avisynth.dll (there are no other way to get yv12 from it, AviFile32 API performs RGB24 conversion). In this case is pretty easy to invoke additional AviSynth function like ConvertToYV12()...

pest
25th January 2006, 17:47
2 all devs

found such code:
// Directshowsource needs the FPS information to be supplied.
// Without a lot of restructuring of code this is the best way of finding the FPS
// If anyone knows a better way of obtaining Framerate info, change this.
AVIReader reader;
try
{
reader = new AVIReader(fileName);
}
catch (Exception) // Some files can't render because you have no VfW codec (like DV sources)
{
reader = null;
}

AFAIK DiresctShowSource reques explicit fps information in very rare cases. And can't believe AVIFile32 API can return fps for such rare cases at all (AFAIK it even can't read such files)

Correct me if I'm wrong, please! I'm suggesting to remove this code!

Why 2 local objects?



AVIReader *reader=new AVIReader(fileName);

if (!reader) blahblah

dimzon
25th January 2006, 17:50
Why 2 local objects?



AVIReader *reader=new AVIReader(fileName);

if (!reader) blahblah

Sorry, don't understand Your post at all

Mutant_Fruit
25th January 2006, 18:01
I wrote that particular piece of code as DirectShowSource wasn't loading my AVI files at all. It needed me to pass the FPS parameter to it before it would load my AVI files. I can guarantee no-one else spotted this problem before i added that code because the AVS generation was broken in MeGUI for AVI sources, and i only encountered the FPS problem after i fixed the AVS generation for AVI sources.

What do you mean by two local objects? There's only one reader there...

dimzon
25th January 2006, 18:09
I wrote that particular piece of code as DirectShowSource wasn't loading my AVI files at all.
Can you provide me sample AVI file (upload it to mytempdir.com in 7z, max 10-20 MB)

Thanx!

pest
25th January 2006, 18:11
Ups, I forgot you where using C#, perhaps its different than in C++


AVIReader reader;


creates a local object


reader = new AVIReader


creates a reference to a local Object-Pointer

Sorry to confuse you. If your code would create 2 Instances
it wouldn't compile anyway

<- never trys to understand C#

stax76
25th January 2006, 18:43
AVIReader reader;
try
{
reader = new AVIReader(fileName);
}
catch (Exception) // Some files can't render because you have no VfW codec (like DV sources)
{
reader = null;
}

Please note that if a exception is thrown in the ctor no instance is created and reader will stay null.

@pest

Yes, .NET is different. ;)

berrinam
25th January 2006, 22:28
To all devs:
Make more use of "Don't show me this again" in dialogs.
Description: See http://forum.doom9.org/showthread.php?p=772750#post772750
Status: Pending Doom9's approval.
I posted that at the beginning of the Feature Request thread. It's not so much of a feature that can be implemented in one go, because it is really something that should be in every dev's mind while coding. MeGUI is all set up to support these, so people just need to use them.

Also, I think it would generally be a good idea to look at the first post of the Feature Request thread, as there are quite a few new requests (mostly from me), once Doom9 approves them.

berrinam
25th January 2006, 22:43
0.2.3.2049 25 Jan 2006
Commit by berrinam:
-Made the error messages shown for AviSynth more specific
-Drag'n'drop handling starts in a new thread, preventing the window where the drag started from freezing

berrinam
25th January 2006, 22:50
@dimzon: I'm going to put some notes about AviSynth audio encoding on the MeGUI guide. In what situation would someone want to use 'force decoding via directshow'?

berrinam
25th January 2006, 23:09
No-one's made a file release on SourceForge for over a week.
1. Can someone do that.
2. dimzon, can you tell us more about the build facility on SF? I couldn't find anything about it.

Mutant_Fruit
25th January 2006, 23:45
Can you provide me sample AVI file (upload it to mytempdir.com in 7z, max 10-20 MB)

Thanx!
For some strange reason, all the avi's that i threw up the error unless i had the FPS parameter are now working fine without passing the FPS parameter. I assume it must have something to do with my directshow filters... since i created that patch i have reinstalled and deinstalled quite a few filters and parsers as part of a project i'm doing in college.

I suppose that that makes my little addition redundant. I'll investigate further and see if i can figure out why i got the FPS error. But for the moment, i think its looking like that bit of code is just a waste of CPU cycles.

EDIT: Just a heads up, i'm finishing off a report for college, so i should be back into coding again by saturday. So if someone wants to grab the bitrate calculator before then, feel free. Otherwise i'll take a look at it on saturday.

berrinam
26th January 2006, 00:39
0.2.3.2050 26 Jan 2006
Commit by berrinam:
-Fix the MeGUI crash when auto-loading wavs after DGIndexing
-Fix the error when selecting multiple chained jobs and pressing delete

berrinam
26th January 2006, 01:18
It means nobody ask encoder developers to add such workaround. It's really easy and costs approx. 5 lines of code in C++ and 10 minutes of time. I can do it myself, just need access to encoder sources ;)
You can get the x264 sourcecode with SVN:
svn co svn://svn.videolan.org/x264/trunk x264

(from http://developers.videolan.org/x264.html)

However, it may not be such a good idea to add ConvertToYV12 silently, because it means that AviSynth error clips will also be encoded without realising it. In my opinion, a better idea would be for MeGUI to check the colorspace before it sends it to the encoder (I mentioned that here: http://forum.doom9.org/showthread.php?p=772747#post772747), because it should be the GUI's job. If someone knows enough to use the commandline, they will know what a colorspace error is, and they will prefer to know about it, so that they can fix it in a (perhaps) better way than simply converttoyv12.

Inc
26th January 2006, 09:26
AviFile32 API performs RGB24 conversion

Not at all, it depends on how you set up the decompression in AVIStreamGetFrameOpen().

Here a piece of code


BITMAPINFOHEADER bih;
ZeroMemory(&bih, sizeof(BITMAPINFOHEADER));

bih.biBitCount=24; //24 bit per pixel
bih.biClrImportant=0;
bih.biClrUsed = 0;
bih.biCompression = BI_RGB;
bih.biPlanes = 1;
bih.biSize = 40;
bih.biXPelsPerMeter = 0;
bih.biYPelsPerMeter = 0;
//calculate total size of RGBQUAD scanlines (DWORD aligned)
bih.biSizeImage = (((bih.biWidth * 3) + 3) & 0xFFFC) * bih.biHeight ;

PGETFRAME pFrame;

// Let the Handler decide which Colorspace matches best your display:
pFrame=AVIStreamGetFrameOpen(pStream, AVIGETFRAMEF_BESTDISPLAYFMT);

// Or do force the decompressor to use the Cspace as given in the bih above:
pFrame=AVIStreamGetFrameOpen(pStream, &bih);

So If yot want to keep a YV12 as YV12 to serve it to an encoder, just apply to bih a BITMAPINFOHEADER Structure for RAW YV12 decompression or to whatever Cspace you want the stream decompressed to.

This weekend Ill add to the AvsRedirect/AvsWrapper some calls to avs's streamdetection (cspace etc etc etc).
Btw. In the avs_openscript command I did implement a routine so you can force the outputted Cspace via a simple String ("YV12","YUY2", "RGB24", "RGB32"). So depending on the encoder the user choosed you can force in MeGUI to serve the encoders native Cspace.

Doom9
26th January 2006, 11:15
In my opinion, a better idea would be for MeGUI to check the colorspace before it sends it to the encoder I fully agree with that. If using the avisynth script creator, we should do the conversion automatically. In addition, the encoder should check the colorspace before encoding and raise an error in case it's the wrong colorspace. When we make the script creator automatically put the proper commands in the script, the only reason why an error would be raised would be if the user created his own avs script.. I think it's reasonable to expect those people to understand if we write "your avisynth script does not output YV12, please change your script accordingly" to the log.

Inc
26th January 2006, 11:46
Not shure, but AFAIK also Qenc.'s avs script input parser automatically adds an ConverttoYV12() if the incoming script doesn't result in a YV12 Cspace.

dimzon
26th January 2006, 11:51
@dimzon: I'm going to put some notes about AviSynth audio encoding on the MeGUI guide. In what situation would someone want to use 'force decoding via directshow'?
By default MeGUI trying to use MPASource for mpeg audio, NicAc3Source for ac3, NicDtsSource for dts, WAVSource for wav, Import for AVS and DirectShowSource otherwise. Checking 'force decoding via directshow' will switch to DirectShowSource for any file (including MP3, AC3 etc). It can be used for advanced audio processing (using FFDSHOW) for example. Another usecase if AviSynth Source Plugin is buggy but you still able to play source file via DirectShow - you can switch to DirectShow for decoding

Actually, it *should* pick up wav audio, too:
if (file.IndexOf(trackNumber) != -1 &&
(file.EndsWith(".ac3") ||
file.EndsWith(".mp3") ||
file.EndsWith(".mp2") ||
file.EndsWith(".mpa") ||
file.EndsWith(".dts") ||
file.EndsWith(".wav"))) // It is the right track
{
audioFiles.Add(file);
}However, that code is case sensitive, which means it requires the extension to be in lower case (that's the bug).


2all devs!
I have found a huge amount of such extension-checking code spreaded by the sources. I propose such replacement for it:

// In some utrility class
public static string[] ListOfAudioExtensions = new string[]{".mp3", ..., ".dts"}

public static bool HasExtension(string fileName, string[] ExtensionList)
{
...
}

//Using
if(Utility.HasExtension(file, Utility.ListOfAudioExtensions))
{
...
}



No-one's made a file release on SourceForge for over a week.
1. Can someone do that.
2. dimzon, can you tell us more about the build facility on SF? I couldn't find anything about it.
http://sourceforge.net/docs/compile_farm
Unfortunally there no Win32 support ATM :scared:


I fully agree with that. If using the avisynth script creator, we should do the conversion automatically.
Ok. Since x264 use AVIFile32 API we have not another choice...

kritip
26th January 2006, 13:28
Unfortunally there no Win32 support ATM :scared:


I didn't read the whole article, but couldn't one of the x86 machine, if its running gcc, just cross compile for win32, pretty sure gcc can do that. Wether you can on the sourceforge system is another matter though.

KriTip

dimzon
26th January 2006, 13:49
I didn't read the whole article, but couldn't one of the x86 machine, if its running gcc, just cross compile for win32, pretty sure gcc can do that. Wether you can on the sourceforge system is another matter though.

KriTip
Unfortunally there are not .NET 2.0 support for non Win32 (AFAIK Mono implements 1.1 only)

Doom9
26th January 2006, 13:50
since when can gcc handle c# and windows .net libs?
I got a PM this morning from somebody willing to volunteer to do the build stuff.. the question is how we get the sources to him and where we publish the builds. I suppose there's some webadmin function on sourceforge so the releases could probably be put on the webspace that's currently not in use.. but what about the sources considering the anonymous CVS is down half the time? Is there any automatic source export.. like press a button and get a zip file with the latest CVS checkout?

Doom9
26th January 2006, 13:52
I have found a huge amount of such extension-checking code spreaded by the sources. I propose such replacement for it:The problem with that is.. often these checks go only over a limited amount of extensions.. as in "if it's .mp3 or .ac3 you can put it into avi.. if it's anything else you cannog", and "if it's .aac or .mp4 you can put it into mp4, otherwise not".

kritip
26th January 2006, 13:52
please delete this post

kritip
26th January 2006, 13:52
Indeed your both correct :) I'll shut up from now on ;)

KriTip

berrinam
26th January 2006, 13:55
since when can gcc handle c# and windows .net libs?
I got a PM this morning from somebody willing to volunteer to do the build stuff.. the question is how we get the sources to him and where we publish the builds. I suppose there's some webadmin function on sourceforge so the releases could probably be put on the webspace that's currently not in use.. but what about the sources considering the anonymous CVS is down half the time? Is there any automatic source export.. like press a button and get a zip file with the latest CVS checkout?
I'm pretty sure that you can grant someone developer read-only CVS access. If you register them as part of the project, then wouldn't that be a solution?

dimzon
26th January 2006, 13:56
0.2.3.2051 26 Jan 2006
Commit by dimzon
-Rewritten AvisynthWrapper.dll (now it will be more friendly with multithread code)
-Rewritten AvisynthWrapper.cs (to use new API from AvisynthWrapper.dll)


The problem with that is.. often these checks go only over a limited amount of extensions.. as in "if it's .mp3 or .ac3 you can put it into avi.. if it's anything else you cannog", and "if it's .aac or .mp4 you can put it into mp4, otherwise not".


ListOfAllAudioExtensions = new string[]{...}
ListOfAudioInAviExtenssions = new string[]{"mp3","ac3"}
ListOfAudioInMp4Extenssions = new string[]{"aac","mp4","m4a"}

e.t.c.

the main goal is to collect all of supported extensions in just one place

Doom9
26th January 2006, 14:24
If you register them as part of the project, then wouldn't that be a solution?If that is possible, then it would indeed be a solution.

the main goal is to collect all of supported extensions in just one placeIt may only be a stopgap solution (in the end, wouldn't it be convenient when needed, the app could ask for Muxer.getMuxer(MuxType), and then do a Muxer.getSupportedExtensions, or Muxer.IsInputSupported.

Keep in mind though, since code is replicated in so many places.. there's a lot of testing you will have to do to make sure your changes don't break anything anywhere.