Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Capturing and Editing Video > Avisynth Development

Reply
 
Thread Tools Search this Thread Display Modes
Old 23rd December 2011, 22:20   #281  |  Link
IanB
Avisynth Developer
 
Join Date: Jan 2003
Location: Melbourne, Australia
Posts: 3,167
Yes as G. says on the Hex/HexValue.

The duplicate code seems to be from a bygone era, Diff.

Log
Code:
Revision 1.3.2.3 - (view) (download) (as text) (annotate) - [select for diffs]
Mon Nov 25 17:00:50 2002 UTC (9 years ago) by sh0dan
Branch: avisynth_2_1
Branch point for: struct_mod
Changes since 1.3.2.2: +29 -0 lines
Diff to previous 1.3.2.2 , to branch point 1.3

Merged latest 2.07 changes (script, color options, parser options).
Handmerged, so there might be a slip or two (seems to work though)

Last edited by IanB; 27th April 2012 at 22:58. Reason: Wrapped long line
IanB is offline   Reply With Quote
Old 6th January 2012, 21:42   #282  |  Link
redfordxx
Registered User
 
Join Date: Jan 2005
Location: Praha (not that one in Texas)
Posts: 863
I am sorry if it is wrong thread for this but I don't know if the following is bug report or my stupidity:

This testclip crashes both MeGui and AvsPMod
Code:
r1=BlankClip(pixel_type="YV12")
r2=BlankClip(pixel_type="YV12",color=$dddddd)

r1=r1.ScriptClip("Subtitle(String(LumaDifference(r1,r2)))")
r1
However, this works fine:
Code:
r1=BlankClip(pixel_type="YV12")
r2=BlankClip(pixel_type="YV12",color=$dddddd)

r1.ScriptClip("Subtitle(String(LumaDifference(r1,r2)))")
Thanx for comment...
redfordxx is offline   Reply With Quote
Old 6th January 2012, 22:56   #283  |  Link
Gavino
Avisynth language lover
 
Join Date: Dec 2007
Location: Spain
Posts: 3,431
Quote:
Originally Posted by redfordxx View Post
This testclip crashes both MeGui and AvsPMod
Code:
r1=BlankClip(pixel_type="YV12")
r2=BlankClip(pixel_type="YV12",color=$dddddd)

r1=r1.ScriptClip("Subtitle(String(LumaDifference(r1,r2)))")
r1
That's because the 'r1' used in the LumaDifference() is evaluated at run-time and refers to the value at the end of the outer script. This sets up a loop in the run-time filter chain since r1 is the result of the ScriptClip() call - leading to ScriptClip requesting a frame from itself, an infinite recursion.

In the second example, r1 is not reassigned, so still has its original value when LumaDifference is evaluated.

See http://avisynth.org/mediawiki/The_sc...untime_scripts.
This is an example of what I call the 'variable binding problem' and was one of the motivations for GRunT.
Using GRunT, the problem is avoided by writing
Code:
r1=r1.ScriptClip("Subtitle(String(LumaDifference(r1,r2)))", args="r1")
which ensures the binding of r1 is done at compile-time, ie its value at that point in the script is used.

EDIT: But actually, for this example, you don't need to use r1 inside the run-time script, since it is also the input to ScriptClip and hence is available inside as 'last':
Code:
r1=r1.ScriptClip("Subtitle(String(LumaDifference(last,r2)))")
__________________
GScript and GRunT - complex Avisynth scripting made easier

Last edited by Gavino; 6th January 2012 at 23:03.
Gavino is offline   Reply With Quote
Old 13th January 2012, 22:07   #284  |  Link
Nickliverpool
Registered User
 
Join Date: Oct 2010
Location: Russia
Posts: 1
Hello, is this a bug? I think it's a bug

Code:
in = FFmpegSource2("F:\BigBuckBunny_320x180.mp4")
in_r = in.ConvertToYV24(chromaresample="point").ConvertToYV12(chromaresample="point")
Subtract(in, in_r)


and...
Code:
i = ImageSource("p.bmp").ConvertToYV24(chromaresample="point")
i_u = i.UToY()
i_v = i.VToY()
i_y = i.Grayscale()

i2 = i.ConvertToYUY2(chromaresample="point").ConvertToYV24(chromaresample="point")
i2_u = i2.UToY()
i2_v = i2.VToY()
i2_y = i2.Grayscale()

i12 = i.ConvertToYV12(chromaresample="point").ConvertToYV24(chromaresample="point")
i12_u = i12.UToY()
i12_v = i12.VToY()
i12_y = i12.Grayscale()

w = 128
h = 64
StackHorizontal(i.PointResize(w,h),i2.PointResize(w,h), i12.PointResize(w,h))
StackHorizontal(i_u.PointResize(w,h),i2_u.PointResize(w,h), i12_u.PointResize(w,h))
StackHorizontal(i_v.PointResize(w,h),i2_v.PointResize(w,h), i12_v.PointResize(w,h))
The source image:
The result:




Nickliverpool is offline   Reply With Quote
Old 13th January 2012, 23:33   #285  |  Link
Gavino
Avisynth language lover
 
Join Date: Dec 2007
Location: Spain
Posts: 3,431
Quote:
Originally Posted by Nickliverpool View Post
Hello, is this a bug? I think it's a bug
I don't.
Because of differing vertical chroma placement in YV12, conversion between YV24 and YV12 with chromaresample="point" effectively introduces a chroma shift.
There is no shift with YUY2, as it has the same placement as YV24 (but with half the chroma missing of course).
__________________
GScript and GRunT - complex Avisynth scripting made easier

Last edited by Gavino; 13th January 2012 at 23:37.
Gavino is offline   Reply With Quote
Old 13th January 2012, 23:54   #286  |  Link
gyth
Registered User
 
Join Date: Sep 2011
Posts: 86
ChromaOutPlacement is ineffectual.

Code:
ImageSource("91182967.png").ConvertToYV24(chromaresample="point")

StackVertical(\
StackHorizontal(ngc("MPEG2","MPEG2"),ngc("MPEG2","MPEG1"),ngc("MPEG2","DV")),\
StackHorizontal(ngc("MPEG1","MPEG2"),ngc("MPEG1","MPEG1"),ngc("MPEG1","DV")),\
StackHorizontal(ngc("DV","MPEG2"),ngc("DV","MPEG1"),ngc("DV","DV")))

function ngc(clip c, string s1, string s2){
    c
    ConvertToYV12(chromaresample="point",ChromaOutPlacement=s1)
    ConvertToYV24(chromaresample="point",ChromaInPlacement=s2)
    PointResize(128,64)
}


P.S. The blocks in the original image are 2x2, so this conversion isn't necessarily lossy.

Last edited by gyth; 14th January 2012 at 00:03.
gyth is offline   Reply With Quote
Old 14th January 2012, 00:47   #287  |  Link
IanB
Avisynth Developer
 
Join Date: Jan 2003
Location: Melbourne, Australia
Posts: 3,167
Point resampling cannot do the required sub-pixel shifting. Point resampling is also known as nearest neighbour.
IanB is offline   Reply With Quote
Old 14th January 2012, 01:25   #288  |  Link
Gavino
Avisynth language lover
 
Join Date: Dec 2007
Location: Spain
Posts: 3,431
Quote:
Originally Posted by gyth View Post
ChromaOutPlacement is ineffectual.

P.S. The blocks in the original image are 2x2, so this conversion isn't necessarily lossy.
I believe it is working correctly.
Precisely because of the 2x2 blocks in the original,
ConvertToYV12(chromaresample="point",ChromaOutPlacement=s1)
gives the same results for all 3 values of s1.
__________________
GScript and GRunT - complex Avisynth scripting made easier
Gavino is offline   Reply With Quote
Old 14th January 2012, 02:21   #289  |  Link
gyth
Registered User
 
Join Date: Sep 2011
Posts: 86
Quote:
Originally Posted by IanB View Post
Point resampling cannot do the required sub-pixel shifting.
Would a feature request for ChromaInPlacement="Point" make sense?
Code:
L1 L2 L3 L4
C1    C2
L5 L6 L7 L8
L9 LA LB LC
C3    C4
LD LE LF L0
"MPEG2" applies C1 to L5, L6, L9, LA
"Point" would apply C1 to L1, L2, L5, L6

But anyway, you can just shift the chroma back.
Code:
ImageSource("91182967.png")
ConvertToYV24(chromaresample="point")
ConvertToYV12(chromaresample="point")
ConvertToYV24(chromaresample="point")
w=width
h=height
MergeChroma(last,last.pointresize(w,h, 0,1, w,h))
PointResize(128,64)

Last edited by gyth; 14th January 2012 at 02:51.
gyth is offline   Reply With Quote
Old 14th January 2012, 02:32   #290  |  Link
gyth
Registered User
 
Join Date: Sep 2011
Posts: 86
Quote:
Originally Posted by Gavino View Post
I believe it is working correctly.
Precisely because of the 2x2 blocks in the original,
ConvertToYV12(chromaresample="point",ChromaOutPlacement=s1)
gives the same results for all 3 values of s1.
Yes, ChromaOutPlacement is choosing the effective location the chroma is being pulled from. And since it is pointwise pulling from a square of uniform color it should always give the same result. Ok, that makes more sense.
gyth is offline   Reply With Quote
Old 14th February 2012, 11:36   #291  |  Link
Selur
Registered User
 
Selur's Avatar
 
Join Date: Oct 2001
Location: Germany
Posts: 7,259
Don't know for sure if this is known, but when calling:
Code:
LoadPlugin("G:\Hybrid\avisynthPlugins\DGDecode.dll")
LoadPlugin("G:\Hybrid\avisynthPlugins\decomb.dll")
MPEG2Source(d2v="D:\Encoding Temp\dolbyegypt_41.d2v")
Telecide()
I get a green bar (multiple lines) at the bottom of the page. (does not happen with Avisynth 2.5.8)
-> seems like a bug in Avisynth 2.6

Cu Selur

Ps.: as source I used: http://www.digital-digest.com/movies...php?type=dolby -> Dolby Digital - Egypt
__________________
Hybrid here in the forum, homepage
Selur is offline   Reply With Quote
Old 14th February 2012, 21:29   #292  |  Link
IanB
Avisynth Developer
 
Join Date: Jan 2003
Location: Melbourne, Australia
Posts: 3,167
Decomb, yet another package that foolishly assumes UVpitch = Ypitch/2
Code:
LoadPlugin("G:\Hybrid\avisynthPlugins\DGDecode.dll")
LoadPlugin("G:\Hybrid\avisynthPlugins\decomb.dll")
MPEG2Source(d2v="D:\Encoding Temp\dolbyegypt_41.d2v")
Telecide()
SetPlanarLegacyAlignment(True)

Last edited by IanB; 15th February 2012 at 01:53.
IanB is offline   Reply With Quote
Old 15th February 2012, 06:26   #293  |  Link
Selur
Registered User
 
Selur's Avatar
 
Join Date: Oct 2001
Location: Germany
Posts: 7,259
Quote:
Decomb, yet another package that foolishly assumes UVpitch = Ypitch/2
Which other packages are known to need 'SetPlanarLegacyAlignment(True)' ? (first time I see this function)
__________________
Hybrid here in the forum, homepage
Selur is offline   Reply With Quote
Old 17th February 2012, 11:14   #294  |  Link
Selur
Registered User
 
Selur's Avatar
 
Join Date: Oct 2001
Location: Germany
Posts: 7,259
I wrote a small application (full source) to view avs files, but it keeps crashing. I pasted the main part to http://pastebin.com/LB5fCTg5

My problem is cleaning the enviroment and rebuilding a new one.
If I loads a new file everything is fine, clip can be viewed without a problem.
To load another clip, I than first call m_env->DeleteScriptEnvironment(); (line 177) to clean up the old environment, initialize a new one (line 53), invoke the Import of the new clip (line 71) and try to call .asClip on the returned AVSValue; all like I did for the first clip. Problem is now the whole application comes crashing down.
To prevent this I added a few lines which check that the enviroment equals NULL before initializing it, problem is: How to do it properly such that I can kill the existing enviroment and set up a new?

Also how to I really delete the enviroment, calling DeleteScriptEnvironment() does not set it back to NULL and if I call delete m_env after calling DeleteScriptEnvironment() the application crashed,..

-> would be cool if someone who knows how to handle avisynth script environment stuff could have a look at it and tell me what I did wrong.
(it's probably something stupid that I missed )

Cu Selur
__________________
Hybrid here in the forum, homepage
Selur is offline   Reply With Quote
Old 17th February 2012, 13:11   #295  |  Link
TheFluff
Excessively jovial fellow
 
Join Date: Jun 2004
Location: rude
Posts: 1,100
With Avisynth 2.5 the usual way to delete a script environment is to simply say
Code:
delete env;
I don't know if that's still the case with 2.6 though. DeleteScriptEnvironment() wasn't an exported function in 2.5.8 AFAIK.
TheFluff is offline   Reply With Quote
Old 17th February 2012, 13:16   #296  |  Link
Gavino
Avisynth language lover
 
Join Date: Dec 2007
Location: Spain
Posts: 3,431
Quote:
Originally Posted by Selur View Post
To load another clip, I than first call m_env->DeleteScriptEnvironment(); (line 177) to clean up the old environment, initialize a new one (line 53), invoke the Import of the new clip (line 71) and try to call .asClip on the returned AVSValue; all like I did for the first clip. Problem is now the whole application comes crashing down.
Before calling DeleteScriptEnvironment(), you need to set any persistent variables (such as m_res and m_clip) to 0. Otherwise Avisynth will crash when you next assign a value to them, as it will try to free the old values which are linked to a now-deleted script environment.

Quote:
Also how to I really delete the enviroment, calling DeleteScriptEnvironment() does not set it back to NULL
Of course not - m_env is a variable and the only way to set it to NULL is to set it yourself.
Code:
m_env->DeleteScriptEnvironment();
m_env = NULL; // ensure new environment created next time
__________________
GScript and GRunT - complex Avisynth scripting made easier
Gavino is offline   Reply With Quote
Old 17th February 2012, 15:55   #297  |  Link
Selur
Registered User
 
Selur's Avatar
 
Join Date: Oct 2001
Location: Germany
Posts: 7,259
Thanks Gavino!! Worked like a charm!

Cu Selur
__________________
Hybrid here in the forum, homepage
Selur is offline   Reply With Quote
Old 20th February 2012, 12:58   #298  |  Link
Selur
Registered User
 
Selur's Avatar
 
Join Date: Oct 2001
Location: Germany
Posts: 7,259
Got another problem.
I use the following code to load an Avisynth script:
Code:
try {
  m_res = m_env->Invoke("Import", infile); //import current input to environment
} catch (AvisynthError &err) { //catch AvisynthErrors
  cerr << "-> Avisynth error: " << err.msg << endl;
  return;
} catch (...) { //catch the rest
  cerr << "-> Unknown error,... " << endl;
  return;
}
problem is, it works fine if the input avisynth script is fine, but if it has a problem the whole application just crashes due to the Invoke call,.. (I assumed it would throw a AvisynthError which I could catch,..)

Cu Selur
__________________
Hybrid here in the forum, homepage
Selur is offline   Reply With Quote
Old 20th February 2012, 14:02   #299  |  Link
TheFluff
Excessively jovial fellow
 
Join Date: Jun 2004
Location: rude
Posts: 1,100
Welcome to the hilarious game of trying to catch C++ exceptions thrown from an external DLL which you have loaded dynamically at runtime. Fun for the whole family!
Except it's not, and if someone looks at your exception handler in a vaguely threatening way it'll most likely freak out and just not catch anything.

In theory, in order to get it to work perfectly reliably you must:
  • compile your program with the same compiler as the DLL
  • using the exact same compilation settings, and
  • using the exact same runtime.

In your case, you can probably get away by just linking to the C++ runtime library dynamically rather than statically.

I remember there being a post somewhere on these boards that explained some gory details regarding this at some length, but I can't find it now.

Last edited by TheFluff; 20th February 2012 at 14:25.
TheFluff is offline   Reply With Quote
Old 20th February 2012, 14:05   #300  |  Link
Selur
Registered User
 
Selur's Avatar
 
Join Date: Oct 2001
Location: Germany
Posts: 7,259
I'll try to look for the post (did before but didn't find anything).
__________________
Hybrid here in the forum, homepage
Selur is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 09:58.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.