VBV buffer, KDVD Matrix, padding script questions
I have 2 questions.
1. I'm encoding KDVD mpeg-2. Does the vbv buffer size have an impact on the final file size? Especially when predicting using cqmatic? I'm now using 224 what is the recommended value for KDVD? 2. I read about timberwolfs matrix comparisons and got a bit confused. Kwag gop and tmpgenc default matrix? Kwag gop and andreas matrix? Are there more settings needed to be made except loading a kdvd template in tmpgenc? 3. Should I check "enable padding not to be lower...." when using cqmatic and encoding KDVD? 4. Dialhot when using your KDVD simple script: Mpeg2source("******", cpu=4) LanczosResize(720,432,8,76,704,424) Deen() Undot() AddBorders(0,64,0,80) What should I set motion search precision to? |
Re: VBV buffer, KDVD Matrix, padding, dialhot script questio
Quote:
Quote:
Many people do compare matrixes/Gops on a single movie which is wrong as every movie gots its own induvidual motion/amount of dark areas/sharpness/Details. Quote:
Quote:
My *little* comment: Deen() also beside temporal- gots a spatial routine running in default mode, so that undot() afterwards IMHO wont find any dots anymore as they have been killed by deen() already and undot() filters much mor lighter than deen(). Also ... deen() for my taste is a bit "heavy" on very good sources. So you have to check your sources quality before. On STARWARS (Boxset) for instance I just used an ... undot() Temporalsoften(1,2,3,5,2) where undot() gives temporalsoften a "light" hand before. And Tempsoften itself only uses a temporal denoising also here at light settings. Heavy or regular spatial softeners/denoisers (except undot() for instance as its light) do plain details - thats a spatial by radius working side-effect ;) But Dialhot made his own experiences so my comments do not represent a doubt. Also everything depends on someones own "gusto" and for shure the sources quality someone is actually dealing with. Many people also at some outside forums did use "undot().deen()" but on the other side they call the Notch Matrix to be evil "as it cuts tooooo much frequencies" :lol: but they already did filter these high frequencies using deen and its also spatial beside temporal routine. |
Thanks for the help!
The link to the timberwolfs thread is: http://www.kvcd.net/forum/viewtopic....berwolf+matrix |
Re: VBV buffer, KDVD Matrix, padding, dialhot script questio
Quote:
Quote:
Quote:
Quote:
Because once uppon a time, I hated deen... once uppon a time ! |
@Jollito
There are different kinds of matrixes from Andreas of the DVD-SVCD-Forum.de in germany, like 99'ers 78'ers Matrixes etc. And as you can see by the Thread Date, that Thread is mega old. ;) Quote:
You mean your optimal Script right? Well, I know that this one gots its purpose for handling already compressed Sources where some DCT Artifacts already do occur. I testet it on some of my DVB-T streams which are broadcasted like bad encoded mpeg4's from the web! One Transponder for DVB-T only gots about 14,75Mhz and often one trnasponder carries up to 4 TVChannels. So 14.75/4 = 3.68 Mhz = 3.68Mbit in average Bitrate @ VBR, means 3768kbit AVG. Now you say "thats far enough for 720x576 including even including 2 AC3 384kbit Tracks" ... but the truth is that mostly the average Bitrate of the Videostream is about 2500kbit even if one mp2 2CH Stream is added. So the encoding engines at the TVstations are always set "like" if no motion estimation is used - well it seems so *lol --- means that these 2500kbit AVG @ VBR Streams do look sometimes mega ugly especially in complex scenes or even if its encoded interlaced 8O So even if in here mpeg4 sources are no subject anymore, your Optimal Script developement should continue on DVB sources as they are totally lega when streamed by someone of his own. But finally as you said, one deen() followed by a TemporalSoften to me means 2x Temporal Denoising which "could" affect the stream in a negative way. 90% of the DVB (PVA/TS) Sources do not contain that much noise but DCT Artifacts and so we should develope a routine where DCT Blocks should be handled by a dynamically postprocessor like MA. but less blur :D Quote:
|
Quote:
Quote:
I often said that the scripts I do are first for my own usage and I just sharing them because there is no reason to not sharing. Quote:
Take a DVD (any DVD you want), try this script and tell me : Code:
Mpeg2Source("PATH\NAME.d2v",cpu=4,idct=7) |
I wouldn't go above 5 in TemporalSoften's thresholds. It's known to cause smearing. My personal setting is (2,4,5,15,2) for DVDs (and for all analogue captures) that are very noisy or need some extra compressibility and (2,3,3,6,2) for increased compressibility and slight denoising.
|
I meant "less blur" in the sentence where I was refering to MA! As MA gots a processing blur by unfilter (as you know).
I wanted o use the Motionadaptive routine for Postprocessing instead of blurring ;) Code:
DRemoveGrain() And thats why I said "Its opun someones own "gusto" " :) I do it the following way as I do end up with 2 Movies on one DVD-R: - cropping the source from 720 to 704 in its width and cropping the black borders. (I try to crop the height at Mod16 IF NO more then 2-3px in the height need to be deleted for obtaining a MOD16 stream, otherwise I use MOD8). And even if I crop at nonMOD source Borders values, no matter in case of DVD-R. Why only Cropping?: Because I want to avoid the image to be resized/interpolated. So I got finally my untouched TV active Movie area of that source. - Filtering the source by using undot() or removegrain(1), followed by a minimal TemporalSoften(1,2,3,5,2), I do choose 5 as threshold as I want to avoid temporal artifacts in moving plain areas ;) - The obligatory Addborders() follows - And finally I do choose a simple Letterbox to fill out the overscan area. In "scripting" words: Mpeg2Source("PATH\NAME.d2v") Crop(8,x,-8,-x) undot() TemporalSoften(1,3,3,5,2) Addborders(...) Letterbox(16,16,16,16) I choose often a letterbox means a non resized overscanning as many movies of mine are in 2.35:1. That Example above is as said for really good sources. Quote:
:) |
DRemoveGrain is the SSE2-optimized version, some 8-12% faster.
|
Quote:
Undot + TemporalSoften... humm... in that case you should drop both line and put a simple "Deen". As you told, your settings are for "very good new released DVD movies or very good remastered DVD Releases". Unfortunally, I do much more "normal" (;-)) DVD recently and Undot (or removegrain) alone is NOT enought ! It's incredible how much noise is added on some sources (I'm definitly sure it is added intentionaly). I don't have the DVD at the office but I will post snapshots taken from a Disney Classic (Sleeping beauty) with and without Deen. It's amazing... Note: to be clear, the script I gave is for KVCD. For 2-movie KDVD you have to remove the temporalsoften. Note2 : and you didn't even use a deblocking in mpeg2source ? My god... we don't have the same sensitivity relating to noise :-) |
Quote:
Quote:
Remember my "Black Rain" Sample in the "How funny" Thread? That one is a pain in the ass :( For my luck, my recent past encodes got clean sources, but that could change very fast when getting an older movie to encode 8O :wink: Quote:
Quote:
I only use cpu=x IF really recognisable DCT artifacts are present in the source, if not theres no need for me as cpu=x also softens even at 4. I did had a look at the orig DVD Starwars Boxset VOBs using Bitrateviewer and the Q curve was verrrrry low, so there for instance was no need for a deblocking. :) The internal routines of mpeg2source() do provide to the cpu deblocking command the actual frame given Quantizer Value which will actually be used as "quant" value. Only in BlindPP() quant as paramer does exist as avisynth directly cant parse the quantizer out of the source but mpeg2source() can do. So on Sources which are encoded at very high bitrates a avg quantizer will be verry low. In Matrix Vol1 I really needed cpu=4 as the PAL release gots a bit higher quantizer peaks. :) |
Quote:
Quote:
My scripts are more "mostly convenient" whatever the DVD. |
Site design, images and content © 2002-2024 The Digital FAQ, www.digitalFAQ.com
Forum Software by vBulletin · Copyright © 2024 Jelsoft Enterprises Ltd.