MeGUI development [Archive] - Page 37

berrinam

18th February 2006, 13:42

@devs: Can you look over at my post here (http://forum.doom9.org/showthread.php?p=787266#post787266)? I meant to post it in this thread, but I posted it in the wrong place. I left it there because it seems somewhat appropriate, so can you look over there anyway?

@dimzon: I was looking through the audio encoder code to see how to add the various forms of upmixing to the AviSynth Script Creator. I don't really like the current way it works: you have all the required filters embedded in your AviSynth script, which means that (a) if the script were actually written to a file, it would be unnecessarily long, (b) no-one else can access the filters, because they are hidden by MeGUI, and (c) they can't be replaced or tweaked by the savvy user.

What I propose is that they be exported as actual scripts (*.avsi files) which be put in the AviSynth plugins directory, and they will be autoloaded. When we get AutoUpdate from Mutant_Fruit, it can be joined into that. I also think it would be a good idea to refactor the audio processing into the ScriptServer class, just like denoising and resizing. Of course, that depends on the response to the post I linked to above.

I also don't think that GUID mess is really a good idea once users start to look at the scripts. Shouldn't those mixing filters be just like any other filters and the authors (whoever they are) should be responsible for not naming them in ways that clash?

Sharktooth

18th February 2006, 13:52

could anyone review the status of those uncommitted patches and eventually (if ok) commit them so we can close them and go for the next "stable" release before implementing new features.

Mutant_Fruit

18th February 2006, 19:28

Ok, i've been quite busy over the last two weeks finishing off a college assignment, but i've finally got around to having a working "beta" of the AutoUpdate.

Check the form1 Load event to see where i initially call the updater. Please, feel free to bitch and moan about how i didn't do this or didn't do that. I wouldn't be surprised if i did things in a roundabout kinda way.

Even if ye don't want to use this code, any pointers on how i could make it better would be greatly appreciated.

Currently nothing is being written to the log textbox, but that will change soon. Also, i amn't saving the settings to a file yet (but i have written code to load the settings :rolleyes:). Break it in any way you can. And any advice on improving (or complaining about how a certain section is just stupid) is appreciated.

http://www.fileshack.us/files/741/AutoUpdate.zip

EDIT: The XML file and "updated versions" can be found on http://megui.org if you want to take a look at what i have there.

EDIT: At the moment only 7-8 files are supported for the AutoUpdate, but this could be extended to any file that MeGUI uses (i.e. lame, avisynth and whatever else you please)

dimzon

19th February 2006, 13:00

@dimzon: I was looking through the audio encoder code to see how to add the various forms of upmixing to the AviSynth Script Creator. I don't really like the current way it works: you have all the required filters embedded in your AviSynth script, which means that (a) if the script were actually written to a file, it would be unnecessarily long, (b) no-one else can access the filters, because they are hidden by MeGUI, and (c) they can't be replaced or tweaked by the savvy user.
At first you must realize - current solution is JUST A FAST HACK to add AviSynth audio to current MeGUI architecture to avoid any significant refactoring (Doom9 ask me about it)

Just spent 1-2 hours to take look @ BeHappy and BeHappy source - there are another and much more flexible way for it. Maybe we can use same ideology in MeGUI?

Sharktooth

19th February 2006, 17:16

sourceforge added the possibility to migrate from cvs to svn.
docs are here:
http://sourceforge.net/docs/E09/en/#use

i propose the migration to SVN since it's faster and it's much better than CVS.
opinions?

dimzon

19th February 2006, 19:00

Sharktooth

19th February 2006, 19:36

CVS Update:

0.2.3.2092 19 Feb 2006
Commit by Sharx1976:
- Fixed a few bugs with number of frames changing from what the user inserts (patch by Mutant_Fruit).

ChronoCross

19th February 2006, 22:54

I'll make a build as soon as I get caught up. I was out of town for the weekend.

Doom9

20th February 2006, 13:02

what about tools to use svn? and I guess most importantly: is the anonymous svn any better than the anonymous cvs (which by all reports sucks big time as it's almost never online).

dimzon

20th February 2006, 13:05

what about tools to use svn? and I guess most importantly: is the anonymous svn any better than the anonymous cvs (which by all reports sucks big time as it's almost never online).
As I said before take look @ SVN limitation first
and I still worry about losing previous history during migration

Sharktooth

20th February 2006, 14:14

what about tools to use svn? and I guess most importantly: is the anonymous svn any better than the anonymous cvs (which by all reports sucks big time as it's almost never online).
if you use tortoisecvs then there's tortoisesvn. or classic svn commandline tools.
for example videolan uses svn.
for what concerns the anonymous svn on SF, well... i dont know.

Doom9

20th February 2006, 15:09

As I said before take look @ SVN limitation firstNothing listed there really has me concerned. But then again I also haven't seen any advantages yet.

BTW, an update on the refactoring: I've been sick since Wednesday and prior to that didn't have the motivation (plus that week-end before I had a little party with the usual after effects that prevent you from doing anything really productive the day after) to get much done. Right now, video encoding is working, including an automatic container dropdown selection in function of whatever encoder can be found for the desired codec. I've finally settled for doing this for audio as well, but there we mostly have no container, and only offer container selection in case of MP4 (I'm afraid AAC in AVI requires raw AAC).. MP4 will be the default though (you just have to register the mp4 container before the none container when registering the avisynth audio encoder). Other than that I have the muxpath selection code written but that's it. And right now I feel like shit so I'm not much for doing anything productive for work so naturally nothing goes for megui either :(

Sharktooth

20th February 2006, 15:45

Nothing listed there really has me concerned. But then again I also haven't seen any advantages yet.
better revisioning system, easier management, faster access (except the SF svn server box is slower so it will be basically as fast as cvs for now), less crashing, better win32 client with more functionalities, better patching system (svn diff will automatically produce a unified diff from your local copy and the svn repository), etc....

dimzon

20th February 2006, 21:23

white = Blankclip(white) #pseudo-code
black = blankclip(black) #pseudo-code
conditionalfilter(inputclip, white, black, "YDifferenceFromPrevious*0.5 + UDifferenceFromPrevious*.25 + VDifferenceFromPrevious*.25", "<", ".5")
I don't see why your C++ code would be faster than Assembly-optimized AviSynth code.
Maybe You are right
I'm worry about possible overhead caused by AviSynth itself especially conditionalfilter. Maybe we need AviSynth developers consultation?

dimzon

20th February 2006, 21:38

@berrinam
maybe we can use FrameEvaluate instead of ConditionalFilter to set global variable
FrameEvaluate(inputclip,"global g_bIsSceneChange = ( YDifferenceFromPrevious*0.5 + UDifferenceFromPrevious*.25 + VDifferenceFromPrevious*.25 < .5)?false:true")
in this case I can add special method to AviSynth wrapper to allow read-only access to global numeric/bool/string variables :cool:

berrinam

20th February 2006, 23:36

I'm worry about possible overhead caused by AviSynth itself especially conditionalfilter. Maybe we need AviSynth developers consultation?Yes, there could be some form of overhead. I agree that FrameEvaluate would be a better way, if possible.
@berrinam
maybe we can use FrameEvaluate instead of ConditionalFilter to set global variable
FrameEvaluate(inputclip,"global g_bIsSceneChange = ( YDifferenceFromPrevious*0.5 + UDifferenceFromPrevious*.25 + VDifferenceFromPrevious*.25 < .5)?false:true")
in this case I can add special method to AviSynth wrapper to allow read-only access to global numeric/bool/string variables :cool:
Yes, if you can do that, that is a better way. I didn't think that was possible, but if you can do it, that's great. Once you've done that, we could also use that for automatic source detection, because that uses frame evaluate and outputs the results to a temp file.... skipping the temp file would be nice.

@all devs: Also, what do you think about what I proposed on the Guide thread? I suggested that we replace MeGUI's cropping and resizing code with AviSynth. I'm sure it would be much faster.

dimzon

20th February 2006, 23:49

@all devs: Also, what do you think about what I proposed on the Guide thread? I suggested that we replace MeGUI's cropping and resizing code with AviSynth. I'm sure it would be much faster.
I must take look @ current code first but i do not think it would be too much faster.

Richard Berg

21st February 2006, 04:01

Why should MeGUI do its own cropping & resizing? That sounds like a really bad idea. What advantage would that have? Who would write that code? Would it handle all colorspaces correctly? Would it obey all of Avery's guidelines (http://www.virtualdub.org/blog/pivot/entry.php?id=86#body)? Would it be faster than all of Avisynth's ASM routines?

berrinam

21st February 2006, 06:09

I must take look @ current code first but i do not think it would be too much faster.Not faster? MeGUI is written in the slow C#, whereas AviSynth is ASM optimized. Just as Richard says,
Would it be faster than all of Avisynth's ASM routines?

I can see the overheads: a new filter would have to be applied every time the cropping or size is changed, and perhaps the entire filter-chain would have to be re-rendered. But still, the AviSynth cropping and resizing functions are definitely faster than the MeGUI/C# ones, so if there was a way to run specific filters on a source of your choice, then it would be faster (something like the way you always convert the output to the same colorspace for previewing). Basically, the idea is that we could replace the two functions, VideoUtil.crop and VideoPlayer.resizeBitmap, with AviSynth's cropping and resizing functions respectively. I don't see how that would be slower, if it were possible.

Why should MeGUI do its own cropping & resizing?Well, it currently does (not on the final file, but for previewing in the AviSynth creator, and in the main window). The cropping code was written by Doom9 as an adaptation from the GK one, and I made it significantly faster by using unsafe code in C#. The resizing code uses C#'s bilinear resizing. The other issues you mentioned are not a problem, because they it is just used for the preview, not the final thing.

dimzon

21st February 2006, 08:42

I can see the overheads: a new filter would have to be applied every time the cropping or size is changed, and perhaps the entire filter-chain would have to be re-rendered.
Yes, I mean exatly this. Dont't take me wrong BUT recreate/reparse AviSynth every time when you rerform resize/cropping and re-rendering filter chain - it cam be a real CPU killer for slow scripts (like my scripts are - i'm using fft3dfilter)
I see realiy yet another solution for it:

AviSynthClip original = ....;
...
AviSynthClip resized = original.Execute("bilinearresize(640,480)");

unfortunally this approach requres significant research and changes in AviSynth wrapper. And there can be threading issues...

berrinam

21st February 2006, 10:17

Yes, I mean exatly this. Dont't take me wrong BUT recreate/reparse AviSynth every time when you rerform resize/cropping and re-rendering filter chain - it cam be a real CPU killer for slow scripts (like my scripts are - i'm using fft3dfilter).Yes, I can see that clearly is a problem. However, for cropping, that should never happen -- the preview for cropping should only have a source filter. I think that the preview in the AviSynthWindow could certainly benefit from this sort of thing, even if not the preview for the main form.

Also, the current situation suffers from this problem, too; for resizing and recropping, the image is re-requested from AviSynth, but this problem may be alleviated by AviSynth's internal caching.

I see realiy yet another solution for it:

AviSynthClip original = ....;
...
AviSynthClip resized = original.Execute("bilinearresize(640,480)");

unfortunally this approach requres significant research and changes in AviSynth wrapper. And there can be threading issues...That is the sort of thing that I was talking about. I still don't know how plausible it is, but now we at least agree with each other.

dimzon

21st February 2006, 10:23

Yes, I can see that clearly is a problem. However, for cropping, that should never happen -- the preview for cropping should only have a source filter
Source can be other AVS including slow filters

but now we at least agree with each other
Yes

Richard Berg

21st February 2006, 17:51

Ok, so it's just for preview. Why not use the videocard to scale then? Heck, we could even use VMR9 -- we already require .Net 2.0 so requiring DX9 is no big deal.

Doom9

21st February 2006, 18:21

I got lost about 1.5 pages ago.. one post seems to have no relation to the next and I'm supposed to see posts and only Swede, bond and myself can physically delete messages in this subforum..

Richard Berg

21st February 2006, 18:31

Well, that's what happens when you put discussion about the entire product into one thread. FWIW, I was talking about how to get rid of the custom resizer code that's apparently in MeGUI. Since it's used for playback, the obvious answer is to let the playback control handle scaling.

stax76

21st February 2006, 19:16

I'm using like AutoGK the AutoCrop filter for auto crop.

For fast drawing I access private .NET internals with Reflection:

Public Function GetBMPFromDib(ByVal pDIB As IntPtr) As Bitmap
Dim pPix As IntPtr = New IntPtr(pDIB.ToInt32() + Marshal.SizeOf(GetType(BITMAPINFOHEADER)))

Dim mi As MethodInfo = GetType(Bitmap).GetMethod("FromGDIplus", BindingFlags.Static Or BindingFlags.NonPublic)

Dim pBmp As IntPtr = IntPtr.Zero
Dim status As Integer = GdipCreateBitmapFromGdiDib(pDIB, pPix, pBmp)

Return CType(mi.Invoke(Nothing, New Object() {pBmp}), Bitmap)
End Function

To draw cropped and scaled I'm using this code:

Dim factorX As Single = CSng(Control.Width) / img.Width
Dim factorY As Single = CSng(Control.Height) / img.Height

Dim left As Single = CropLeft * factorX
Dim right As Single = CropRight * factorX
Dim top As Single = CropTop * factorY
Dim bottom As Single = CropBottom * factorY

Dim rectDest As RectangleF = New RectangleF()

rectDest.X = left
rectDest.Y = top
rectDest.Width = Control.Width - left - right
rectDest.Height = Control.Height - top - bottom

Dim rectSrc As Rectangle = New Rectangle()

rectSrc.X = CropLeft
rectSrc.Y = CropTop
rectSrc.Width = img.Width - CropLeft - CropRight
rectSrc.Height = img.Height - CropTop - CropBottom

g.DrawImage(img, rectDest, rectSrc, GraphicsUnit.Pixel)

Dim sb As SolidBrush = New SolidBrush(Color.White)

g.FillRectangle(sb, 0, 0, left, Control.Height)
g.FillRectangle(sb, 0, 0, Control.Width, top)
g.FillRectangle(sb, Control.Width - right, 0, right, Control.Height)
g.FillRectangle(sb, 0, Control.Height - bottom, Control.Width, bottom)

All this is pretty fast as StaxRip demonstrates.

dimzon

21st February 2006, 19:32

For fast drawing I access private .NET internals with Reflection
This is a really dirty hack! Do not use it!

Richard Berg

21st February 2006, 20:25

I still don't understand why we'd stoop to the level of writing resizer code, blitting raw DIBs to the screen, etc. That's what DirectX is for.

Doom9

21st February 2006, 20:46

finally some good news from the refactoring front: audio now uses the same logic as video.. codecs and encoders are registered, and upon selecting an audio codec, the supported output types (containers) are gotten. Audio input and output filters are set according to whatever an encoder supports and audio job generation now fully resides outside form1.

I don't think at this point it makes a lot of sense to argue about resizing. Have a mouthful of this: currently we have a preview with intro/credits setting preview, another one for zones, and another one for plain preview without any possibility to set anything. On top of that there will be a cutter window as well. Now, when should they be accessible, does it make sense to limit their number, and where are the individual settings saved (intro/credits, zones, cutlists)?
Who cares if the resizeable preview is a bit slower than it can be.. those are just beautifying issues that can be looked into if there are no open feature requests and bugs and no more oustanding refactoring.. now when the whole project is in the thick of all of those categories.

dimzon

21st February 2006, 21:22

@Doom9
talking about RAW AAC output - i don't like it bcz we need explicit SBR signaling.
In this case I propose to use special markers in filename:
bla-bla-bla (SBR).aac

Richard Berg

21st February 2006, 21:23

Well, if it's already done, then so be it. Don't mess with it unless it's broken or too slow.

Doom9

21st February 2006, 21:25

i don't like it bcz we need explicit SBR signaling.The default is MP4 output for all encoders (well... you can control that by the order in which you send back the container types when you register the output types with the encoder). The thing is I need raw aac for aac in avi.. other than that.. it's the users fault if he screws things up.. we can only do so much to prevent people from doing stupid things. And of course.. when I create the muxjob I can set that flag manually when I look at the audio streams..

stax76

21st February 2006, 21:33

This is a really dirty hack! Do not use it!

My code is full of hacks and dirty tricks like cloning complex object graphs with serialization or comparing complex object graphs with reflection, or aborting by throwing exceptions, not everybody considers that as hack by the way ;)

Sharktooth

22nd February 2006, 23:13

CVS update:

0.2.3.2093 22 Feb 2006
Commit by Sharx1976:
- Fixed a bug in the calculator introduced in 0.2.3.2092 (patch by Mutant_Fruit).

berrinam

23rd February 2006, 10:30

0.2.3.2094 23 Feb 2006
Commit by berrinam:
- Fixed bug in 'One Click Profile Setup' which didn't allow selected profile to be selected

Sharktooth

23rd February 2006, 10:45

i cleaned the SF patches section a bit.
There are still 2 patches there, any comments?

@berrinam: what does your previous post mean? it should be 2094, not 2092...

note:
CVS Update:

0.2.3.2092 19 Feb 2006
Commit by Sharx1976:
- Fixed a few bugs with number of frames changing from what the user inserts (patch by Mutant_Fruit).

berrinam

23rd February 2006, 11:01

@berrinam: what does your previous post mean? it should be 2094, not 2092...Yep, typo.... fixed.

Doom9

23rd February 2006, 11:02

@berrinam: I've been meaning to make some suggestion to the one click tool (which I still consider your baby.. I may have messed it all up twice now but that only makes the mess mine): 1) Enable the codec dropdown and make it limit the video profiles that remain accessible (aking to limiting profiles when you enter a codec configuration dialog), 2) have two audio profiles so that the two audio tracks can have different settings, 3) Upon selecting the container, limit the audio profiles to whatever's supported (that really goes into territory I'm currently working on).
Let me elaborate three: What do you guys (all developers) think about the following workflows:
1) a: user selects video codec, b: user selects audio codec, c: user selects container, d: megui picks the proper output type for audio and video (that's the most complex case.. as you know we can have .264/mp4/mkv output from x264.exe for instance and .aac or .mp4 output from nero/faac)
2) a: user selects video codec, b: user selects video output type (basically container.. but I call it type because there are two types of no container, raw avc and raw asp), c: user selects audio codec, d: user selects audio output type (same logic as for video), e: megui offers compatible containers (if any). This is what I currently have mostly working for the one click mode
3) a: user selects container, b: megui limits audio and video codec selection to whatever it can accomodate with the existing muxers, c: user makes further choices in audio/video codec and output types

Keep in mind, all three are done fully automatic.. there's a videoencoderprovider, an audioencoderprovider and a muxprovider and between the three of them, they do all the work (so you can ask the muxprovider questions like "I have a raw avc stream, two mp3 streams, what can you mux that into?)

Doom9

23rd February 2006, 11:06

about the patches: 1408670: that's by design and should not be removed. Plus, it's already a moot point as that restriction will be gone with my next commit (when that will be, god only knows.. once again I managed to set out to do something and end up doing something else completely.. making the whole setup structure flexibly.. yesterday I completely rewrote all bitrate calculation routines even to adapt to that new flexibility.. now even if at some point I should fall on my head and relax the two audio stream restriction, the calculator can accomodate that now with no changes (except the gui needs changes of course)).
Hasn't 1417477 already been integrated?

berrinam

23rd February 2006, 11:12

Doom9

23rd February 2006, 11:26

[quote]except that 2) allows more customisability in container formats, and 1) is easier for beginners.[quote]Actually, 2) places additional limitations because the video and audio output types have already been chosen. E.g. AACinMP4 is a nogo if you're aiming for AVI (avimuxgui does raw aac only), and similarly, currently rawaac is a nogo for mkv/mp4 (not because the muxers can't handle it, but because I block it and will only allow it when I'm ready to automatically send the SBR flag to the muxer along with the audio stream to ensure proper flagging in all cases.. aacinmp4 requires no such flagging).

But 1) is the most complex.. when you go auto mode, you disregard output extensions completely and have to redo everything manually (well.. you ask muxer and encoder providers what they can do and somehow try to match it, then apply whatever changes need to be done because when you go from the main gui to the autoencode window, the output types are already given).

Sharktooth

23rd February 2006, 11:30

ok... all patches on SF have been "closed".

ChronoCross

23rd February 2006, 19:20

0.2.3.2094 23 Feb 2006
Commit by berrinam:
- Fixed bug in 'One Click Profile Setup' which didn't allow selected profile to be selected

Sharktooth

23rd February 2006, 20:31

it should be 0.2.3.2095...

EDIT: ehr... no.

ChronoCross

23rd February 2006, 20:40

From #x264:
[01:35] > sharktooth: the version count is off on megui. someone doubled up numbers
[01:37] > sharx1976 got confused when he committed.
[01:38] > then berrinam only looked at the next one down (where the numbering was wrong) so he committed under 2094 rather than 2095

This might be intentional numbering if the commit of 2093 was only slightly corrected, which I think it was because he commited nearly the same thing 2 minutes later with a one line offset.