Known Issues
From Avisynth wiki
(Difference between revisions)
| (14 intermediate revisions by 4 users not shown) | |||
| Line 1: | Line 1: | ||
| − | The page contains a list of bugs in 2. | + | The page contains a list of bugs in 2.60. They are fixed in 2.61 unless stated otherwise. |
| − | + | == Usage bugs == | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| + | === 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 69: | 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.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. | ||
| − | + | === 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.61. | ||
| − | + | === 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. | + | |
# Show PointResize Issue | # Show PointResize Issue | ||
| Line 113: | Line 54: | ||
pointresize(width,height/2) | pointresize(width,height/2) | ||
| − | This issue exists in v2. | + | This issue still exists in v2.61 and it will likely remain that way to ensure compatibility. |
| − | + | === 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) | ColorBars(width=14,height=2,pixel_type="YV12").trim(0,80) | ||
| Line 141: | Line 75: | ||
} | } | ||
| + | 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") | ||
| + | == API bugs == | ||
| − | + | === 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. | |
| + | === c-api === | ||
| − | + | Fix avisynth_c plane=0. Default parameters are not allowed in plain C. | |
| − | + | [[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.
