Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
14th February 2015, 21:18 | #1 | Link | |
Registered User
Join Date: Mar 2007
Posts: 407
|
Universal ConvertTo...() wrapper Cnv2()
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 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. Quote:
Last edited by martin53; 17th February 2015 at 18:09. |
|
14th February 2015, 21:49 | #2 | Link |
Registered User
Join Date: Feb 2002
Location: California
Posts: 2,685
|
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. |
14th February 2015, 22:38 | #3 | Link | |
Registered User
Join Date: Mar 2007
Posts: 407
|
Quote:
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 for a desirable method to store it with the clip in the future. Last edited by martin53; 15th February 2015 at 11:06. |
|
15th February 2015, 10:42 | #4 | Link |
Registered User
Join Date: Mar 2007
Posts: 407
|
This is an example of the tunnel feature.
Code:
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) } 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. Last edited by martin53; 17th February 2015 at 21:44. Reason: fixed bug |
15th February 2015, 11:10 | #5 | Link |
Registered User
Join Date: Mar 2012
Location: Texas
Posts: 1,664
|
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. Last edited by Reel.Deel; 15th February 2015 at 11:23. |
15th February 2015, 11:21 | #6 | Link |
Registered User
Join Date: Mar 2007
Posts: 407
|
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.
Last edited by martin53; 15th February 2015 at 11:24. |
15th February 2015, 18:15 | #7 | Link | |
Registered User
Join Date: Mar 2007
Posts: 407
|
@John,
Quote:
The format of the string is prepared to easily use Code:
i= 8 #(for interlaced property - set appropriately for each property) item=Eval("Select("+string(i)+sMediaInfo) Code:
#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) Last edited by martin53; 15th February 2015 at 19:29. |
|
15th February 2015, 19:47 | #8 | Link | |
Moderator
Join Date: Nov 2001
Location: Netherlands
Posts: 6,364
|
Quote:
|
|
15th February 2015, 19:54 | #9 | Link | |
HeartlessS Usurer
Join Date: Dec 2009
Location: Over the rainbow
Posts: 10,980
|
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). Quote:
Code:
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.
__________________
I sometimes post sober. StainlessS@MediaFire ::: AND/OR ::: StainlessS@SendSpace "Some infinities are bigger than other infinities", but how many of them are infinitely bigger ??? |
|
16th February 2015, 18:16 | #10 | Link |
Registered User
Join Date: Mar 2007
Posts: 407
|
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 Code:
MergeRGB(VToY8, GreyScale, UToY8) Code:
YToUV(ShowBlue, ShowRed, ShowGreen) 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. Last edited by martin53; 16th February 2015 at 22:11. |
Thread Tools | Search this Thread |
Display Modes | |
|
|