Known Issues

From Avisynth wiki
(Difference between revisions)
Jump to: navigation, search
m (space)
 
(6 intermediate revisions by one user not shown)
Line 1: Line 1:
The page contains a list of bugs in 2.58. They are fixed in 2.60 unless stated otherwise.
+
The page contains a list of bugs in 2.60. They are fixed in 2.61 unless stated otherwise.
  
===Crop Bug===
+
== Usage bugs ==
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
+
=== Improper YV12<->YUY2 Conversions ===
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: [http://forum.doom9.org/showthread.php?p=1471072#post1471072].
+
 
+
 
+
===Improper YV12<->YUY2 Conversions===
+
 
Please see [http://forum.doom9.org/showthread.php?t=147629].  The built-in YUY2<->YV12 conversions introduce a chroma shift.  Use this replacement instead:
 
Please see [http://forum.doom9.org/showthread.php?t=147629].  The built-in YUY2<->YV12 conversions introduce a chroma shift.  Use this replacement instead:
  
Line 66: Line 34:
 
  }
 
  }
  
Use the YV12<->YV16 conversions instead. They use a different code path and don't have this problem. This issue still exists in v2.60.
+
Use the YV12<->YV16 conversions instead. They use a different code path and don't have this problem. This issue still exists in v2.61.
  
 +
=== Resizers: Chroma Positioning Bugs ===
 +
All [[Resize|resizers]] contain (hardly noticeable) 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 [http://forum.doom9.org/showthread.php?p=1505975#post1505975 here] and [http://forum.doom9.org/showthread.php?p=1543729#post1543729 here]. It affects all horizontally subsampled YUV formats (YUY2, YV16, YV411 and YV12, but not YV24). This issue still exists in v2.61.
  
===ImageSource/ImageReader Bug===
+
=== Bob: Chroma Positioning Bugs ===
Reading a tga image results in a flipped (upside down) output. This can be 'corrected' by using [[FlipVertical]] afterwards.
+
[[Bob]] also contains a chroma positioning bug. More can be found [http://forum.doom9.org/showthread.php?p=1172038#post1172038 here]. This issue still exists in v2.61.
  
 
+
=== PointResize Issue ===
===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 [http://forum.doom9.org/showthread.php?t=153313 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 [[Resize|resizers]] contain (hardly noticeable) 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 [http://forum.doom9.org/showthread.php?p=1505975#post1505975 here] and [http://forum.doom9.org/showthread.php?p=1543729#post1543729 here]. It affects all horizontally subsampled YUV formats (YUY2, YV16, YV411 and YV12, but not YV24). This issue still exists in v2.60.
+
 
+
 
+
===Horizontal Shift in RGB->YUY2===
+
There is a horizontal shift when doing a RGB->YUY2 conversion as described [http://forum.doom9.org/showthread.php?p=1038027#post1038027 here].
+
 
+
 
+
===Bob: Chroma Positioning Bugs===
+
[[Bob]] also contains a chroma positioning bug. More can be found [http://forum.doom9.org/showthread.php?p=1172038#post1172038 here]. This issue still 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.
 
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.
  
Line 105: Line 54:
 
  pointresize(width,height/2)
 
  pointresize(width,height/2)
  
This issue still exists in v2.60. It will likely remain that way to ensure compatibility.
+
This issue still exists in v2.61 and it will likely remain that way to ensure compatibility.
  
 
+
=== SincResize Bug ===
===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===
+
 
[[SincResize]] produces incorrect results.  This bug exists in AviSynth 2.6a3, but has been corrected in 2.6MT.  Demonstration:  http://screenshotcomparison.com/comparison/91203
 
[[SincResize]] produces incorrect results.  This bug exists in AviSynth 2.6a3, but has been corrected in 2.6MT.  Demonstration:  http://screenshotcomparison.com/comparison/91203
  
Line 133: Line 77:
 
todo: is this still an issue?
 
todo: is this still an issue?
  
 +
=== ShowSMPTE framerate check ===
 +
ShowSMPTE framerate must be an integer (24, 25, 30, 31,...) or a standard drop-frame rate as listed in the table below. If that's the case an error should be thrown, but that didn't happen. Not sure whether this bug also exists in v2.58.
 +
 +
=== FixLuminance ===
 +
This filter is broken. I think the idea of the filter is that it progressively darkens the top of the image. So the luma should go from black (at the top) to the luma of the image (at the bottom). It has two defects though:
 +
1) It is broken when you apply it to an image with height larger than 255 pixels. You will see a repetitive gradient, because of the line <br>
 +
p[x*2] = max(0, BYTE(p[x*2]-subtract)); <br>
 +
p[x*2]-subtract can get negative, and p[x*2] won't be zero in that case. <br>
 +
2) It results in a crash if intercept > height of the image. It either should throw an error or use min(height, intercept) instead.
 +
 +
=== Convert to planar YUV and chromaoutplacement="dv" ===
 +
 +
The ConvertToYVxx do the dv-pal chroma with reverse u and v in shifting: http://forum.doom9.org/showpost.php?p=1736293&postcount=55
 +
Script:
 +
 +
ColorBars(width=640, height=480, pixel_type="RGB32")
 +
ConvertToYV12(interlaced=true, chromaoutplacement="dv")
  
===BlankClip and Last Bug===
+
== API bugs ==
[[BlankClip]] without brackets will be taken as BlankClip(last) if last has a defined clip value, instead of being taken as BlankClip(). Discussion http://forum.doom9.org/showthread.php?t=163976 .
+
  
 +
=== 32 bytes aligned frames not allowed ===
 +
Some plugin filters require 32bytes aligned pointer and pitch to support AVX2: https://github.com/chikuzen/YV12To422
  
===Audio cache bug===
+
However, even if I call env->NewVideoFrame(vi, 32), AviAynth returns 16 bytes aligned frame. Because it uses hard coded FRAME_ALIGN value to calculate offset. This issue still exists in v2.61a1.
http://forum.doom9.org/showthread.php?t=164833 and http://forum.doom9.org/showthread.php?t=149457 .
+
  
 +
=== c-api ===
  
===Float Implementation Documentation Issue===
+
Fix avisynth_c plane=0. Default parameters are not allowed in plain C.
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 integers, due to precision issues. For more information, please see [[Advanced_Scripting_Tips]].
+
  
 
[[Category:AviSynth_Usage]]
 
[[Category:AviSynth_Usage]]

Latest revision as of 13:14, 21 June 2016

The page contains a list of bugs in 2.60. They are fixed in 2.61 unless stated otherwise.

Contents

[edit] Usage bugs

[edit] Improper YV12<->YUY2 Conversions

Please see [1]. 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()
}

Use the YV12<->YV16 conversions instead. They use a different code path and don't have this problem. This issue still exists in v2.61.

[edit] Resizers: Chroma Positioning Bugs

All resizers contain (hardly noticeable) 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. It affects all horizontally subsampled YUV formats (YUY2, YV16, YV411 and YV12, but not YV24). This issue still exists in v2.61.

[edit] Bob: Chroma Positioning Bugs

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

[edit] 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 still exists in v2.61 and it will likely remain that way to ensure compatibility.

[edit] SincResize Bug

SincResize 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)
}

todo: is this still an issue?

[edit] ShowSMPTE framerate check

ShowSMPTE framerate must be an integer (24, 25, 30, 31,...) or a standard drop-frame rate as listed in the table below. If that's the case an error should be thrown, but that didn't happen. Not sure whether this bug also exists in v2.58.

[edit] FixLuminance

This filter is broken. I think the idea of the filter is that it progressively darkens the top of the image. So the luma should go from black (at the top) to the luma of the image (at the bottom). It has two defects though: 1) It is broken when you apply it to an image with height larger than 255 pixels. You will see a repetitive gradient, because of the line
p[x*2] = max(0, BYTE(p[x*2]-subtract));
p[x*2]-subtract can get negative, and p[x*2] won't be zero in that case.
2) It results in a crash if intercept > height of the image. It either should throw an error or use min(height, intercept) instead.

[edit] Convert to planar YUV and chromaoutplacement="dv"

The ConvertToYVxx do the dv-pal chroma with reverse u and v in shifting: http://forum.doom9.org/showpost.php?p=1736293&postcount=55 Script:

ColorBars(width=640, height=480, pixel_type="RGB32")
ConvertToYV12(interlaced=true, chromaoutplacement="dv")

[edit] API bugs

[edit] 32 bytes aligned frames not allowed

Some plugin filters require 32bytes aligned pointer and pitch to support AVX2: https://github.com/chikuzen/YV12To422

However, even if I call env->NewVideoFrame(vi, 32), AviAynth returns 16 bytes aligned frame. Because it uses hard coded FRAME_ALIGN value to calculate offset. This issue still exists in v2.61a1.

[edit] c-api

Fix avisynth_c plane=0. Default parameters are not allowed in plain C.

Personal tools