Known Issues
(→Resizers: Chroma Positioning Bugs) |
|||
(4 intermediate revisions by one user not shown) | |||
Line 1: | Line 1: | ||
The page contains a list of bugs in 2.60. They are fixed in 2.61 unless stated otherwise. | The page contains a list of bugs in 2.60. They are fixed in 2.61 unless stated otherwise. | ||
− | ===Improper YV12<->YUY2 Conversions=== | + | == 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 34: | Line 36: | ||
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. | 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 === | |
− | ===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. | 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: 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. | [[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 === | |
− | ===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 56: | Line 56: | ||
This issue still exists in v2.61 and 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 === | |
− | ===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 78: | 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") | ||
+ | |||
+ | == 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]] | [[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.