Could Avisynth support VideoInfoHeader2 and dwInterlace output?

[zambelli]

Here's an interesting an idea that came up in another discussion...

A customer on the Expression Encoder forum was asking why an Avisynth script when imported into EE2 doesn't automatically trigger deinterlacing in the encoder. In case you're not familiar with Expression Encoder 2, it was designed to automatically enable deinterlacing whenever the input source presents a VideoInfoHeader2 with dwInterlace > 0.

The answer, of course, was that the Avisynth source has no flag that identifies it as progressive or interlaced, and even if it did, it only offers a VideoInfoHeader2 output pin.

But the more I thought about it, the more it actually sounded like a good idea. Why NOT add a method to the Avisynth filters that allows one to flag content as interlaced or progressive (and inheriting such info from source plugins like DGMPGDec would be fairly simple) and then offer a VideoInfoHeader2 output pin for downstream applications to process correctly?

[IanB]

Avisynth currently exports through the AVIFile interface, so any Direct Show access will be mapped from this.

This the currently exported information.AVIFILEINFOW afi;

afi.dwMaxBytesPerSec = 0;
afi.dwFlags = AVIFILEINFO_HASINDEX | AVIFILEINFO_ISINTERLEAVED;
afi.dwCaps = AVIFILECAPS_CANREAD | AVIFILECAPS_ALLKEYFRAMES | AVIFILECAPS_NOCOMPRESSION;

int nrStreams=0;
if (vi->HasVideo()==true) nrStreams=1;
if (vi->HasAudio()==true) nrStreams++;

afi.dwStreams = nrStreams;
afi.dwSuggestedBufferSize = 0;
afi.dwWidth = vi->width;
afi.dwHeight = vi->height;
afi.dwEditCount = 0;

afi.dwRate = vi->fps_numerator;
afi.dwScale = vi->fps_denominator;
afi.dwLength = vi->num_frames;

wcscpy(afi.szFileType, L"Avisynth");

[Wilbert]

A customer on the Expression Encoder forum was asking why an Avisynth script when imported into EE2 doesn't automatically trigger deinterlacing in the encoder. In case you're not familiar with Expression Encoder 2, it was designed to automatically enable deinterlacing whenever the input source presents a VideoInfoHeader2 with dwInterlace > 0.
I guess that dwInterlace > 0 means that the footage is encoded as interlaced. But your proposal will degrade your video when dwInterlace > 0, but the contents is actually progressive.

[zambelli]

I guess that dwInterlace > 0 means that the footage is encoded as interlaced. But your proposal will degrade your video when dwInterlace > 0, but the contents is actually progressive.
My idea is that it would be left up to either the script author or a preprocessing plugin to determine whether the content is interlaced or progressive. It's exactly the same concept as is in place for BFF/TFF today. If you use DGMPGDec, for example, it automatically sets BFF/TFF based on the MPEG-2 field order flag. But if you want to override it manually you can always call AssumeBFF/TFF.

In addition, if we established a progressive/interlaced property within Avisynth, deinterlacing plugins such as TDeint or Yadif could add the functionality which automatically sets that property to "progressive" after deinterlacing the video.

The issue that IanB mentions is probably the biggest blocker to implementing such functionality.

One possibility, and this could also solve the similar WaveFormatExtensible issue, might be to distribute a custom Avisynth source DShow filter with the Avisynth package. The few apps that use VfW to read .avs scripts don't care for VIH2 anyway, but DirectShow apps could certainly benefit from a source filter that's customized to Avisynth's needs.