Known Issues

Revision as of 05:02, 19 September 2014

The page contains a list of bugs in 2.58. Most of them are fixed in 2.60 unless stated otherwise.

Crop bug

The crop bug exists when cropping RGB including an area outside the screen. There will be a crash instead of an error message.

# crop bug
exposebug = false # set to true to crash
n = exposebug ? 241 : 240
colorbars
crop(0,n,0,n)
#~ File "pyavs.pyo", line 310, in _GetFrame
#~ File "avisynth.pyo", line 139, in BitBlt
#~ WindowsError: exception: access violation reading 0x02DDFFE0

Overlay bug

Overlay gives a yellow tint on videos if used repeatedly on the same RGB video. All inputs to overlay are converted internally to a YUV 4:4:4 format, even if both are RGB.

# Overlay converts internally to a YUV 4:4:4 format. This will cause
# an increasing yellowish color at the top of the screen.
# The script also uses a large amount of memory since each instance of Overlay will use up to 3 full frames of this format.
# If that bothers you, use Layer instead.
base = blankclip.trim(0,9)
over = colorbars.trim(0,9)
showissue = true # Be careful with overlayissue, large values of n cause excessive memory use leading to a crash
showissue ? overlayissue(base,over,25) : layernonissue(base.resetmask,over.resetmask,25)
  function overlayissue(clip base, clip over, int n) {
    n<2?overlay(base,over.crop(0,n-1,0,1),y=n-1):overlay(overlayissue(base,over,n-1),over.crop(0,n-1,0,1),y=n-1)
  }
  function layernonissue(clip base, clip over, int n) {
    n<2?layer(base,over.crop(0,n-1,0,1),y=n-1):layer(layernonissue(base,over,n-1),over.crop(0,n-1,0,1),y=n-1)
  }

The yellow tint is caused by incorrect rounding: [1].

Improper YV12<->YUY2 Conversions

Please see [2]. The built-in YUY2<->YV12 conversions introduce a chroma shift. Use this replacement instead:

# Replacement code for YUY2<->YV12 conversions in v2.58
function YV12ToYUY2(clip c, bool "interlaced") {
  interlaced = Default(interlaced, false)
  interlaced ? c.YV12ToYUY2i() : c.YV12ToYUY2p()
}
function YUY2ToYV12(clip c, bool "interlaced") {
  interlaced = Default(interlaced, false)
  interlaced ? c.YUY2ToYV12i() : c.YUY2ToYV12p()
}
# ------- Support functions --------
function YV12ToYUY2p(clip c) {
  U = c.UToY().BilinearResize(c.width/2, c.height).ConvertToYUY2()
  V = c.VToY().BilinearResize(c.width/2, c.height).ConvertToYUY2()
  YToUV(U, V, c.ConvertToYUY2()) #crashes on v2.60
}
function YV12ToYUY2i(clip c) {
  f = c.AssumeTFF().SeparateFields()
  top = f.SelectEven()
  bot = f.SelectOdd()
  topU = top.UToY().BilinearResize(c.width/2, c.height/2, 0, 0.125)
  botU = bot.UToY().BilinearResize(c.width/2, c.height/2, 0, -0.125)
  U = Interleave(topU, botU).ConvertToYUY2()
  topV = top.VToY().BilinearResize(c.width/2, c.height/2, 0, 0.125)
  botV = bot.VToY().BilinearResize(c.width/2, c.height/2, 0, -0.125)
  V = Interleave(topV, botV).ConvertToYUY2()
  YToUV(U, V, f.ConvertToYUY2()).Weave()
}

ImageSource/ImageReader bug

Reading a tga image results in a flipped (upside down) output. This can be 'corrected' by using FlipVertical afterwards.

SeparateFields: Parity bug

The separation of the fields is done wrong if the parity of the clip is not constant (thus if an earlier filter has introduced a non-standard parity function, where the parity depends on the frame number). However, frame-based clips (the usual source material) usually have the same parity for every frame, since the entire clip is usually TFF or BFF. Hence the problem doesn't show up. More can be found here.

MergeChroma/MergeLuma documentation bug

There is no "weight" argument. It should be "LumaWeight" for MergeLuma() and "ChromaWeight" for MergeChroma(). Since v2.60 you can also use the "weight" argument.

Resizers: chroma positioning bugs

All resizers contain (hardly noticable) horizontal chroma positioning bugs. At first glance it seems to me the code dumbly assumes the chroma is positioned top left of the macrocell, not mpeg1. More can be found here and here. This issue also exists in v2.60. It affects all horizontally subsampled YUV formats (YUY2, YV16, YV411 and YV12, but not YV24).

Horizontal shift in RGB->YUY2

There is a horizontal shift when doing a RGB->YUY2 conversion as described here. This issue is fixed in 2.60a3.

Bob: chroma positioning bugs

Bob contains also a chroma positioning bug. More can be found here. This issue also exists in v2.60.

PointResize Issue

In YUV, PointResize will delete the first of every two lines when resizing. In RGB, the video is processed upside down and thus every 2nd line will be deleted. The result in this example is a screen of blue in RGB and a screen of black in YUY2.

# Show PointResize Issue
exposeissue = false # set to true to show issue
blue = blankclip(height=480/2,color=$ff)
black = blankclip(height=480/2)
interleave(black,blue)
assumefieldbased.assumetff.weave
exposeissue ? converttoyuy2 : nop
pointresize(width,height/2)

This issue exists in v2.58 and v2.60. It will likely remain that way to ensure compatibility.

Histogram Bug

The display shown in Histogram looks different whether in YV12 or YUY2. The marked areas are wrong; the midpoint is off-center and the upper range is too large.

SincResize Bug

The sinc resizer produces incorrect results. This bug exists in Avisynth 2.6a3, but has been corrected in 2.6MT. Demonstration: http://screenshotcomparison.com/comparison/91203

ColorBars(width=14,height=2,pixel_type="YV12").trim(0,80)
a=animate(0,80,"shift1",0.,8.)
b=animate(0,80,"shift2",0.,8.)
stackvertical(a,b)
pointresize(280,280)
ScriptClip("""
ph=current_frame/10.
subtitle("shift="+string(ph))
""")
function shift1(clip c, float x) {
   c.bilinearresize(c.width*20,c.height,x,0,c.width,c.height)
}
function shift2(clip c, float x) {
   c.sincresize(c.width*20,c.height,x,0,c.width,c.height)
}

Blankclip and last bug

Blankclip without brackets will be taken as blankclip(last) if last has a defined clip value, instead of being taken as blankclip(). Fixed in 2.6a3. Discussion http://forum.doom9.org/showthread.php?t=163976 .

Audio cache bug

http://forum.doom9.org/showthread.php?t=164833 and http://forum.doom9.org/showthread.php?t=149457 . Fixed in 2.6ax.

Float Implementation Documentation Issue

Older downloads of Avisynth 2.6 don't specifically mention the implementation of float. It is 32bits with 24bit mantissa. Care must be taken when casting or calculating, especially compared to the larger 32 bit ints, due to precision issues. For more information, please see Advanced_Scripting_Tips.