Resize or not resize, that is the question.
 

Is it worth to resize to 704*576 when we are doing 1:1 or 2:1 DVD backups?
If we keep resolution 720*576, encoding will be really faster, or not?

For 1:1 I use to not resize to not introduce artifacts due to the resize (whatever the resizer, there is always more or less artifacts).
But for a 2 movie DVD (is that what you call 2:1 ?) you should resize to 704 because you will gain a lot of precious bits.

That's what I usually do, resize to 704x576.
A doubt: also resize to 704x576 when encoding anamorph?.

Yes it is.

720 --> 704 via resizing??? Since we do encodings in 704 we never used "resizing" from 720. That will end up in a generic PAR and not 128/117!

IF we go from 720 to 704 then we do use CROP, why?
Because both will be played back using 13.5Mhz.

The window of 720 is 53,333µs
The window of 704 is 52,148µs
The window of TV is 52,000µs

So 704 comes nearest to the TV. All other higher widths can only bee seen on a NON Analogue TV device like a PC Monitor.

When using 720 or 544 that is inefficient for TV purposes 704 or 528 is the best relation IF you do encode for TV purposes.

So 704 by just using crop doesnt result in resizing interpolation artefacts, its faster and anyway you wouldn't see the pixel data gain of 720 on your TV.

Calm down ! Do you know about Fitcd ? ;-) *
All what you are speaking about is managed by crop/border calc. Noone never meant that the resize is done by a simple XXXrezize(704,576) command line in the script.

* for memory : 720 -> 704 with FitCD first crops to 712, then resizes.

But this is to apply resize.
Why doesn't crop straight to 704?

For the same reason to use overscan : why not have ON the screen all the pixels that are IN the video ?
Using crop will give you the same film area that if you read directly the DVD on the TV set, but not all the picture that you should have on an over screen like a plasma (or like Inc says : "on a NON Analogue TV device like a PC Monitor")

But of course, this introduce some artifacts so you can choose to loose pixels insteed.

Not: I just checked my scripts and for a 1 movie DVD I crop to 704 then letterbox for overscan. I thought I encoded in 720 but no, I never used that res finally.

So what must I do to avoid resizing, please.
Crop and letterbox, crop and addborders.
When we use FitCD or Moviestacker, they give a script with resizers, so they are resizing. Hot to do for not resizing?

I answered in my previous post (that I was modifiying while you typed your question ;-))

Thanks.

And the script, extracted from a very old thread (that means that the filters used are now obsolete - forget this part) :
http://www.kvcd.net/forum/viewtopic....ght=crop#68572

In case of NTSC to PAL or if format is untouched but resized overscan is applied then this makes sense ;)

Like Phil mentioned.

crop from 720 to 704x576 and apply an overlayed overscan by using letterbox(16,16,16,16) finally

This avoids scaling/interpolation and shows the DVD content in its samne area like it would have been played back as original where also these pixels in the letterbox area wouldnt have been shown.

You can use the argument "But I want to keep/see more of the given 720x576 active pixels." But then you have to resize.

I know that, and I give not to those periferic pixels any importance if the increased encoding speed compensates it.
Thanks.

Luis,
Encoding at 704 is faster to encoding at 720, this answer to your question about speed.

But this 704 can be obtained by cropping or resizing. And the two methods won't have a great difference in term of speed (except if you use Lanczos as resizer that is a little slow).

So your choice is still : do you want to lost pixels (and so use crop) or to keep all pixels (and then use resize).

:?: Using crop for 704x480 (NTSC) DVD, is this correct?

Mpeg2Source("PATH\NAME.d2v",cpu=4)
Crop(8, 72, 704, 336) # 72_72
#Crop(8, 16, 704, 448) # 16_16
#Crop(8, 0, 704, 480) # fullscreen

FluxSmooth()
TemporalCleaner(ythresh=5,cthresh=7)
Undot()
DCTFilter(1,1,1,1,1,1,0.5,0)

Addborders(0,72,0,72) # 72_72
#Addborders(0,16,0,16) # 16_16
LetterBox(16,16,16,16)

:?: Which filters are currently deemed "best" for single movie DVD's (to replace the ones above)? Simple questions, but I have a tendency to screw things up without some guidance from you guys. :oops:

Currently using only:

RemoveGrain(mode=2)
TemporalSoften(2,3,3,6,2)

totally
You shouldnt use DCT filter anymore as it cuts too much high freqs. when applying Notch afterwards it will result too smooth. And shurely if other Detail-stealing filters have been added before.

For a clean DVD I would only use LRemovedust(17,1) or LRemoveDust(17,2) not more according to denoising.
And even that one (even it keeps most pixels of all) does a tiny bit erase details.

Thanks, Incredible. :D I'm now trying to locate LRemovedust(). Several posts mention it, but it is a bit confusing. :?

hi nicksteel, look here for lremovedust:

http://www.kvcd.net/forum/viewtopic.php?t=16094

It's a function, and there are 2 versions: for SSE capable and non SSE capable cpu's. You should definitely try it, it works like a charm :D

BE CAREFULL !
The values I gave (72 and 16) are for PAL sources (2.35 and 1.85). For NTSC sources I don't know how large are the black borders you have to remove. Check it first on a source !

And for filters I use RemoveGrain().Deen().
Nothing more.

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


LRemovedust is NOT a filter but a fast function which uses filters from the Removegrain package at www.removegrain.de.tf.
Search in here in the LimitedSharpen Thread to find the LRemovedust() function fom Didée.

Thanks, Incredible.

Think I will start with Boulder's routine (above). I don't know if my 2.8 Gateway 820 dual-core is Prescott P4 or not, so will try different SSE versions.

Im not shure, but AFAIK your new "Toaster" even supports SSE3.
Or is that only on newer Athlon 64's supported .... hmmmm

Try CPU-Z, it will tell you which instruction set your CPU can deal with. I'm quite sure you can use the SSE3 versions of Repair and RemoveGrain and SSETools.

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.

You are so much focused on the with that you do not understand that I am talking about the height !
Look at the lines I have in my script :
The "72" and "16" are for PAL SOURCES.
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 ?

I will try.

And you are just thinking in already "detailed" X.xx:1 croppings which arent at ANY interesting to the MAIN subject ... started by prodater and also as you really dont know WHATs really the state of Nicsteels source - just by quoting his lines.
I think "I" understood HIS purpose of trying to understand the "Logic".
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":

Finding out standard (MOD16) borders of 2.35:1 and 1.87:1 or 1.85:1 or WHATEVER when these have been set when digitally telecining the Footage can be "seen" on the original or if someone doesnt have that experience/feeling then it can be figured out using displaying/cropping softwares.

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.

Dont explain me PAL, NTSC, and Borders. I know it and not only cause what have been written in Posts, optimalScripts, www sites or xxxDemystified Literature, its a math ... btw. explained by myself in here many times.

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:
Lets do kick out these remarked lines:

So "I do read your lines" and see your'e cropping a 720x576 to 704x432 and finally you just apply a letterbox() on that "cropped" result?
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.

YOU just forgot that YOU weren't the guy that I was talking to. I know that YOU won't use "blindly" the value 72.
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 :!:

It's because he posted this script, and because you did not correct the crop lines - you erased them - that I told HIM that the values HE used weren't correct. If you had sent all your explanations about not using fixed values to the correct person (that means HIM, not ME), my post would never existed.

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 ;))

Dont mix up things. I dont take every post line by line, but one line Im shure of you know of which Im talking about. Just comparing to Jorel is nosnense. "Jorel gots a problem" vs. "I got my limits" thats a clear difference.

Sorry ... did I catch up something wrong?
Isn't that post adressed to me?
If its not adressed to me then I do excuse. But I'd like to know that other Inc. in here ;)

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.

Cropping is not linked to size but to quality. The less you have to encode, the better will be the quality.
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...

Inc says that you don't need because LRemoveDust is already a combination of filters.

: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.

That's generally what I do also but for such little compression you can also use the transcoder that is included in DVDLabPro.

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.

It asks you the size of the file you want to obtain if I'm not wrong. Actually it is less convenient than the automatic mode in DVDShrink.

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

I have used them in my scripts without any problems.

Because they do not take in account borders that exist in original DVD sources and that should be cropped before the calc to enhance the result (and speed).