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. |
20th September 2014, 03:16 | #1 | Link |
Registered User
Join Date: Jul 2011
Posts: 1,121
|
Spline64 - Faster?
Just wondering, is there any optimizations i have missed for Spline64?
Like an OpenCL version etc? Or perhaps there is a similar approach that's quite faster? Nothing special of use, just noticed that it could be quite slow when resizing to 1080p (which is understandable). |
20th September 2014, 03:41 | #2 | Link | |
契約者
Join Date: Jun 2008
Posts: 1,576
|
Quote:
Last edited by Keiyakusha; 20th September 2014 at 03:44. |
|
20th September 2014, 10:13 | #4 | Link |
Join Date: Mar 2006
Location: Barcelona
Posts: 5,034
|
I don't find Spline64 that slow compared to the "standard" resizers. Here's some numbers taken with AVSMeter resizing a SD clip (720*576) to 1920*1080:
Code:
pointresize(1920, 1080) : 615 fps lanczosresize(1920, 1080): 256 fps spline36resize(1920, 1080): 256 fps spline64resize(1920, 1080): 215 fps |
20th September 2014, 15:37 | #6 | Link |
Registered User
Join Date: Jul 2011
Posts: 1,121
|
Hmm, interesting, 215 fps is far faster than i achieved in my test (though i encoded with x264, but that wasn't the bottleneck funny enough).
The only thing i did was pretty much, resize and then ConverttoYV12, and i can't see that being the culprit as it simply "discards" data, which should be fairly fast. I think i compared 64 to 32, and in this case i saw a very small different, but to the better (it's very simple cartoon like stuff, so edges and small lines etc, Happy Wheels). Will have to do a test next time i do the same thing and come back. Still, couldn't this stuff be improved a lot with OpenCL, as isn't Resizing something that GPUs handle really well? |
20th September 2014, 16:00 | #8 | Link | |
Registered User
Join Date: Jul 2011
Posts: 1,121
|
Quote:
But will do another recording now, and see if i get same results. |
|
20th September 2014, 16:46 | #11 | Link |
Registered User
Join Date: Mar 2012
Location: Texas
Posts: 1,664
|
Since you're converting to YV12 anyways, why don't you do something like this? Did not try but I assume is a little bit faster.
Code:
Avisource("Z:\Happy Wheels - 2014-09-18 9-58 PM.avi").ChangeFPS(30, linear=true) ConvertToYV12(matrix="Rec709", interlaced=false) ZoomBox(width=1920, height=1080, ResizeMethod="Spline64Resize") Amplify(8.0) |
20th September 2014, 16:50 | #12 | Link |
Registered User
Join Date: Jul 2011
Posts: 1,121
|
I Convert to YV12 afterwards as it reduces Chroma Bleeding (as it has some very small colored text at times).
But yeah it will be faster, about 15fps it seems. Can't see how you get 200fps with Spline64, i get 50-60. And if i don't do anything and just Decode i get about 400-500, so the Codec isn't the bottleneck. |
20th September 2014, 17:21 | #14 | Link | |
Registered User
Join Date: Jul 2011
Posts: 1,121
|
Avisynth+ r1697.
CPU Intel i5 760 @ 4Ghz. ZoomBox script (It's Not mine, found it some years ago). Quote:
|
|
20th September 2014, 17:31 | #15 | Link |
Join Date: Mar 2006
Location: Barcelona
Posts: 5,034
|
Have you tried a plain Spline64Resize or only Zoombox? There's a lot of floating point math in that function which might explain the lower speed.
Just tried it. The culprit is clearly the fact that the resizer is a lot slower when processing RGB data (I get 35 fps instead of 215 fps). Last edited by Groucho2004; 20th September 2014 at 17:47. |
20th September 2014, 17:48 | #16 | Link |
Registered User
Join Date: Jul 2011
Posts: 1,121
|
Done with and without, and posted it, ZoomBox is clearly a bit slower.
Oh, that's very good to know. Hmm, problematic that i have to resize from 900x500 to 1920x1067 and add black borders in order to keep aspect ratio. I don't think this can be done with YUV as it can't be divided by 2. Hmm, perhaps i can add borders before resizing... EDIT: Then again YV12 will destroy the colored text as it's so small. Damn, i just can't win;P I guess YV24 first and YV12 later will improve it somewhat. Last edited by zerowalker; 20th September 2014 at 17:52. |
21st September 2014, 01:32 | #17 | Link |
I'm Siri
Join Date: Oct 2012
Location: void
Posts: 2,633
|
how about split every rgb frame to 3 neighbor y8 frames, then it's in yuv colorspace to resizers now, and it's lossless compared to converting to yv24 first (converting to yuv will lose about 2bpc precision)
Last edited by feisty2; 21st September 2014 at 01:46. |
21st September 2014, 13:30 | #19 | Link |
I'm Siri
Join Date: Oct 2012
Location: void
Posts: 2,633
|
xxxsource
r=showred ("y8") g=showgreen ("y8") b=showblue ("y8") interleave (r,g,b) spline64resize (1920,1080) mergergb (selectevery (3,0),selectevery (3,1),selectevery (3,2)) donno if it will be faster I guess the whole convert to yv12 stuff is somehow a bad idea since there're texts in the clip, you will obviously observe some quality loss around the texts (what you said, "color bleed"), yv12 could be not so nasty to natural images but computer graphics will be worsened a lot if convert them to yv12. if you just gotta stick to yv12 somehow, I advice "bt 2020" matrix as an advanced choice, it splits brightness and colors under linear rgb colorspace while "bt 601" and "bt 709" split them under gamma compressed rgb colorspace (which leads to some tiny brightness information gets distributed to chroma channels then chroma channels get downsized and image quality heads to hallelujah disaster) edit2: just checked "dither" document, it still adopts non constant luma method (same as old "bt709"), guess u gotta do gamma linear conversion urself the better way to get a not so crappy yv12 output (slow!) Code:
#rgb32 input# r=showred ("y8").convert8to16 (tv_range=false).Dither_y_gamma_to_linear (tv_range_in=false,tv_range_out=false,curve="srgb",sigmoid=true).dither_resize16nr (1920,1080,kernel="spline",taps=4) g=showgreen ("y8").convert8to16 (tv_range=false).Dither_y_gamma_to_linear (tv_range_in=false,tv_range_out=false,curve="srgb",sigmoid=true).dither_resize16nr (1920,1080,kernel="spline",taps=4) b=showblue ("y8").convert8to16 (tv_range=false).Dither_y_gamma_to_linear (tv_range_in=false,tv_range_out=false,curve="srgb",sigmoid=true).dither_resize16nr (1920,1080,kernel="spline",taps=4) dither_convert_rgb_to_yuv (r,g,b,lsb=true,output="yv12",matrix="2020",chromak="spline64",mode=-1) Dither_y_linear_to_gamma (tv_range_in=true,tv_range_out=true,curve="2020",sigmoid=true,u=2,v=2) #round to 10bpc now or dither to 8bpc (change "curve" in "Dither_y_linear_to_gamma" from 2020 to 709 if using 8bpc) #encode with x264 with "bt2020" matrix flag and selected transfer characteristics (curve) flag Function Convert8To16 (clip input, bool "tv_range") { tv_range = Default (tv_range, True) iCceil = (255-128) / (255.5-128) * (65535.5-32768) + 32768 Yexpr = "0-0 ; 255-65535 ;65535-65535 " Cexpr = "0-0.5;0.5-0.5;128-32768;255-"+String(iCceil)+";65535-"+String(iCceil) fullrange = StackVertical (input.Dither_gen_null_lsb (), input). \ SmoothCurve16 (Ycurve=Yexpr, Ucurve=Cexpr, Vcurve=Cexpr, mode=0, interp=0, HQ=True, \ dither=-1, limiter=False, TVrange=0) output = tv_range ? input.Dither_convert_8_to_16 () \ : fullrange return output } Last edited by feisty2; 21st September 2014 at 15:45. |
21st September 2014, 15:47 | #20 | Link |
Registered User
Join Date: Dec 2007
Location: Germany
Posts: 632
|
You can also resize the chroma straight in one go to YV12 like this.
It avoids resizing the chroma plane two or more times, reducing blurring to the minimum. Code:
AddBorders(0,3,0,3) #make up for 16:9 (900x506) ConvertToYV24(matrix="Rec709") Y = ConvertToY8().Spline64Resize(1920, 1080) U = UToY8().Spline64Resize(1920/2, 1080/2, src_left=-0.5) V = VToY8().Spline64Resize(1920/2, 1080/2, src_left=-0.5) YToUV(U, V, Y) #results in YV12 Last edited by TheSkiller; 21st September 2014 at 15:51. |
Thread Tools | Search this Thread |
Display Modes | |
|
|