Universal ConvertTo...() wrapper Cnv2()

[martin53]

The attached script is intended as the ultimate wrapper for all ConvertTo...() calls.
With the internal ConvertTo...() functions, I repeatedly struggle with several issues
- Matrix parameter is not allowed when converting from YUV to YUV, and RGB to RGB. So script lines with the parameter throw an error if a clip happens to be in the same color space.
- Matrix parameter depends on clip. Here (http://forum.doom9.org/showthread.php?t=169155) was found that it can in most cases be derived from clip resolution, but the internal functions require the user to enter it.
- Sometimes a number of formats are possible, and it can get tedious wo write down all the conditional commands depending on the format of the current clip
- it is harder than neccessary to set the format of a clip identical to the format of a reference clip. E.g. a user function could convert the format accordingly to the internally neded plugins, and then convert the clip back to the input format, so the function can be inserted everywhere without performing a hidden format change.
- ...

Comments & suggestions welcome.
# Cnv2() is designed to replace all pixel type conversion calls (ConvertTo...()).
# It features all ConvertTo...() function parameters, plus the boolean parameters 'PC', 'stacked' and the int 'tunnel'.
# The name Cnv2() is a phonetic shorthand for 'ConvertTo' for lazy typers.
#
# CCITT color transformation coefficients (601 or 709) are automatically chosen depending on clip size.
#
# Additional features: Instead of a pixel type string, simply a reference clip with the desired pixel type may be used.
# Arbitrary combinations of pixel type names or even pixel type Classes e.g. "RGB", "YUV" etc. may be used as target pixel type.
# Possible pixel type tokens in pixel_type: RGB24,RGB32,Y8,YV12,YV16,YV24,YV411,YUY2
# Possible pixel type class tokens in pixel_type: RGB,YUV,444,PLANAR,INTERLEAVED
#
# Function Parameters
# val pixel_type Either a string with one or more target pixel type names and/or pixel type classes or a reference clip with the target pixel type
# str matrix ("") CCITT matrix name. If omitted: Rec601/Rec709 automatically chosen depending on clip size
# bool interlaced (false) Interlaced layout for YV12 conversions. See AviSynth doc 'ConvertToYV12()'
# str ChromaInPlacement ("") For converting from YV12. See AviSynth doc 'ConvertToYV12()'
# str chromaresample ("") Chroma resampling for conversions with different chroma subsampling. See AviSynth doc 'ConvertToYV12()'
# str ChromaOutPlacement ("") For converting to YV12. See AviSynth doc 'ConvertToYV12()'
# bool PC (false) If true, PC.601/PC.709 are used instead of Rec601/Rec709. The variant 601/709 is still automatically chosen
# bool stacked (false) See 'dither' package. If true, vertical size of stacked 16bit frame is assumed for Rec601/Rec709 decision
# int tunnel (0) if >0, for YUV<->RGB conversion, direct channel transfer Y<->G, U<->B, and V<->R channels
# Tunneling allows to use most RGB filters on YUV, or YUV filters on RGB footage with:
# Source(pixel_type="YVxx").Cnv2("RGB",tunnel=1).YourRGBFilters().Cnv2("YV24",tunnel=2)
# or Source(pixel_type="RGBxx").Cnv2("YV24",tunnel=1).YourYUVFilters().Cnv2("RGB",tunnel=2)
# NO color conversion is done. So it's faster and 100% lossless
# 1 tunnel entrance. If RGB requested and clip is YUV, or vice versa, frame is tunneled and global var gCnv2Tunnel is set.
# But if clip is already RGB (UR YUV, if YUV requested), there is no tunnel.
# 2 tunnel exit. Only if global var gCnv2Tunnel is !="", tunnel exit is performed, otherwise normal conversion.
# Tunneling is tolerant against input/output formats to the maximum possible extent.
#
# Key features
# Cnv2(reference_clip) is a big helper for StackHorizontal() and a lot of other filters. For comparison output,
# StackHorizontal(original,processed.Cnv2(original)) is all you need, *no matter what pixel_type of original is*
# Cnv2() allows more than one output pixel_type. E.g. if no YV24 renderer is available, but YV12 and RGB24
# renderers, Cnv2("YV12 RGB24") at the end of the filter chain will convert all YUV footage to YV24, and all RGB
# footage to RGB24.
# For universal scripting, Cnv2("...") lines with all possible pixel_types reduce conversions, yet prevent crashes
# Cnv2() automatically omits or inserts the 'matrix=' parameter in the resolved base conversions, depending on the
# fact that a YUV<->RGB conversion is performed or not.
# For HD footage, Rec709 coefficients are used automatically.
# Cnv2() does not affect framereate performance, because it performs some string calculations during filter graph
# setup, but resolves to typically one base conversion or no conversion at all.
# No-Conversion situations are detected
# Conversions that yield best output resolution and least color space transformations are preferred
#
# Caveats
# Because of the global variable, multi-instances scripts work only correctly, if only one color space,
# (i.e. RGB *OR* YUV) is used as a tunnel in one script. There will be interference if at different places of
# the script RGB and YUV are both used as tunnels.
#
# Needs GScript()
#
# Version 1.0, 02-14-2015
#


EDIT: 2015-02-16 attached version is 1.02 with again slightly improved tunnel processing and description

[johnmeyer]

My biggest issue with these convert statement is the "interlaced=true/false" parameter. Since I don't think you can determine whether the clip is interlaced or progressive, the script won't be able to stop me from making that mistake.

However, getting some of the other things correct could be useful. I'll have to look at the script once it is approved for download.

[martin53]

My biggest issue with these convert statement is the "interlaced=true/false" parameter. Since I don't think you can determine whether the clip is interlaced or progressive, the script won't be able to stop me from making that mistake.

I thought about performing an autocorrelation over the whole frame and comparing that to the autocorrelations of the fields. If these are higher, combing can be assumed.
But then, with AviSynthV2.6 YV24 format will replace YV12 more and more, I think, and with all formats except YV12, the interlace parameter is of no use (regarding conversion).

The autocorrelation would consume some script performance - it's a different topic, I think.
EDIT: it is possible to read MediaInfo informations into a script. This is an alternative means for determining the interlaced state. Also, see here (http://forum.doom9.org/showthread.php?p=1709196#post1709196) for a desirable method to store it with the clip in the future.

[martin53]

This is an example of the tunnel feature.
function MSU_SmartDeblock(clip c) {
LoadVirtualDubPlugin("C:\Program Files (x86)\AviSynth 2.6\plugins\MSU_SmartDeblock_0.8.vdf","MSU_Smart_DeblockingVDF", 0)
c_ref = c.Cnv2("YV24 RGB32")
c_ref.Cnv2("RGB32",tunnel=1)
MSU_Smart_DeblockingVDF(1, 1, 1, 1)
Cnv2(c_ref,tunnel=2)
}


The user function will handle RGB32 clips directly, convert RGB24 to RGB32, process and return RGB32.
YUV clips are first chroma-upsampled to YV24, then channel-wise transferred Y->G, U->B and V->R without color conversion. I think this is also faster, but mainly there is no conversion loss.
The VDF filter works on a clip that has kinda psychedelic colors, but that should not affect its principal function.
Afterwards, the three channels are transferred back to the YUV channels (only if the function was called with a YUV clip!), and the filter returns a clip with either YV24 or RGB32.

Note: If the YUV clip is not YV24 (but YV12, YUY2 ...), there is chroma upsampling with the conversion to RGB format (Cnv2 first converts to YV24). The clip is not downsampled later in an additional ConvertTo() step from YV24 to the original format though, because c_ref is already RGB32 or YV24 in the example.

Note It has a special meaning that with tunnel=2, Cnv2() is not called with a pixel_type string but with a reference clip. Cnv2() uses this internally as an indication that the reference clip has the original color type YUV or RGB before tunneling. This makes the otherwise difficult decision easier, if de-tunneling is neccessary or not. In this simple example, it is not an issue. But when it comes to a script with more than one tunnel and with RGB-already plus originally-YUV clips, AviSynth with only local plus global variables may not be capable of sorting all things out correctly.

[Reel.Deel]

Is YV12 chroma placement treated the same as the internal ConvertTo...? Is not mentioned up above so I'm just wondering.

Do you have an immediate download for Cnv2? Attachments are good in the long run but can sometimes take days to get approved.

Edit: Attachment has just been approved, now I can answer my own question. :p

[martin53]

Is YV12 chroma placement treated the same as the internal ConvertTo...? Is not mentioned up above so I'm just wondering.
I hope I took all chroma placement options into account and handled them correctly. But I did it by code review, not by practical test. So if you find any issue, please report it.

[martin53]

@John,
My biggest issue with these convert statement is the "interlaced=true/false" parameter.

The following code fragement uses MediaInfo to read "progressive" or "interlaced", among other media file properties into the variable sMediaInfo.
The format of the string is prepared to easily use
i= 8 #(for interlaced property - set appropriately for each property)
item=Eval("Select("+string(i)+sMediaInfo)

I couldn't find how to retrieve TFF/BFF, however.

#Needs CallCmd and RT_Stats plugins, and MediaInfo.exe in %PATH%
sFile = ScriptDir() + RT_LocalTimeString() + string(Rand()) + ".avs"
sCommand = """cmd /c MediaInfo --Output=Video;sMediaInfo=\"\"\"\"\",0%Width%,0%Height%,0%FrameCount%,0%NumberOfFrames%,0%FrameRate%,0%FrameRate_Nominal%,0%Duration%,0%PixelAspectRatio%,\"%ScanType%\")\"\"\"\"\" """ + QuoteStr(s) + " >" + sFile
# Select: 0=Width, 1=Height, 2=FrameCount, 3=FrameCount_fallback, 4=FrameRate, 5=FrameRate_fallback, 6=Duration/ms, 7=PAR, 8=ScanType
CallCmd(BlankClip, Open=sCommand, Hide=true, debug=false, Synchronous=7)
Import(sFile)
RT_FileDelete(sFile)

[Wilbert]

The following code fragement uses MediaInfo to read "progressive" or "interlaced", among other media file properties into the variable sMediaInfo.
It's not really important whether the flag says progressive or interlaced (since progressive footage can be encoded a interlaced). What's important is whether there is combing or not.

[StainlessS]

IIRC, DGIndex does not report field order (although it shows it when processing in the progress window),
probably because there can be (illegal) field transitions in an mpeg. In DGIndex_Batcher, I run a decode
for a second or so, so that I can snatch initial field order, and just report that (but it aint perfect solution).
No idea how to get it from MediaInfo (perhaps user Zenitram will happen by).

sFile = ScriptDir() + RT_LocalTimeString() + string(Rand()) + ".avs"

Also, perhaps "Rand" is superfluous

RT_LocalTimeString(Bool "file"=True)
Returns current local time as a string.
Where digits Y=Year, M=Month, D=Day, H=Hour, M=Minute, S=Second, m=millisecond.
When bool file==False, then string in format "YYYY-MM-DD HH:MM:SS.mmm"
When bool file==True (Default) string is in format "YYYYMMDD_HHMMSS_mmm"
Also when file==True, function first waits until the system tick count is incremented (about every 10ms)
before inquiring system time. This is to prevent 2 consecutive calls returning the same time string.
Perhaps useful for temporary filename generation.

[martin53]

I'd like to point out the tunnel feature again.
Its basic goal is to avoid lossy YUV->RGB or RGB->YUV conversions, even when the formats of clip and filter do not match.
The conversion MergeRGB() allows to provide three Y8 single channels and pack them into RGB24 or RGB32 format, YtoUV() allows to provide three Y8 single channels and pack them into YV24 format.
ShowRed(), ShowGreen() and ShowBlue() extract the channels from RGB24/RGB32; GreyScale(), UtoY8() and VtoY8() extract the channels from YV24.

Tunneling just extracts and repacks the channels.
One way is
MergeRGB(VToY8, GreyScale, UToY8)
The other way is
YToUV(ShowBlue, ShowRed, ShowGreen)
Keep in mind that YUV->RGB from a TV range clip yields a slightly pale clip, because not the full number range 0...255 is used in TV range YUV clips, and RGB->YUV yields not a TV range, but a PC range YUV clip that uses the full number range 0...255.
Especially U and V of originally dark RGB pixels contain extreme 'negative', non YUV-typical values. RGB clips tunneled to YUV may be suitable for technical processing, but avoid all filters that evaluate the color of the YUV triple.
YUV->RGB tunneling yields RGB triples with R and B components close to 128 when G is small, G shows the original Y contrast.
If the unusal range and the unrealistic colors can be managed by the involved filters, thanks to AviSynth26 new formats Y8 and YV24 tunneling allows lossless processing of otherwise incompatible clips/filters.