horizontal stripes after upgrading from v2.58 to v2.60

[zee944]

I've upgraded from Avisynth v2.58 to 2.60, and when I opened my project horizontal stripes appeared on the image that weren't there before. Here's a picture. See those stripes on the right side of the orange credits, around the heads of the couple and the very left side of the image? That shouldn't be there.



Here's the same frame taken from an encode made with v2.58 (it's heavily tweaked but still proves that no stripes are supposed to be seen):



The code part that's responsible for the problem is simple as this:

LoadPlugin("Decomb[5.2.2].dll")
MPEG2Source("TDUV.d2v")
AssumeTFF()
Telecide(guide=1)
Decimate(cycle=5)
AssumeFPS(23.976)

Actually, it is the Telecide() command that triggers the problem. I'm in a middle of a big-big project, I'd rather stick with Decomb if this can be fixed a less risky way. If the replacement plugin would do just a slightly different job IVTCing, that would led to catastrophic results and possibly wouldn't be noticed until it's too late.

I could go back to Avisynth 2.58, but I had to switch to 2.60 because of some new features needed for the very same project. I've tried both 2.60 alpha 1 and alpha 3 with the same result. The new feature I needed was ConvertToYV12's 'chromaresample' parameter. I have to do several colorspace conversions while avoiding chroma shifts, and this parameter is a key for archieving that. Discussed here: http://forum.doom9.org/showthread.php?t=164737, Gavino's posts.

What can I do?

[Didée]

Try

...
Telecide(guide=1)
SetPlanarLegacyAlignment(true)
...

[zee944]

:wiping sweat from forehead:

Ah, thanks. Works fine.

[Guest]

Is this something I could fix in Telecide()? What exactly is going on here?

[Didée]

The problem isn't about chroma pitch, or is it?

[IanB]

People have been notified since 2.57 to not assume any relationship between memory attributes of planes. Yet we still have plugins that do foolish things like pitchUV=pitchY/2; and even more foolish srcV=SrcY+src->GetPitch()*vi.height; (and this one dies with all versions after a crop).

As noted there is always the SetPlanarLegacyAlignment(true) compatibility mode and/or Crop(... align=true) for plugins that cannot be corrected.


@neuron2,

I appreciate you did not write the offending mpeg2source pp code, but you did assume the role of custodian, you did accept the chalenge to fix the bug and did suceed. I have pointed to offending lines of code and offered ammended code but the relevant posts seem to have avoided your notice. Not so sure about Telecide.

[TheFluff]

Telecide has always made unsafe assumptions about pitch, and there has been quite a bit of hurf durfed regarding this, so I'm a bit baffled by neuron2's apparent surprise and attempt to blame Avisynth 2.6 for breaking things. As IanB points out, assuming things about pitch is a recipe for disaster and it has never been the correct thing to do, so blaming Avisynth 2.6 for "breaking" things when what it did was stopping to work around silly bugs is sorta like trying to sweep your problems under somebody else's rug IMO.

[Guest]

Originally Posted by IanB

I have pointed to offending lines of code and offered ammended code but the relevant posts seem to have avoided your notice. Not so sure about Telecide.

Can you please point me again to these things?

[Chikuzen]

Originally Posted by neuron2

Can you please point me again to these things?

http://forum.doom9.org/showthread.php?t=150428

[Guest]

Thanks, but those changes were already made. I'd like to hear about the ones I apparently didn't notice.

[Guest]

Originally Posted by IanB

As noted there is always the SetPlanarLegacyAlignment(true) compatibility mode and/or Crop(... align=true) for plugins that cannot be corrected.

Is there anyway to enforce that from my plugin or is it something that can only be done in the script?

[StainlessS]

Could perhaps just duplicate functionality from 2.6a3

avisynth_2-6\src\filters\debug.cpp

class PlanarLegacyAlignment : public GenericVideoFilter 
{ 
private:
  const IScriptEnvironment::PlanarChromaAlignmentMode mode;

public:
  PlanarLegacyAlignment( PClip _child, const bool _mode, IScriptEnvironment* env )
    : GenericVideoFilter(_child),
      mode(_mode ?  IScriptEnvironment::PlanarChromaAlignmentOff  // Legacy PLANAR_Y alignment
                  : IScriptEnvironment::PlanarChromaAlignmentOn)  // New PLANAR_UV priority alignment
  { }

  PVideoFrame __stdcall GetFrame(int n, IScriptEnvironment* env)
  {
    const IScriptEnvironment::PlanarChromaAlignmentMode
      oldmode = env->PlanarChromaAlignment(mode)            // Set the PLANAR alignement mode
              ? IScriptEnvironment::PlanarChromaAlignmentOn
              : IScriptEnvironment::PlanarChromaAlignmentOff;

    PVideoFrame src = child->GetFrame(n, env);              // run the GetFrame chain

    env->PlanarChromaAlignment(oldmode);                    // reset the PLANAR alignement mode

    return src;
  }

  static AVSValue __cdecl Create(AVSValue args, void*, IScriptEnvironment* env)
  {
    return new PlanarLegacyAlignment(args[0].AsClip(), args[1].AsBool(), env);
  }

};

Above, remembers required mode in "mode" in constructor (is inverted for chroma).
In GetFrame(), switch to required mode using constructor set mode
using env->PlanarChromaAlignment(mode) and remember original returned in "oldmode".
Get child PVideoFrame with the set alignment, finally switch back to "oldmode".

Does not take into consideration the mentioned crop alignment.

[IanB]

Originally Posted by neuron2

Is there anyway to enforce that from my plugin or is it something that can only be done in the script?

As pointed out by StainlessS you could flip legacy mode around your GetFrame calls, but that means all the child filter chain runs with potentially unaligned chroma planes. Of course any child sse2 filters that don't properly check address alignment may crash and burn. At least one filter author has suggested they might be inclined to just throw an error if the alignment is not to their liking which is just as useful as a crash and burn, just with a "nicer" error message. Some filter defer to a slow C implementation when an unsuitably aligned source is supplied, better ones use a movdqu version, which is still slower.

As for the Crop(... Align=True) that is just a blit to new suitably aligned frame, so sure you could do that as well, but it costs you an extra set of blits.

The PlanarLegacyAlignment mode only effects the behaviour of the env->NewVideoFrame(vi); calls, so you probably need to wrap them as well, but then you end up feeding your parent filter with potentially unaligned output, so the crash and burn target moves down the script a few lines.

Anyway the PlanarLegacyAlignment mode only applies to YV12 frames, so to support new formats like YV16 and YV24 you are going to have to use the correct pitch values for the chroma planes.


Oops, I have previously looked at fixes for your Decomb package, but it seems I never got around to sending them to you or posting about them, life distractions are such a pain, particularly when you remember the intent instead of the action so no there is no post about Decomb only the one about PP in Mpeg2Source. (damn the forum search is lame, thank God for Google's site: modifier)

[StainlessS]

Perhaps I'm not terribly bright (It's not up for discussion) but,
why would (( x + 15) / 16) * 16, not be mod 16 aligned ?
(think mentioned in linked thread rather than this one).
EDIT: Here:- http://forum.doom9.org/showthread.ph...05#post1337605

[Gavino]

Originally Posted by StainlessS

Perhaps I'm not terribly bright (It's not up for discussion) but,
why would (( x + 15) / 16) * 16, not be mod 16 aligned ?
(think mentioned in linked thread rather than this one).
EDIT: Here:- http://forum.doom9.org/showthread.ph...05#post1337605

(( x + 15) / 16) * 16 clearly is, by construction, mod 16 aligned.

However, what IanB said was:

Originally Posted by IanB

there is obviously still some recalcitrant code that assumes UVpitch = YPitch/2; and/or YPitch = (Rowsize+15)/16*16

The problem there is not the mod16 alignment, but the erroneous asumption that the pitch is derived simply from the source width, which is wrong if a Crop has been used earlier in the chain.

[StainlessS]

Arh yes Of course, maybe it was the 'and/or' that threw me.
Thank you Big G.

EDIT: I would always use ((x + 15) & 0xFFFFFFF0) rather than ((( x + 15) / 16) * 16), except in script.

[IanB]

Okay, I spent a little time fixing Telecide to correctly handle pitch.

[Guest]

Sweet, thanks very much!

[Guest]

Hi IanB,

I'm ready to test this but when I search for Avisynth 2.6 to download all I find is installer EXE packages. Can I get just the plain DLL somewhere?

[manolito]

AFAIK 7zip can open the installer EXE and it lets you extract the dll just fine...


Cheers
manolito