Thanks, Phil. :D Will do. Will try out the LRemoveDust filters tonight.
|
@ Phil
For NTSC is 704 exactly the same value ;) A FULL ntsc active video area on tv is 648x486 (yep). So such an active window on a DVD would be result as 712x486. But as our encodings will do result as a "cropped" full ntsc area, means 640x480 on later TV viewing, then we can use the relation of 640x480 on our DVD encoding and that exactly also an active width as in PAL, means 702x480 which does result in a 704x480 encoding. So crop at 704x480 :) Phil (just a point of taste), I do avoid using removegrain() in its defaults as it plains a lot of "pocito" details. Thats why I do love that LRemoveDust() Function as it uses a special way to avoid the spatial overshoot on details. With LRemovedust() you even dont have to use Deen() anymore as it plains a lot (its spatial compound of the c3d default mode is like an eraser, paired with that temporal artifacting compound). The Result is a cleaner, more detailed an FASTER encoding as LRemovedust is fast. I came to a conclusion .... If LRemovedust(17,1) plains too much details, then ... just don't denoise as other denoisers I know would do plain even more. @ nicksteel Quote:
Search in here in the LimitedSharpen Thread to find the LRemovedust() function fom Didée. |
Thanks, Incredible.
Quote:
|
Im not shure, but AFAIK your new "Toaster" even supports SSE3.
Or is that only on newer Athlon 64's supported .... hmmmm |
Quote:
I would also recommend you try tsp's MT plugin, it adds some multithreading capability to Avisynth. If you have a dual-core CPU which also supports hyperthreading, you could run 4 threads. Try MT("LRemoveDust(17,1)",4) and see if you notice any difference in the performance. http://forum.doom9.org/showthread.php?t=94996 Remember to use the latest Avisynth, now at release candidate stage. |
Quote:
Look at the lines I have in my script : Code:
Code: For NTSC the border in a 2.35:1 sources is smaller than 72, so you must crop less than this else you will cut the head of the character ! Capisce ? Quote:
|
Quote:
Quote:
Some people dont just want the food, the want to know WHAT they're eating. Now related to NicSteels post to make it a bit retrospectively: The logic of bringing 720x480! to 704x480 IS CROPPING! if you won't loose quality by resize interpolation and IF you want the stream to be still played back in the SAME window as it was meant to be when mastered as original on the DVD! As that tiny little SAP does work in 13.5Mhz period. Now lets push the FFW Button to "Capice": Quote:
Yep Inc. you still think in "overlayed" overscans. I do so as I do have a 16:9 TV where at least at a 1.778:1 DVD I want to avoid watching borders! Means I want to see the borders they where meant to be there at the "academy format" telecine of 720x576. Quote:
16,16 at width (yep yep, again the focussed width) can be used for PAL/NTSC .... the HEIGHT where we would determine the original border cropping can be "figured out" easely using DVD2AVI (if setting within bigger MODs) or that tiny little dv2viewer appl. Remeber? Then you see in which range the sources height is (2.35:1, 1,78:1 or whatever) and .... surprise ... you even have a pre builded cropping line. So I personally btw. wouldnt use ANY of these "static" suggested resize parameters as people never will understand WHY it is correct in such a case or why it isnt. I thought we are at an "advanced" movie conversation area? Phillipe, keep your distant, noirotic coool way from your top to the bottom of the roman people (at least when we both are talking/ diskussing) on YOUR side. You can treat every person you want as a fool but people which do have at least something in the head made already their experiences if beeing a fool or not. I do make it in here official and not via PM cause you do it in here - in the official area. Its quite symphatic ... in a time where the (also non warez) activity in here shrinked to almost 3% compared to the time before ... to have then almost 50% of these posts in such a distant cool way - nice! ;). So don't worry I got my "capice". These lines above are not related to this crappy 704/borders- or whatever -subject. Its in general and you do focus it many times as new. |
Lets make a trim() on the "Capice" and applying a loop:
Quote:
Quote:
And Nicsteel uses it. Ough. I don't want to tease you ... really ... (ok, a bit), but YOUR'E the one who is focussing on "read my lines" .. "capice?" :lol: BTW my capice is : Many DVDs arent exactly at standard 2.35:1, 1,778:1 at MOD16, so by cropping using "static" 16, 72 Values could result in by few pix cropped movieareas OR even worst, some height pixels could still be present where some further applied filters would also filter "these" present few pix borders. A sharpener for instance ... ough ... not imagine how it will be seen "uneasy" on a normal TV. |
@Inc
I see you like doing as Jorel taking each post, line by line, but I won't don't that myself. The story is simple : I was talking about height (values 72 and 16 are on the height) and you answer to me "Phil, 704 is the correct value even in NTSC". So ? What is the link between something concerning the height and the fact that 704 is the correct width to use for both format ? Did I say that 704 was not correct ? Did I say that 480 was not correct ? I said that 72 and 16 is not correct. Period. Quote:
NICKSTEEL is not YOU. That is why I told HIM that HE has to be carefull because if HE uses 72 (things that YOU will never do) then HE will have problems. Look at the script HE posted :!: Quote:
Note: no-one never noticed that when I posted my script I did not uncomment the line correctly (fortunally I put always comments in my scripts even when I do them for me. They eased to understand that there was an error here - and Nicksteel corrected it by himself BTW ;)) |
Quote:
Quote:
Isn't that post adressed to me? Quote:
Essentially Im not interested in widths heights, PALs, NTSCs in that post or where ever. The Essential you can read in the line dealing with the words "cool way". Its not my job to give you hints on that, but I do point on it if it comes to limits like in threads before which I dont quote now - hint: "taxes". I think its all mentioned, think about it or not. |
:D Thanks for everything guys.
Did first encodes with LRemoveDust() last night. No problem with SSE3 dlls. Encoded non-cropped 95 minute film in about 60 minutes while running 2 DVDShrinks concurrently, so pretty fast. Couple questions though. First encode (DVD NTSC Film) was true anamorphic (widescreen , but no borders in raw source). Also detected as anamorphic by FitCD. Size was no problem, so I did not crop, just processed with 16:9 flag in Tmpgenc. :?: Should I always crop to 704, even if no size problems when final size allows muxing with original AC3? LoadPlugin("C:\video\moviestacker\Filters\MPEG2Dec 3dg.dll") LoadPlugin("C:\video\moviestacker\Filters\RepairSS E3.dll") LoadPlugin("C:\video\moviestacker\Filters\RemoveGr ainSSE3.dll") LoadPlugin("C:\video\moviestacker\Filters\SSE3Tool s.dll") Mpeg2Source("C:\film\film.d2v",idct=7) LRemoveDust_YV12(17,2) function LRemoveDust_YV12(clip input, int clmode, int "limit") { limit=default(limit,2) clmode=default(clmode,17) repmode = 2 clensed = Clense(input) rep = Repair(clensed, input, mode=repmode) rg = RemoveGrain(rep, mode=clmode) return LimitChange(rg, input, limit) } Second encode (DVD NTSC Film) had 60 pixels top and bottom in DVD2AVI. Processed with 16:9 flag in Tmpgenc and used: LoadPlugin("C:\video\moviestacker\Filters\MPEG2Dec 3dg.dll") LoadPlugin("C:\video\moviestacker\Filters\RepairSS E3.dll") LoadPlugin("C:\video\moviestacker\Filters\RemoveGr ainSSE3.dll") LoadPlugin("C:\video\moviestacker\Filters\SSE3Tool s.dll") Mpeg2Source("C:\film\film.d2v",idct=7) Crop(8, 60, 704, 360)# 60_60 LRemoveDust_YV12(17,2) Addborders(0,60,0,60) # 60_60 function LRemoveDust_YV12(clip input, int clmode, int "limit") { limit=default(limit,2) clmode=default(clmode,17) repmode = 2 clensed = Clense(input) rep = Repair(clensed, input, mode=repmode) rg = RemoveGrain(rep, mode=clmode) return LimitChange(rg, input, limit) } :?: Do I need to use more filtering than only LRemoveDust() as in above? The output looks very good. |
Quote:
If you encoded in 720 with a CQ=90 and the size is still smaller than 4.37, so for sure you have no need to encode in 704. But if the CQ was 65... Quote:
|
:D Thanks, Phil. CQ was 90. I only take other measures if CQ falls below 85 or so.
In fact, if CQ is 90 and final DVDLab Pro size is a little large (say DVDShrink 95% compression), I use DVDShrink to size final output. |
Quote:
|
Shows you my level of ignorance about DVDLab Pro. :oops: Will try the transcoder next time instead of DVDShrink. :?: Does DVDLab Pro give indication of compression level required?
I try to do all my encodes to allow AC3 and sometimes run into slightly oversized final files. Sometimes I have to go to MP2 files, but try to avoid it whenever possible due to use of external sound system. I always give video quality precedence over audio, but like to have both. |
Quote:
|
You might want to use ConverttoRGB24() at the end of your scripts to ensure the colorspace conversion is done properly, that is, if you use TMPGEnc. For CCE you need ConverttoYUY2(), of course.
I wouldn't use limit=2 with DVD sources, limit 1 should be enough. For a slight extra compression, add parameter limitU=255 to LimitChange. It will allow chroma to be processed just as RemoveGrain(mode=17) would do instead of limiting the change to the amount of pixels you set the limit to in LRemoveDust. I'm quite positive you won't notice any difference at all, but the encoder will :wink: |
Note: I split the thread, the further, non-resizing discussion is here : http://www.kvcd.net/forum/viewtopic.php?t=16122
|
Why not use the VM functions (also used in DIKO), it saves from doing manual calculations (done internally by the script) and so the consequent errors caused by manual resizing and adding borders can be ommitted!!!!.
You need to pass parameters to it thru avs script Code:
Loadplugins Code:
Function DivXResize(clip c, int WIDTH, int HEIGHT, int OVERSCAN, string RESIZER, int widescreen) { |
Quote:
|
Site design, images and content © 2002-2024 The Digital FAQ, www.digitalFAQ.com
Forum Software by vBulletin · Copyright © 2024 Jelsoft Enterprises Ltd.