MeGUI development

[berrinam]

Originally Posted by dimzon

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.

Originally Posted by dimzon

@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

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]

Originally Posted by berrinam

@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]

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? Would it be faster than all of Avisynth's ASM routines?

[berrinam]

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.

Originally Posted by Richard Berg

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]

Originally Posted by berrinam

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]

Originally Posted by dimzon

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]

Originally Posted by berrinam

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

Originally Posted by berrinam

but now we at least agree with each other

Yes

[Richard Berg]

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]

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]

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]

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]

Originally Posted by stax

For fast drawing I access private .NET internals with Reflection

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

[Richard Berg]

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]

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]

@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]

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

[Doom9]

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]

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]

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]

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