AviSynth 2.6.0 Alpha4 [Jan 14th, 2013]

[Stephen R. Savage]

I am encountering an access violation with this script:


ImageSource("what.png")
ConvertToYV24()
Tweak(sat=1.25)
Tweak(sat=0.8)
ConvertToRGB()


The error reads: "Avisynth read error: Software caught an access violation at 0x00000320(code+4249890016), attemping to write to 0x00000320". The image dimensions are 785x900.

[paradoxical]

*ignore me*

[Chikuzen]

It may or may not be the issue but YV24 requires mod4 dimensions and 785 is not mod4.

wut?
YV24 (and Y8) can accept even odd width/height.

[paradoxical]

Okay, then either I misread or the source was wrong, but I did see a source say that mod4 was required for YV24. My bad, then.

[Groucho2004]

I am encountering an access violation with this script:


ImageSource("what.png")
ConvertToYV24()
Tweak(sat=1.25)
Tweak(sat=0.8)
ConvertToRGB()


The error reads: "Avisynth read error: Software caught an access violation at 0x00000320(code+4249890016), attemping to write to 0x00000320". The image dimensions are 785x900.
Which version of devil.dll are you using?
Which program produces the error?

[IanB]

@Stephen R. Savage, and What CPU processor are you using? What OS?

Does this fail the same way?BlankClip(1001, 785, 900, Pixel_type="rgb24")
ConvertToYV24()
Tweak(sat=1.25)
Tweak(sat=0.8)
ConvertToRGB()

[Stephen R. Savage]

@Stephen R. Savage, and What CPU processor are you using? What OS?

Does this fail the same way?BlankClip(1001, 785, 900, Pixel_type="rgb24")
ConvertToYV24()
Tweak(sat=1.25)
Tweak(sat=0.8)
ConvertToRGB()

I am using Windows 8 AMD64 on an Ivy Bridge CPU. Your fragment does not produce any exceptions as far as I can tell.

Edit: Never mind, exceptions are still there. I managed to reproduce it by loading it in VirtualDub and then switching the tweak parameters and reloading a few times. Eventually it tells me "script open failed".

[Groucho2004]

@IanB
Which compiler did you use to build Alpha4?

[SEt]

It's compiled with VC 6. And packed with 6 years old upx after that.

[Wilbert]

Edit: Never mind, exceptions are still there. I managed to reproduce it by loading it in VirtualDub and then switching the tweak parameters and reloading a few times. Eventually it tells me "script open failed".
So, you can't produce a script which always fails??

[forclip]

I can easily reproduce this AccessViolations with simple script like this:

BlankClip(1001, 754, 562, Pixel_type="y8")
ConvertToRGB32()

In VirtualDubMod - by pressing F5 button or reloading the script again and again.
In MPC-HC - by reloading the script.
In MeGUI script creator - by reloading preview window.
...

All the time it is AccesViolation, or app just dissapeared, or other things like "Parser: Unknown error".

Actually, I came to this not from this bugreport, but from my own bug report, when the user told me that everything works fine when he uses DirectShow preview of the script (a simple player that based on DirectShow), but when switching to our own preview engine (that uses AviSynth.dll directly via AviSynthWrapper.dll) he've got alot of AcessViolations. Most of the time - on unloading AviSynth (when PClip var = some_clip; do something; and then on unloading var=NULL; - here, when destroying IClip on Release()). And then I remembered that in second case everything is Convert`edToRGB32() in AviSynthWrapper. Added ConvertToRGB32() at the end of the script - and now I can reproduce AVs with DirectShow too.

Tested with Alpha4 and latest MT build; on Win XP SP2 with Intel Q6600 cpu.

[StainlessS]

Confirmed with VDMod and VD 1.9.11

Also Access violation with arg names supplied ie



#BlankClip(1001, 754, 562, Pixel_type="y8")
BlankClip(length=1001, width=754, height=562, Pixel_type="y8")
ConvertToRGB32()


Seems to mostly work ok on first load but on reload bombs.

VD 1st load may play OK, bomb on reload.

VDMod, Bombs on reload and if exit without reload or play.

XP32SP3

AppCompat.txt From VDMod bomb on noplay exit:

http://www.mediafire.com/?dmy86jv3uxsogke

[IanB]

Failure is for aligned SSE3+ code path in ConvertYV24toRGB for widths 16*N+1, N a positive integer greater than 1.N=2
BlankClip(10, 16*N+1, 16, Pixel_type="YV24")
ConvertToRGB()The packbuf array was being overrun. Repeatedly reloading the script eventually clobbers something that matters. It may happen on the first try, it may take 50 tries.

Fixed in CVS.

[forclip]

Thanks! :thanks:

[Gavino]

I can easily reproduce this AccessViolations with simple script like this:
BlankClip(1001, 754, 562, Pixel_type="y8")
ConvertToRGB32()

Failure is for aligned SSE3+ code path in ConvertYV24toRGB for widths 16*N+1, N a positive integer greater than 1.N=2
BlankClip(10, 16*N+1, 16, Pixel_type="YV24")
ConvertToRGB()
754 does not have the form 16*N+1. (754%16 is 2, not 1)
:confused:

[forclip]

There is also different source colorspaces (Y8 in my sample and YV12 was reported to me), but I hope that it makes no difference and affected code path is the same.

P.S. it would be nice to have a project files for something like MSVC2008\2010 on the CVS..

[IanB]

Well it's actually 16*N+[1..7] that are wrong, but they get harder to expose.

Wrong buffer length is (width*4 + 32), used buffer length is ((width+15)/16*64), the overrun is ((7 - (width-1)%16)*4)

W%16 Overrun
1 28
2 24
3 20
4 16
5 12
6 8
7 4

[Wilbert]

I was looking at the additions for BlankClip. Why not add video (with the default parameters) when supplying an audio only template, instead of checking of the one the parameters width, height or pixel_type is set? Likewise for a video only template.

[IanB]

@Wilbert,

So when you do BlankClip(Clip) you get identical clip properties to the template. If it's audio only you get a blank audio only clip. If it's video only you get a blank video only clip. If you start to modify the parameters to force a video or audio track, now you start with good defaults rather then possibly (probably) invalid junk from the template.

[Wilbert]

... If it's audio only you get a blank audio only clip. ...
Somehow I missed that. Makes sense now. Thanks.

[Wilbert]

Mmmm, i didn't realize you already documented everything ;( My fault of course.

Regarding the bit functions. Is there a difference between BitRShiftL, BitRShiftU and BitRShiftU for example? If not, why the need for three of them?
I would also like to ask you to remove tau (as being 2 pi). It's not used in the scientific literature: http://en.wikipedia.org/wiki/Tau_%282%CF%80%29#In_popular_culture, while it can denote a lot of other things: http://en.wikipedia.org/wiki/Tau.

[IanB]

Possibly a bit over-redundant but this is what we have, it allows building selections from Bit[LR]shift[AL] or Bit[LR]shift[SU] :-

7 synonyms for Left Shift, X << Y, bottom bits are always zero filled.
bitlshift Left Shift
bitlshiftl Left Shift Logical
bitlshifta Left Shift Arithmetic
bitlshiftu Left Shift Unsigned
bitlshifts Left Shift Signed
bitshl Shift Left
bitsal Shift Arithmetic Left


3 synonyms for Unsigned Right Shift, (unsigned int)X << Y, top bits are zero filled.
bitrshiftl Right Shift Logical
bitrshiftu Right Shift Unsigned
bitshr Shift Right


3 synonyms for Signed Right Shift, (int)X << Y, top bits are sign filled.
bitrshifta Right Shift Arithmetic
bitrshifts Right Shift Signed
bitsar Shift Arithmetic Right


2 synonyms for Rotate Left, Top bit rolls to Bottom bit.
bitlrotate Left Rotate
bitrol Rotate Left


2 synonyms for Rotate Right, Bottom bit rolls to Top bit.
bitrrotate Right Rotate
bitror Rotate Right


I added Tau() as a stir of a friend who is an avid Tau'ist, who I regularly poke with "The area of a circle is ∏r²". So I will take it out.

[Reino]

Since v2.60 you can trim the audio using AudioTrim. The start_time, end_time and duration need to be specified in seconds (but can be float)Is it really?
I'm trying to load a cue-indexed audiosong from a TAK-image which starts at 40053972 samples (908.25333s) and is 16986144 samples (385.17333s) long:
LoadDll("C:\Program Files\AviSynth 2.6.0\plugins\tak_deco_lib.dll")
BassAudioSource("D:\Test\Image.tak")

AudioTrim(40053972/44100,-16986144/44100)
AudioTrim(Float(40053972)/44100,Float(-16986144)/44100)

ConvertAudioTo16bit
With the 1st AudioTrim foobar returns a length of 16978500 samples or exactly 385s. It seems the start_time and end_time are floored somehow. I'd figure the starting point would also be 40042800 samples or 908s.

With the 2nd AudioTrim foobar returns 16986144 samples, but when I then bit-compare (http://www.foobar2000.org/components/view/foo_bitcompare) the Avisynth-script and the cue-indexed TAK-song, it doesn't seem to be accurate:
Differences found in 1 out of 1 track pairs.

Comparing:
"D:\Test\Image.tak" / index: 3
"D:\Test\Image.avs"
Differences found: 33952821 sample(s), starting at 0.0000000 second(s), peak: 1.4393005 at 35.8453061 second(s), 2ch

- How come Float() is needed?
- Is it possible to AudioTrim with sample accuracy?

[Rumbah]

- How come Float() is needed?

If you divide two integers the result will be an integer.
Just add a .0 to the integers to do a floating point division.

[Reino]

Ah, got it. Thanks for the heads-up, Rumbah.

Another weird example:
Another song within the same TAK-image starts at 113414616 samples (2571.76s) and is 21692496 samples (491.89333s) long:
LoadDll("C:\Program Files\AviSynth 2.6.0\plugins\tak_deco_lib.dll")
BassAudioSource("D:\Test\Image.tak")

AudioTrim(113414616/44100.0,-21692496/44100.0)
AudioTrim(113414616/44100.0,135107112/44100.0)

ConvertAudioTo16bit
The 1st AudioTrim returns a length of 21692497 samples (491.89337s), but although code for the 2nd AudioTrim should have the same result as the 1st, it returns 21692485 samples (491.89308s)! Does anyone have an explanation?

Happens to WavSource() too, so at least BassAudio isn't faulty. Remove both AudioTrim()'s and bit-compare that to the entire TAK-image also results in 'no differences found'.

[Gavino]

AudioTrim(113414616/44100.0,-21692496/44100.0)
AudioTrim(113414616/44100.0,135107112/44100.0)
The 1st AudioTrim returns a length of 21692497 samples (491.89337s), but although code for the 2nd AudioTrim should have the same result as the 1st, it returns 21692485 samples (491.89308s)! Does anyone have an explanation?
You are being hit by the accuracy limits of floating point representation.
Avisynth floats have 24 bit precision, which gives an accuracy of about 1 part in 16.8 million (2^24).
So any sample start, end or length values larger than this (which your examples all have) will not be sample-accurate.

[IanB]

@CoRoNe,

You are running into lack of precision with single precision floats.

Floats only have a 24 bit mantissa so numbers bigger than 16,777,216 can not be represented exactly. Which for the way you are using the arithmetic and with 44100Hz streams is about 380.4 seconds (349.5 for 48000Hz).

The code internally uses 64 bit integers and double precision floats, so as long as you feed it from the script with single precision numbers that can be represented exactly you can achieve audio sample exact results.

You can trim between 1.0 and 16,777,215.0 integer seconds of audio exactly from the start of a clip.

So to crib the precision do the AudioTrim in stages. Using integer arithmetic calculate whole seconds and a remainder....
Start=113414616/44100
Sremainder=(113414616%44100)/44100.0

Duration=21692496/44100
Dremainder=(21692496%44100)/44100.0

AudioTrim(Start, 0) # Chop off start integer seconds
AudioTrim(Sremainder, 0) # Chop off start remaining fractional second
# Chop full seconds and join with remaining fractional second
AudioTrim(0, -Duration) + AudioTrim(Duration, -Dremainder)

The relevant code inside AudioTrim :- Trim::Trim(double starttime, double endtime, PClip ...
...
__int64 esampleno = 0;
...
audio_offset = min(max(__int64(starttime*vi.audio_samples_per_second + 0.5), 0), ...
...
if (endtime == 0.0)
esampleno = vi.num_audio_samples;
else if (endtime < 0.0)
esampleno = __int64((starttime-endtime)*vi.audio_samples_per_second + 0.5);
else
esampleno = __int64(endtime*vi.audio_samples_per_second + 0.5);

[Reino]

LoadDll("C:\Program Files\AviSynth 2.6.0\plugins\tak_deco_lib.dll")
BassAudioSource("D:\Test\Image.tak")

AudioTrim(113414616/44100, 0)
AudioTrim((113414616%44100)/44100.0, 0)
AudioTrim(0, -21692496/44100) + AudioTrim(21692496/44100, -(21692496%44100)/44100.0)

ConvertAudioTo16bitAll tracks decoded fine, no differences found.

Comparing:
"D:\Test\Image.tak" / index: 7
"D:\Test\Image.avs"
No differences in decoded data found.
:goodpost: IanB!

However, I've tried to come up with some script to mimic the cutting I did with Audacity earlier, but although the amount of samples are the same, there's a glitch at the cutting-point:
Src=BassAudioSource("D:\Test\Image.tak")
Prt1=Src.AudioTrim(113414616/44100, 0)
Prt1=Prt1.AudioTrim((113414616%44100)/44100.0, 0)
Prt1=Prt1.AudioTrim(0, -11161180/44100) + AudioTrim(11161180/44100, -(11161180%44100)/44100.0)
Prt2=Src.AudioTrim(128129206/44100, 0)
Prt2=Prt2.AudioTrim((128129206%44100)/44100.0, 0)
Prt2=Prt2.AudioTrim(0, -6977906/44100) + AudioTrim(6977906/44100, -(6977906%44100)/44100.0)
Prt1+Prt2
Yesterday this code still looked like this:
A=AudioTrim(113414616/44100.0, 124575796/44100.0)
B=AudioTrim(128129206/44100.0, 135107112/44100.0)
A+BI haven't touched Avisynth in quite some time, so I must be doing something rather silly.

[Gavino]

I've tried to come up with some script to mimic the cutting I did with Audacity earlier, but although the amount of samples are the same, there's a glitch at the cutting-point:
Src=BassAudioSource("D:\Test\Image.tak")
Prt1=Src.AudioTrim(113414616/44100, 0)
Prt1=Prt1.AudioTrim((113414616%44100)/44100.0, 0)
Prt1=Prt1.AudioTrim(0, -11161180/44100) + AudioTrim(11161180/44100, -(11161180%44100)/44100.0)
Prt2=Src.AudioTrim(128129206/44100, 0)
Prt2=Prt2.AudioTrim((128129206%44100)/44100.0, 0)
Prt2=Prt2.AudioTrim(0, -6977906/44100) + AudioTrim(6977906/44100, -(6977906%44100)/44100.0)
Prt1+Prt2
It should be:
...
Prt1=Prt1.AudioTrim(0, -11161180/44100) + Prt1.AudioTrim(11161180/44100, -(11161180%44100)/44100.0)
...
Prt2=Prt2.AudioTrim(0, -6977906/44100) + Prt2.AudioTrim(6977906/44100, -(6977906%44100)/44100.0)
Does the quoted script match the one you actually used?
It should give an error 'invalid params to AudioTrim()' (unless some earlier part of the script sets an implicit 'last').

[Reino]

(unless some earlier part of the script sets an implicit 'last').Yeah, that! Lot's of '#'s for testing, but I forgot one it seems. Prt1 and Prt2 did the trick. Thanks! Silly me. Like I said, it's been a while. :p

[IanB]

...
However, I've tried to come up with some script to mimic the cutting I did with Audacity earlier, but although the amount of samples are the same, there's a glitch at the cutting-point:
...I take it you mean between the join between Prt1 and Prt2.

Are the sample numbers you have chosen zero crossing points. I believe Audacity does soft joins, Avisynth does hard joins of audio segments which can lead to significant discontinuities (loud pop) if one clip ends with a non-zero value and the next clip starts with a value of the opposite sign. Apart from selecting zero crossing points you can use a very short duration FadeOut0() and FadeIn0() on the two clips or you could use Dissolve() with a short overlap. I typically set FPS=1000 and use a value between 2 to 10 depending on the sound type, i.e a 2 to 10 millisecond fade....
AudioDubEx( A+B, A.KillVideo().FadeOut0(2, Fps=1000)+B.KillVideo().FadeIn0(2, fps=1000) )

There are also joins between the clips and the small residual segment at the end of the clips. To make the method bullet proof you need to test for (duration%rate)==0 if using the classic script form of AudioTrim. If using the new Length= form the code handles a zero length request correctly.

To help debug your audio trimming use AudioLengthS() to display the full 64 bit value of audio sample count property as a string.

[Reino]

I take it you mean between the join between Prt1 and Prt2.Exactly, but "unless some earlier part of the script sets an implicit 'last'" caused the glitch.

I don't know about hard- or soft joins, but all I did was decode the 7th cue-entry to WAV, load it in Audacity and remove 3553310 samples at 11161180 samples from the start.
Src=BassAudioSource("D:\Test\Image.tak")
Prt1=Src.AudioTrim(113414616/44100, 0).AudioTrim((113414616%44100)/44100.0, 0)
Prt1=Prt1.AudioTrim(0, -11161180/44100) + Prt1.AudioTrim(11161180/44100, -(11161180%44100)/44100.0)
Prt2=Src.AudioTrim(128129206/44100, 0).AudioTrim((128129206%44100)/44100.0, 0)
Prt2=Prt2.AudioTrim(0, -6977906/44100) + Prt2.AudioTrim(6977906/44100, -(6977906%44100)/44100.0)
Prt1+Prt2
And this Avisynth-script has the same result,...
All tracks decoded fine, no differences found.

Comparing:
"D:\Test\Audacity_edit.wav"
"D:\Test\Image.avs"
No differences in decoded data found.
...as it's bit-exact.

To help debug your audio trimming use AudioLengthS() to display the full 64 bit value of audio sample count property as a string.Like Subtitle(String(AudioLengthS)), right? Foobar (and foo_input_avs (http://www.foobar2000.org/components/view/foo_input_avs)) already shows me that.

[IanB]

AudioLengthS() returns a string so Subtitle(AudioLengthS()) or WriteFileStart("AudioLengthS()")

Yeah, that! Lot's of '#'s for testing, but I forgot one it seems. Prt1 and Prt2 did the trick. Thanks! Silly me. Like I said, it's been a while. :pI missed it as well, so don't feel to bad.

A hard join is just appending the audio segments without processing. This can lead to clicks and pops if done carelessly. This is what Avisynth does by default.

A soft join checks the audio samples at the join and applies some processing to eliminate any clicks or pops. In Avisynth you can carefully select the splice points or use very short fades or a dissolve.

[StainlessS]

Dont think this has been reported:


Colorbars().Killaudio()
#ConvertToYV24() # Uncomment to swamp pagefile.
ScriptClip("""
Overlay(Last.BlankClip(Width=4,height=height,color=$FF0000),x=0,y=0)
Overlay(Last.BlankClip(Width=4,height=height,color=$FF0000),x=10,y=0)
Overlay(Last.BlankClip(Width=4,height=height,color=$FF0000),x=20,y=0)
Overlay(Last.BlankClip(Width=4,height=height,color=$FF0000),x=30,y=0)
Overlay(Last.BlankClip(Width=4,height=height,color=$FF0000),x=40,y=0)
Overlay(Last.BlankClip(Width=4,height=height,color=$FF0000),x=50,y=0)
""")
return last.ConvertToRGB32()


Produces error message on frame when ConvertToYV24 line uncommented,:

GetFramebuffer: Returned a VFB with a 0 data pointer!
size=23104, max=536870911, used=64378496
I think we have run out of memory folks!
(scriptClip, line 3)


Run it with Taskmanager showing perfomance tab and watch Pagefile.

VDUB/VDUBMOD/MediaPlayer

Other colorspaces stabilize at about 1GB pagefile.

EDIT: This Also problem


Colorbars().Killaudio()
ConvertToYV24() # Uncomment to swamp pagefile.
Z=Last.BlankClip(Width=4,height=height,color=$FF0000)
ScriptClip("""
Overlay(Z,x=0,y=0)
Overlay(Z,x=8,y=0)
Overlay(Z,x=16,y=0)
Overlay(Z,x=24,y=0)
Overlay(Z,x=32,y=0)
Overlay(Z,x=40,y=0)
""")
return last.ConvertToRGB32()


EDIT: Also tried with Groucho2004 ICL Avisynth.dll (current updates @ 8 March 2013), same thing.

The second script seems more likely to survive in VDMod rather than VD current which bombs after about 30 secs.
Media Players, MPC Home Cinema latest, goes Black Screen.
Other Media Players may put the mentioned error message on screen.

EDIT: Multiple Overlays to make it bomb quicker.

[bxyhxyh]

Is 2.6a4 more stable than 2.5.8?

[StainlessS]

Chroma displacement problem with YV411 in Info.h.

around about this line:


for (int tx = _xs; tx < 10; tx+=xSubS, dpU++, dpV++, fontline<<=xSubS) {


Is to do with font being 10 pixels wide and chroma sample representing 4 pixels, eg last 2 pixels in a character jumps
forward 1 whole choma sample and is 2 pixel positions or half chroma sample in error (for each character ie error grows).

See problem in DDigitTest v1.04 using non greyscale clip.

[IanB]

Hmmmmm, yes YV411 chroma subsampling is a pita. How to fix it, but keep it fast and generic. One thought is to process 2 chars at a time so we mask through 20 pixels per loop, as 20%4 == 0 the algorithm will work correctly as opposed to 10%4 == 2 which creeps.

One issue would be odd length strings. Okay in the length=0 case, we can use the null terminator, but in the length specified case the next char can be anything.

Or for YV411 we just bang the chroma to 128 across the region. The sub-sampling is pretty rough already so it won't actually look that bad skipping the chroma dimming between glyphs.

More thoughts .... ?

[IanB]

@bxyhxyh,

Yes the consensus seems to be the 2.6 series makes a very good 2.5.9. The 2.5 code has many fixes over 2.5.8, hopefully without regressions. Most bugs found are related to new 2.6 code paths. e.g the overlay memory leak 3 posts up only happens with YV24.

[mandarinka]

I am normally rather conservative but I switched over and saw no trouble yet in the two to three months or so.

[StainlessS]

@IanB,

Still chewing on the YV411 problem.

I've done a mod of a debug plug for DDigit, InfoPrint, just allows to view zoomed Info.H output as here:

https://s20.postimg.cc/wv1zjhfnh/Grid_zps7ecfb526.jpg (https://postimg.cc/image/5kgobkcqh/)

Uses V.C Mohan's Grid plugin (included with source in zip), zip here:
http://www.mediafire.com/?9p876ru232wpbv7 (http://www.mediafire.com/?i2syabkp5u3skti)

and supplied script here:


BlankClip(length=1,width=100,height=80,fps=25.0,color=$ff8000).KillAudio()

#ConvertToRGB24()
#ConvertToRGB32()
#ConvertToYUY2()
#ConvertToYV12()

#ConvertToY8() # v2.6 Only
#ConvertToYV16() #
#ConvertToYV24() #
ConvertToYV411() #

X=0 Y=0

InfoPrint("ABCDEFG",X+0,Y+00)
InfoPrint("abcdefg",X+1,Y+20)
InfoPrint("0123456",X+2,Y+40)
InfoPrint("NoPqRsT",X+3,Y+60)

PointResize(width*10,Height*10)
ConvertToRGB24()

Grid(lineint=10,bold=10,vbold=1) # Small grid=1x1 pixels
#Grid(lineint=20,bold=5,vbold=1) # Small grid=2x2 pixels
#Grid(lineint=40,bold=5,vbold=1) # Small grid=4x4 pixels
return Last
# ------------------------------------------------------------------------
# InfoPrint(clip,string,int "x"=0,int "y2"=0,bool "pix"=true)
#
# Formatting control codes in string:-
# '\n', Newline, positioning cursor 1 line down and at left edge of screen.
# '\r', Newline Special, moves 1 line down and positions cursor at on-entry X position.
# '\b', Backspace, obvious, not sure how useful this will be.
# '\f', Forward Space, again obvious, re-uses formfeed code for this. Again, maybe not so useful.
# '\t', Tab, @ character positions, every 4 characters.(relative screen LHS).
# ------------------------------------------------------------------------
# Grid.dll by V.C Mohan
# ------------------------------------------------------------------------


Perhaps of some use to you.

[IanB]

Yes the problem is obvious just from reading the code, with 4 time sub-sampling the inner most chroma only does 2 iterations when it needs to do 2.5, oops 2.5 is not an integer.

I tried just banging all the chroma in the 10x20 pixel cell to 128, it looks shitty.

I have also tried using 12x20 pixels cells for YV411, but that also looks shitty, the characters look divorced from one another with the extra gap between them.

So it looks like I have to process the chroma for the characters in pairs, which becomes a little untidy when handling all the edge conditions.

[IanB]

Fixed the memory leak in overlay.cpp (http://avisynth2.cvs.sourceforge.net/viewvc/avisynth2/avisynth/src/filters/overlay/overlay.cpp?revision=1.21&view=markup)

Have a play with this version of info.h (http://avisynth2.cvs.sourceforge.net/viewvc/avisynth2/avisynth/src/core/info.h?revision=1.10&view=markup), the first attempt code is under a "#if 0" so you can see what I mean. Just bump all the 10's to 12's to try the increased spacing (yuck!).The main code has only had minimal testing, YV411 suck for this sort of text rendering. Let me know how it goes for you.

[Gavino]

Fixed the memory leak in overlay.cpp (http://avisynth2.cvs.sourceforge.net/viewvc/avisynth2/avisynth/src/filters/overlay/overlay.cpp?revision=1.21&view=markup)
Related to this area, should this code at the end of GetFrame():
if (vi.IsYV24() && inputCS == vi.pixel_type) { // Fast path
delete img;
img = NULL;
return frame;
}
also be added on the earlier path where overlayImg->IsSizeZero()?
This would avoid not only a redundant copy, but also possible problems in the Overlay destructor (when calling img->Free()).

[StainlessS]

Thanx for the Overlay fix. :)

I know that you understood the YV411 problem without it being shown to you, I thought the utility might assist
in testing solutions. Also can show how eg supplied length performs as the control codes eg '\n' and '\r' send
intervening substrings with len specified.

Will download new info.h and give it a whirl. Thankyou.

EDIT: Perhaps someone knows of a collection of Open Source fonts, perhaps even with YV411 compatible
source that already exists ?

EDIT: Google on "open source font" bring up plenty of links.

EDIT: Or probably more targetted, "open source monospace bitmap screen font rendering bdf"

EDIT: This might be useful in search "BDF" (Glyph Bitmap Distribution Format) :-
http://en.wikipedia.org/wiki/Glyph_Bitmap_Distribution_Format

[StainlessS]

Problem in post #90 InfoPrint.dll zip, v2.6 project file, mistakenly got AVISYNTH_PLUGIN_25 defined for Release, remove or it will compile
to a v2.5 version dll. have updated post #90 link with fixed project file and dll's.

link again:
http://www.mediafire.com/?i2syabkp5u3skti

EDIT:- By the way, can use either eg "Test"+Chr(10)+"Test2" as well as "Test\nTest2" in InfoPrint

[StainlessS]

From ImageSource docs
The first file in the sequence, i.e., corresponding to 'start', MUST exist in order for clip parameters to be computed. Any missing files in the sequence are replaced with a blank frame.



ColorBars().Trim(0,-100).ShowFrameNumber()
ImageWriter("TEST_",type="BMP") # Create test frames




ImageSource("TEST_%06d.BMP",start=0,end=1000) # Test ImageSource


In both v2.58 and 2.6a4, non existing frames (100 -> 1000) alternate between BLACK frame and copies of ColorBars, rather than blank.

When I tested same with a 640x400 live video clip, I got some frames which looked like multiple miniature copies of frames, along with black frames
and some black frames with streaks in them.

Also see previous post EDIT.

[Gavino]

In both v2.58 and 2.6a4, non existing frames (100 -> 1000) alternate between BLACK frame and copies of ColorBars, rather than blank.
Looking at the source code in ImageSeq.cpp, it seems that (unless using DevIL) the frame is never written to in these cases and so contains random junk.

I think all the error paths in function checkProperties() should be setting the frame to blank (before, if appropriate, writing an error message). Of course, this will have to allow for setting chroma to 128 for YUV output, so can't just set all bytes to zero.

[StainlessS]

Probably just a copy/paste typo, in new filtersdk/DataStorageInAviSynth.htm


Y8

width mod-1 (no restriction)
height mod-1 (no restriction) if progressive
height mod-2 if interlaced

YV411

width mod-4
height mod-1 (no restriction) if progressive
height mod-1 (no restriction) if interlaced

[Wilbert]

Did anyone get SoundOut to work with Avisynth v2.60a4? When i open a script (ending with SoundOut()) in Virtualdub i get the error message:

Avisynth open failure:
Cache: Filter returned invalid response to CACHE_GETCHILD_CACHE_MODE. 176310176

Is it supposed to work in 2.60 or is something not implemented properly?

[poisondeathray]

Did anyone get SoundOut to work with Avisynth v2.60a4? When i open a script (ending with SoundOut()) in Virtualdub i get the error message:

Avisynth open failure:
Cache: Filter returned invalid response to CACHE_GETCHILD_CACHE_MODE. 176310176

Is it supposed to work in 2.60 or is something not implemented properly?



Works ok here...