Suggestions for improving the quality!

[diimaan]

What? SAR remains the same whether you crop or not. And you should absolutely crop out the black bars in the encode.


Go ahead and crop it to 710x368, then encode with the setting "--sar 32:27" in the x264 commandline. The encode will display correctly (at about 2.35:1).

:thanks: Creamy!

and any x264 devs can answer me?
what decides the speed factor of x264 encoding? The CPU? or RAM?
If it's cpu? can a faster dual core outperform quadcore?

[diimaan]

You should use MKVToolnix for muxing mkv files.
There's no need to crop 2 pixels from the left side in your sample, so your cropped resolution should be 712x368.
You should encode at cropped resolution because Blue_MiSfit is exaggerating. It won't affect AR that much. (cropped (http://img37.imageshack.us/img37/1589/withcrop.jpg) vs not cropped (http://img707.imageshack.us/img707/5817/withoutcrop.jpg)) The error is a fraction of a pixel as I see it.
For this source use --sar 32:27 as Blue_MiSfit suggested.
If you'll set sar you won't have to mess with AR while muxing.

wow! thank you too MokrySedeS.
I just read abt mkvtoolnix and did some sample muxing with it! cli as well as mmg... :)

I never thought I get this much help from fellow members... :)

right now I'm leaning towards resizing up to 848 x 360 as Lord_Mulder suggested! ;)
cos it's closely matching my N900's screen :D

[creamyhorror]

right now I'm leaning towards resizing up to 848 x 360 as Lord_Mulder suggested! ;)
cos it's closely matching my N900's screen :D
There's little benefit in resizing to 848x360 during the encode; it will just increase the filesize a bit under CRF (since the resolution is now higher).

Leaving it at the original post-cropped resolution is the best solution, unless your device cannot display anamorphic H.264 video properly, or if it has an absolutely shit scaler.

[diimaan]

There's little benefit in resizing to 848x360 during the encode; it will just increase the filesize a bit under CRF (since the resolution is now higher).

Leaving it at the original post-cropped resolution is the best solution, unless your device cannot display anamorphic H.264 video properly, or if it has an absolutely shit scaler.

hmmm well! am not sure abt the scaler in the default player! but it does have a mplayer backend!

if i check the resolution of 712 x 368 in the ars calculator for 2.35:1 it shows 249:205! so can i use this one or 32:27?

[AnonCrow]

and any x264 devs can answer me? Not a dev but will answer anyway.

what decides the speed factor of x264 encoding? The CPU? or RAM?
If it's cpu? can a faster dual core outperform quadcore?
Amount of RAM can be a limiting factor (but won't directly affect speed) with higher values of certain settings (rc-lookahead). Amount of L1/L2/L3 cache is much more important.

Encoding speed itself increases nearly linearly as number of cores increase,
so an otherwise identical dual-core CPU would have to have a ~100% higher clockspeed.

If you use b-adapt=2 along with a very high number of b-frames,
the difference would be less as frame-type decision is (still AFAIK) single-threaded;
so the quad-core would not necessarily run at 100% CPU usage.
OTOH, you could just run multiple encoding jobs on the quad-core machine at the same time.

But often the speed is limited by other things, namely the decoding speed of the source - especially with faster presets,
and any major pre-processing done on the source - especially if they are single-threaded.


Disk I/O would rarely come into play, unless you were encoding to/from a USB 2.0 connected HD/UFD
and/or you had a single internal SATA HD and quad-socket machine filled with 8-core Xeons running multiple encoding jobs.

[diimaan]

Not a dev but will answer anyway.


Amount of RAM can be a limiting factor (but won't directly affect speed) with higher values of certain settings (rc-lookahead). Amount of L1/L2/L3 cache is much more important.

Encoding speed itself increases nearly linearly as number of cores increase,
so an otherwise identical dual-core CPU would have to have a ~100% higher clockspeed.

If you use b-adapt=2 along with a very high number of b-frames,
the difference would be less as frame-type decision is (still AFAIK) single-threaded;
so the quad-core would not necessarily run at 100% CPU usage.
OTOH, you could just run multiple encoding jobs on the quad-core machine at the same time.

But often the speed is limited by other things, namely the decoding speed of the source - especially with faster presets,
and any major pre-processing done on the source - especially if they are single-threaded.


Disk I/O would rarely come into play, unless you were encoding to/from a USB 2.0 connected HD/UFD
and/or you had a single internal SATA HD and quad-socket machine filled with 8-core Xeons running multiple encoding jobs.


:thanks: AnonCrow!
so cache memory and the cpu plays more important role than other factors right?

[AnonCrow]

The size of memory and cache (unless very low cache like old Celerons or Semprons) don't matter much, but their speed does , sometimes even more than the speed of the CPU itself.

[diimaan]

The size of memory and cache (unless very low cache like old Celerons or Semprons) don't matter much, but their speed does , sometimes even more than the speed of the CPU itself.

wow that's really news to me! :)
hope my i3 is better than the core2's!

[diimaan]

i just made a comparison encode of the sample file i uploaded before!

my avs:

Loadplugin("D:\dgmpgdec158\DGDecode.dll")
Loadplugin("C:\Program Files (x86)\AviSynth 2.5\plugins\AutoCrop.dll")

mpeg2source("C:\Users\diimaan\Desktop\m1.d2v")
AutoCrop(mode=0, threshold=50)


xvid single pass quant(2.75)

xvid_encraw.exe -i "C:\Users\diimaan\Desktop\m1.avs" -type 2 -o "C:\Users\diimaan\Desktop\m1_xvid_quant.mkv" -par 1 -progress 10 -cq 2.75 -max_bframes 2 -bquant_ratio 150 -bquant_offset 100 -bvhq -qtype 0 -qpel -gmc -lumimasking -quality 6 -vhqmode 2 -imin 2 -imax 31 -bmin 2 -bmax 31 -pmin 2 -pmax 31

1035 frames 44.15 fps! 1344 kbps!

xvid 2 pass bitrate(925 kbps)

xvid_encraw.exe -i "C:\Users\diimaan\Desktop\m1.avs" -type 2 -pass1 "C:\Users\diimaan\Desktop\xvid.stats" -bitrate 925 -full1pass -progress 10 -max_bframes 2 -bquant_ratio 150 -bquant_offset 100 -max_key_interval 240 -bvhq -qtype 0 -qpel -gmc -lumimasking -quality 6 -vhqmode 2 -imin 2 -imax 31 -bmin 2 -bmax 31 -pmin 2 -pmax 31
xvid_encraw.exe -i "C:\Users\diimaan\Desktop\m1.avs" -type 2 -pass2 "C:\Users\diimaan\Desktop\xvid.stats" -o "C:\Users\diimaan\Desktop\m1_xvid_2pass.mkv" -bitrate 925 -par 1 -progress 10 -max_bframes 2 -bquant_ratio 150 -bquant_offset 100 -max_key_interval 240 -bvhq -qtype 0 -qpel -gmc -lumimasking -quality 6 -vhqmode 2 -imin 2 -imax 31 -bmin 2 -bmax 31 -pmin 2 -pmax 31

1035 frames 42.76 fps! 1769 kbps! 1pass
1035 frames 49.68 fps! 877 kbps! 2pass

x264 crf(19.5)

x264.exe "C:\Users\diimaan\Desktop\m1.avs" --preset slow --threads auto --thread-input --level 30 --sar 32:27 --crf 19.5 --vbv-maxrate 10000 --vbv-bufsize 10000 --partitions all --trellis 2 --no-fast-pskip --output "C:\Users\diimaan\Desktop\m1_x264_crf.mkv"

1035 frames 19.96 fps! 1187.43 kbps!

x264 2 pass bitrate(925 kbps)

x264.exe "C:\Users\diimaan\Desktop\m1.avs" --threads auto --thread-input --level 30 --ref 12 --sar 1:1 --vbv-maxrate 10000 --vbv-bufsize 10000 --me tesa --subme 10 --merange 24 --partitions all --8x8dct --bframes 16 --trellis 2 --no-fast-pskip --pass 1 --bitrate 925 --stats "encode.stats" --output NUL
x264.exe "C:\Users\diimaan\Desktop\m1.avs" --threads auto --thread-input --level 30 --ref 12 --sar 1:1 --vbv-maxrate 10000 --vbv-bufsize 10000 --me tesa --subme 10 --merange 24 --partitions all --8x8dct --bframes 16 --trellis 2 --no-fast-pskip --pass 2 --bitrate 925 --stats "encode.stats" --output "C:\Users\diimaan\Desktop\m1_x264_2pass.mkv"

1035 frames 158.52 fps! 868.68 kbps! 1pass
1035 frames 5.97 fps! 906.34 kbps! 2pass

Here (http://www.mediafire.com/?y3mdzdynatn) are the samples!

one thing really surprised me!
the second pass of the xvid was quicker than the first pass!

i'll leave which is best encode to you ppl! :)

and the video container is mkv! muxed using mmg!
audio used is q 2.45 ogg!

[AnonCrow]

x264.exe "C:\Users\diimaan\Desktop\m1.avs" --threads auto --thread-input --level 30 --ref 12 --sar 1:1 --vbv-maxrate 10000 --vbv-bufsize 10000 --me tesa --subme 10 --merange 24 --partitions all --8x8dct --bframes 16 --trellis 2 --no-fast-pskip --pass 1 --bitrate 925 --stats "encode.stats" --output NUL
x264.exe "C:\Users\diimaan\Desktop\m1.avs" --threads auto --thread-input --level 30 --ref 12 --sar 1:1 --vbv-maxrate 10000 --vbv-bufsize 10000 --me tesa --subme 10 --merange 24 --partitions all --8x8dct --bframes 16 --trellis 2 --no-fast-pskip --pass 2 --bitrate 925 --stats "encode.stats" --output "C:\Users\diimaan\Desktop\m1_x264_2pass.mkv"


This has already been said to you several times, but your settings (still) make no sense.
Most of the settings in the first pass are ignored anyway because you didn't set slow-firstpass.

I urge you to at the very least remove me tesa, possibly also one or more of ref 12 , subme 10 ,trellis 2 and bframes 16,
and do some more test encodes with the same target bitrate and try to see any differences.
Or as said before , remove all the settings I just mentioned and just use slow, slower or veryslow preset.

Of course ,if you truly can see a difference between veryslow and placebo presets and you don't mind spending half a day to encode a movie, then by all means use placebo.

Then, if you still decide you want to mess around with individual settings, first study x264 --fullhelp and http://mewiki.project357.com/wiki/X264_Settings

[diimaan]

This has already been said to you several times, but your settings (still) make no sense.
Most of the settings in the first pass are ignored anyway because you didn't set slow-firstpass.

I urge you to at the very least remove me tesa, possibly also one or more of ref 12 , subme 10 ,trellis 2 and bframes 16,
and do some more test encodes with the same target bitrate and try to see any differences.
Or as said before , remove all the settings I just mentioned and just use slow, slower or veryslow preset.

Of course ,if you truly can see a difference between veryslow and placebo presets and you don't mind spending half a day to encode a movie, then by all means use placebo.

Then, if you still decide you want to mess around with individual settings, first study x264 --fullhelp and http://mewiki.project357.com/wiki/X264_Settings

yes yes! i know! i was just using the 2nd pass encode for comparison purpose only! correct me if there's any wrong in the crf encode! :)
these files are around 5-7 mb after the encoding! so i didn't mind about the placebo's if any! it's a very short video clip! ;)

[diimaan]

my mistake! I posted the wrong code for crf! now updated with new links!!! :) :D

sorry for the trouble AnonCrow!

[nm]

--no-fast-pskip is not necessary. It's slow and not very useful so it's only enabled automatically in --preset placebo.

[diimaan]

--no-fast-pskip is not necessary. It's slow and not very useful so it's only enabled automatically in --preset placebo.

:thanks: and done! will post a new comparison shortly with suggested codes! :)

[LoRd_MuldeR]

and how you find the PAR of 1:1 gives 854x480! :)

You content is 720x480, the standard NTSC resolution. But obviously 720/480 is neither 4/3 nor 16/9 ;)

So displaying the video at its "native" resolution would look "stretched". Also it isn't hard to see the proper DAR for this movie should be 16/9, not 4/3.

(480 / 9) * 16 = 854 ⟹ 854/480 = 16/9


You can also throw your file on MPlayer and look at log:

MPlayer Sherpya-SVN-r31170-4.2.5 (C) 2000-2010 MPlayer Team
Setting process priority: realtime
154 audio & 337 video codecs

Playing C:\Temp\!_DOWN~1\VTS_01~1.VOB.
fopen Vobsub file failed: No such file or directory
ID_VIDEO_ID=0
ID_AUDIO_ID=128
MPEG-PS file format detected.
VIDEO: MPEG2 720x480 (aspect 3) 29.970 fps 8500.0 kbps (1062.5 kbyte/s)
ID_FILENAME=C:\Temp\!_DOWN~1\VTS_01~1.VOB

[...]

Starting playback...
Movie-Aspect is 1.78:1 - prescaling to correct movie aspect.
ID_VIDEO_ASPECT=1.7778
VO: [gl] 720x480 => 854x480 Planar YV12


The "technical" way to calculate the proper DAR would applying the standard PAR for "16:9 NTSC" content, which is defined as 32:27. So you'll get:

720/480 * 32/27 = 16/9

[diimaan]

You content is 720x480, the standard NTSC resolution. But obviously 720/480 is neither 4/3 nor 16/9 ;)

So displaying the video at its "native" resolution would look "stretched". Also it isn't hard to see the proper DAR for this movie should be 16/9, not 4/3.

(480 / 9) * 16 = 854 ⟹ 854/480 = 16/9


You can also throw your file on MPlayer and look at log:

MPlayer Sherpya-SVN-r31170-4.2.5 (C) 2000-2010 MPlayer Team
Setting process priority: realtime
154 audio & 337 video codecs

Playing C:\Temp\!_DOWN~1\VTS_01~1.VOB.
fopen Vobsub file failed: No such file or directory
ID_VIDEO_ID=0
ID_AUDIO_ID=128
MPEG-PS file format detected.
VIDEO: MPEG2 720x480 (aspect 3) 29.970 fps 8500.0 kbps (1062.5 kbyte/s)
ID_FILENAME=C:\Temp\!_DOWN~1\VTS_01~1.VOB

[...]

Starting playback...
Movie-Aspect is 1.78:1 - prescaling to correct movie aspect.
ID_VIDEO_ASPECT=1.7778
VO: [gl] 720x480 => 854x480 Planar YV12


The "technical" way to calculate the proper DAR would applying the standard PAR for "16:9 NTSC" content, which is defined as 32:27. So you'll get:

720/480 * 32/27 = 16/9

it all looks very simple as long as you get what it is! :)
so if i resize to 854/480 (848/360)
what would be the sar/par i should pass on via encoder? 1:1 right?

[Blue_MiSfit]

Correct, because resizing to 854x480 effectively changes the par/sar to 1:1 :)

So, you don't actually need to set any sar at all in x264

[diimaan]

Correct, because resizing to 854x480 effectively changes the par/sar to 1:1 :)

So, you don't actually need to set any sar at all in x264

the x264 encoder takes the source AR if there is no SAR specified! hmmm!

[diimaan]

i'll post a mini comparison with the output resized to 854/480! :)

[diimaan]

here's a new comparison!
only betn x264 crf and 2pass encodes(i omitted xvid's as the output was not satisfactory) :)

please have a look and let me know... thanks!

http://www.mediafire.com/?ymzyum22kde

my avs:

Loadplugin("D:\dgmpgdec158\DGDecode.dll")
Loadplugin("C:\Program Files (x86)\AviSynth 2.5\plugins\AutoCrop.dll")

mpeg2source("C:\Users\diimaan\Desktop\m1.d2v")
AutoCrop(mode=0, threshold=50)


x264 crf(19.5)

x264.exe "C:\Users\diimaan\Desktop\m1.avs" --preset slower --threads auto --thread-input --level 30 --crf 19.5 --vbv-maxrate 10000 --vbv-bufsize 10000 --output "C:\Users\diimaan\Desktop\m1_crf.mkv"

1035 frames 14.67 fps! 1239.37 kbps!

x264 2 pass bitrate(1200 kbps)

x264.exe "C:\Users\diimaan\Desktop\m1.avs" --preset slower --threads auto --thread-input --level 30 --vbv-maxrate 10000 --vbv-bufsize 10000 --pass 1 --slow-firstpass --bitrate 1200 --stats "encode.stats" --output NUL
x264.exe "C:\Users\diimaan\Desktop\m1.avs" --preset slower --threads auto --thread-input --level 30 --vbv-maxrate 10000 --vbv-bufsize 10000 --pass 2 --bitrate 1200 --stats "encode.stats" --output "C:\Users\diimaan\Desktop\m1_2pass.mkv"

1035 frames 15.85 fps! 1134.04 kbps! 1pass
1035 frames 16.37 fps! 1177.91 kbps! 2pass

also using crf at 19.5 is ok? or can i reduce a bit lower or increase it?

[diimaan]

is there a way to mux
h264 avc video and ogg vorbis audio in a mp4 container?

I've been doing this in a mkv container! but i want an mp4 output! is this possible?

yamb produces a video file with no audio?

[Blue_MiSfit]

No, vorbis cannot be stored in MP4. Use AAC or AC3, or stick to MKV :)

[diimaan]

No, vorbis cannot be stored in MP4. Use AAC or AC3, or stick to MKV :)

nope! it worked... i just tried with the yamb beta 2! it works!
with yamb 1.6 sync is not proper!
we need to feed the video as .h264! it works... :)

[Blue_MiSfit]

Wow. That's news to me :p

[diimaan]

Wow. That's news to me :p

yeah! ;)

but am not sure about the compatibility! it works in my pc without a problem... :)

http://en.wikipedia.org/wiki/Comparison_of_container_formats

it says vorbis can be stored but with some restrictions... :)

[diimaan]

@LoRd_MuldeR

I was reading through your thread on Simple x264 Launcher!
It goes way over my head! LoL
I'll read again to understand it much better... :)

but do you think is there any apparent performance gain by using the x264_64.exe than the x264.exe?

I am running vista 64 on a core i3!
with x264 mod generic from komisar!

[diimaan]

vorbis in mp4 does have disrepancies!
i checked a few sample encodes.

if you encode a h264 without mentioning a level and mux it with a vorbis!

you can see blocky artifacts all over your screen on the resulting mp4! :) pretty strange though!
same settings just without the mentioning of profile and vbv causing this problem...

[Didée]

(Warning: only "vague knowledge" below)

AFAIK, the "officially" supported audio formats for mp4 are the mpeg layer formats, and AAC. Anything else is supported only as "private" streams within mp4 - sort of a "black box". Means you can theoretically mux about just anything, but need a dedicated splitter/decoder that is able to handle that private stream correctly.

Now actually, you can't even be sure if you're experiencing a splitter/decoder issue, or if yamb's way of muxing is incorrect. (By chance, it could be both.) ;)

In short: better stay away from Vorbis-in-mp4. Compare to Vorbis-in-AVI: You can mux it (with AviDemuxGUI, iirc), but you can not play it. (Different technical reason, but same end result.)

[diimaan]

(Warning: only "vague knowledge" below)

AFAIK, the "officially" supported audio formats for mp4 are the mpeg layer formats, and AAC. Anything else is supported only as "private" streams within mp4 - sort of a "black box". Means you can theoretically mux about just anything, but need a dedicated splitter/decoder that is able to handle that private stream correctly.

Now actually, you can't even be sure if you're experiencing a splitter/decoder issue, or if yamb's way of muxing is incorrect. (By chance, it could be both.) ;)

In short: better stay away from Vorbis-in-mp4. Compare to Vorbis-in-AVI: You can mux it (with AviDemuxGUI, iirc), but you can not play it. (Different technical reason, but same end result.)

:thanks:
Didée

yeah it's a pity vorbis is not at all stable in mp4! :(
i liked the sound of vorbis(esp with DSPGuru's boost) better than aac(HE or LC)

mkv FTW then...

[foxyshadis]

mp4 doesn't get you anything over mkv anyway in this case: No hardware player supporting mp4 will play it, or if you're really lucky they'd play it with no sound.

That 640x272 is going to look pretty bad when it's scaled up to fullscreen. Before I went down that far I'd activate x264's --nr 500 or add some smoothing filters in the script, like MipSmooth or MDeGrain1 (or 2). Lees detail -> less downsizing needed, but it's a tricky balance. On some movies you can also drop half of the frames, but on sports it'd be a bad idea. You might also consider encoding audio at 24khz to give the video some more room (or with HE-AAC), vorbis & nero aac sound very good down to very low q levels. 24khz+crystalizer is pretty much the same as HE-AAC.

[diimaan]

mp4 doesn't get you anything over mkv anyway in this case: No hardware player supporting mp4 will play it, or if you're really lucky they'd play it with no sound.

That 640x272 is going to look pretty bad when it's scaled up to fullscreen. Before I went down that far I'd activate x264's --nr 500 or add some smoothing filters in the script, like MipSmooth or MDeGrain1 (or 2). Lees detail -> less downsizing needed, but it's a tricky balance. On some movies you can also drop half of the frames, but on sports it'd be a bad idea. You might also consider encoding audio at 24khz to give the video some more room (or with HE-AAC), vorbis & nero aac sound very good down to very low q levels. 24khz+crystalizer is pretty much the same as HE-AAC.

yeah i know! 640x272 actually sucks on fullscreen! cos i use a full hd led monitor at 1920x1080 res! so think abt it! ;)

it's for my technologically challenged mom dad's old pc! which is equipped with a 15 inch crt! :)

[diimaan]

thanks all for helping me out so these are my final settings!

my avs

Loadplugin("C:\Program Files (x86)\dgmpgdec158\DGDecode.dll")
Loadplugin("C:\Program Files (x86)\AviSynth 2.5\plugins\AutoCrop.dll")

mpeg2source("D:\dvd2avi.d2v")

//telecide or decimate if needed for 1080i or 1080p tv shows

AutoCrop(mode=0, threshold=50)
Spline64Resize(some WUXGA resolution matches my 1920x1080 screen)

//mipsmooth if needed


x264:

@echo off
"D:\CLI\x264.exe" "D:\m1.avs" --preset slower --threads auto --thread-input --sar 1:1 --crf 19 --output "D:\m1.mkv"
pause


besweet:

@echo off
"C:\Program Files (x86)\BeSweetv1.5b31\BeSweet.exe" -core( -input "C:\Users\scud\Desktop\mobil.wav" -output "C:\Users\scud\Desktop\mobil.ogg" -logfile "C:\Users\scud\Desktop\mobil.log" ) -ota( -g max ) -ogg( -q 0.445 ) -boost( /b2=4 /l=0.95 )
pause


I just tried out the pclos 2010.1 kde edition! which was really snappy! so am planning to shunt my windows for that!

so can anyone suggest me how i can transform the above codes for mencoder?
yeah I read abt the ogmrip and k9copy tutorials

but it will be helpful if someone give some lines for my above settings, both audio and video, including the muxing!
i was really lost with the piping and all... :(

yeah forget abt the installation part of mencoder and et al!

[nm]

so can anyone suggest me how i can transform the above codes for mencoder?
yeah I read abt the ogmrip and k9copy tutorials

but it will be helpful if someone give some lines for my above settings, both audio and video, including the muxing!
i was really lost with the piping and all... :(

How about HandBrake (http://handbrake.fr/)? It has both a nice GUI and a command-line interface, both easier than MEncoder when encoding with x264.

[diimaan]

How about HandBrake (http://handbrake.fr/)? It has both a nice GUI and a command-line interface, both easier than MEncoder when encoding with x264.

does HandBrake works on linux? apart from mac and PC?

[nm]

does HandBrake works on linux? apart from mac and PC?

Yes, perfectly. PCLinuxOS even seems to have 0.9.4 in their package repository.

[diimaan]

Yes, perfectly. PCLinuxOS even seems to have 0.9.4 in their package repository.

reallly! that's gr8! i'll post my comments once got it installed and tested with pclos!

[diimaan]

sorry was busy testing some encodes for my mobile so not able to test the pclos!

can we use the comptest xls to find the crf average? or is it different for x264?

and also while testing various containers with x264,
mkv, mp4 and avi!
avi is quick to load! but i heard it's having some compatibility issues with x264!

what is vfr?
how to find a video is vfr or cfr?

[diimaan]

currently i'm testing encodes with this setting!


@echo off
"D:\CLI\x264.exe" "D:\m1.avs" --preset fast --threads auto --thread-input --sar 1:1 --crf 21 --me umh --output "D:\m1.mkv"
pause

the only thing i'm forcing over the preset is, setting umh over hex!

also i'm not able to see any considerable difference in quality compared to the time spent with the one below

@echo off
"D:\CLI\x264.exe" "D:\m1.avs" --preset slower --threads auto --thread-input --sar 1:1 --crf 21 --output "D:\m1.mkv"
pause


can i continue encoding with fast preset than slower? you guys think the quality difference would be substantial?

thanks... :)

[Lam3rD]

It's entirely your choice. If the speed gain surpasses the quality drop you notice, then go with it. The presets are there, so everyone can chose the fastest/slowest, that he can live with.

p.s: --threads auto --thread-input --sar 1:1 aren't really needed

[nm]

also i'm not able to see any considerable difference in quality compared to the time spent with the one below

@echo off
"D:\CLI\x264.exe" "D:\m1.avs" --preset slower --threads auto --thread-input --sar 1:1 --crf 21 --output "D:\m1.mkv"
pause


can i continue encoding with fast preset than slower? you guys think the quality difference would be substantial?

If bitrate doesn't matter, you can use faster presets. If bitrate does matter, don't use CRF to compare the settings! Make 2-pass encodes to get equal bitrates and then compare quality. (Or first make a CRF encode with one set of settings and then a 2-pass encode that targets the average bitrate from the first encode with other settings.) After you have determined whether a slower preset is worth the speed loss, return to CRF and find the maximum value that gives you good enough quality.

[diimaan]

hi all!

i'm again with a confusion, whether this source is a interlace or progressive! but what i'm more concerned with is some noise or grain kind of thing present through out the movie! you can see it's quite an old dvd! it's from 1993... :D

sample of my source (http://www.mediafire.com/?qj5m3mqllqn)

please have a look and let me know... thanks... :)

and this is what i got when i used the info()

http://i50.tinypic.com/w6sile.jpg





ColorMatrix()
a = last.RemoveGrain(mode=17)
b = a.degrainmedian(mode=2).VagueDenoiser(threshold=2, method=3, nsteps=6, chromaT=2.0)
SeeSaw(a,b)


I tried this to remove the noise but the output was not quite good as i expected! i heard using this in place of degran and vaguedenoiser


FFT3DFilter(sigma=3.0, plane=4, bw=48, bh=48, bt=3, ow=16, oh=16, sharpen=0, interlaced=false)

will do much better job

but i can't afford to work at 0.5 fps! :(

any suggestions for improving the quality of output?
at moderate speed!

[Blue_MiSfit]

I'm taking a look.. we'll see!

Derek

[diimaan]

Thanks Derek! :)

me waiting... :p

[Blue_MiSfit]

So, your source is vanilla 3:2 hard telecine, and can be fixed with a simple telecide / decimate.

Here's how I figured that out

1) Open in DGIndex, set to "honor pulldown". Push F5, see no field repeats, so save project as-is (NO FORCE FILM)
2) Open D2V in AvsP, step through frame by frame, see clean 3:2 pattern
3) Add Telecide.Decimate, get clean 24p out. DONE :)

You don't need ColorMatrix, since your colorimetry is already standard BT.470 (aka BT.601 aka standard SD colors).

As far as the denoising goes, that's the subjective bit! Adding DeGrainMedian(interlaced=true) prior to the Telecide.Decimate seems to help some, but that's definitely tricky noise.

If you like the look of fft3dfilter and have a reasonably powerful video card, you can try FFT3DGPU. If you have something half-decent, it will basically be free :)

Derek

[diimaan]

So, your source is vanilla 3:2 hard telecine, and can be fixed with a simple telecide / decimate.

Here's how I figured that out

1) Open in DGIndex, set to "honor pulldown". Push F5, see no field repeats, so save project as-is (NO FORCE FILM)
2) Open D2V in AvsP, step through frame by frame, see clean 3:2 pattern
3) Add Telecide.Decimate, get clean 24p out. DONE :)

You don't need ColorMatrix, since your colorimetry is already standard BT.470 (aka BT.601 aka standard SD colors).

As far as the denoising goes, that's the subjective bit! Adding DeGrainMedian(interlaced=true) prior to the Telecide.Decimate seems to help some, but that's definitely tricky noise.

If you like the look of fft3dfilter and have a reasonably powerful video card, you can try FFT3DGPU. If you have something half-decent, it will basically be free :)

Derek

I don't use AvsP!
I manually edit... :D anyways

so my script should look like this right?

Loadplugin("C:\Program Files (x86)\AviSynth 2.5\plugins\UnDot.dll")
Loadplugin("C:\Program Files (x86)\AviSynth 2.5\plugins\Decomb.dll")
Loadplugin("C:\Program Files (x86)\AviSynth 2.5\plugins\AutoCrop.dll")
Loadplugin("C:\Program Files (x86)\AviSynth 2.5\plugins\TomsMoComp.dll")
Loadplugin("C:\Program Files (x86)\AviSynth 2.5\plugins\ColorMatrix.dll")
Loadplugin("C:\Program Files (x86)\AviSynth 2.5\plugins\degrainmedian.dll")
Loadplugin("C:\Program Files (x86)\AviSynth 2.5\plugins\VagueDenoiser.dll")
Loadplugin("C:\Program Files (x86)\AviSynth 2.5\plugins\RemoveGrainSSE3.dll")

mpeg2source("D:\dvd2avi.d2v")
#Info()

AutoCrop(mode=0, threshold=50)

Telecide(post=false,guide=2,blend=false)
Decimate(cycle=5)

UnDot()
a = last.RemoveGrain(mode=17)
b = a.degrainmedian(mode=2).VagueDenoiser(threshold=2, method=3, nsteps=6, chromaT=2.0)
SeeSaw(a,b)



also do you think using this will do any good instead of Telecide/Decimate?


TomsMoComp(1,5,1)

or

Top=AssumeFrameBased().ComplementParity()
Bottom=Top.SeparateFields.Trim(1,0).weave
Interleave(Top.TomsMoComp(1,5,1),Bottom.TomsMoComp(0,5,1))


my GPU is ATI 5750 with 1GB GDDR5 RAM

[Blue_MiSfit]

TomsMoComp is a deinterlacer. It's NOT the same thing as inverse telecine (Telecide/Decimate). Don't confuse the two!

Deinterlacing is for taking truly interlaced video and making it progressive. Inverse telecine is for recovering progressive frames from a partially interlaced stream generated via pulldown.

Movies are almost always telecined. TV shows (especially sports, sitcoms, etc) are frequently interlaced.

Don't overthink your telecide / decimate calls also. Defaults worked just fine for me.

My script:


MPEG2Source(...)

telecide
decimate

fft3dgpu(plane=4, sigma=.5)

That sigma value is totally off the head. It surely needs tweaking!

Derek

[diimaan]

TomsMoComp is a deinterlacer. It's NOT the same thing as inverse telecine (Telecide/Decimate). Don't confuse the two!

Deinterlacing is for taking truly interlaced video and making it progressive. Inverse telecine is for recovering progressive frames from a partially interlaced stream generated via pulldown.

Movies are almost always telecined. TV shows (especially sports, sitcoms, etc) are frequently interlaced.

Don't overthink your telecide / decimate calls also. Defaults worked just fine for me.

My script:


MPEG2Source(...)

telecide
decimate

fft3dgpu(plane=4, sigma=.5)

That sigma value is totally off the head. It surely needs tweaking!

Derek

ohh, thanks Derek...

will give it a go with these scripts... :)

[diimaan]

while going through the forums i end up reading this

http://forum.doom9.org/showthread.php?t=108527

i couldn't properly get neuron2's explanation! :confused:
can anyone explain with some screenshots?

[diimaan]

Hey Derek,

I'm settling with this code... and I'm happy with the output and at a speed of around 27-30fps, for a slower preset in x264 is a good thing i believe...

what do you say>?


Loadplugin("C:\Program Files (x86)\dgmpgdec158\DGDecode.dll")
Import("C:\Program Files (x86)\AviSynth 2.5\plugins\SeeSaw.avs")
Loadplugin("C:\Program Files (x86)\AviSynth 2.5\plugins\UnDot.dll")
Loadplugin("C:\Program Files (x86)\AviSynth 2.5\plugins\Decomb.dll")
Loadplugin("C:\Program Files (x86)\AviSynth 2.5\plugins\AutoCrop.dll")
Loadplugin("C:\Program Files (x86)\AviSynth 2.5\plugins\FFT3dGPU.dll")
Loadplugin("C:\Program Files (x86)\AviSynth 2.5\plugins\RemoveGrainSSE3.dll")

mpeg2source("D:\dvd2avi.d2v")
#Info()

AssumeTFF()
Telecide()
Decimate()

AutoCrop(mode=0, threshold=50)

UnDot()

a = last.RemoveGrain(mode=17)
b = a.FFT3dGPU(sigma=2.0, plane=4, bw=48, bh=48, bt=4)
SeeSaw(a,b)


:rolleyes:

[Blue_MiSfit]

Cool, I'd maybe drop the removegrain and seesaw bits, and then adjust your fft3dpgu settings a bit (probably reduce sigma, maybe spread it out to sigma, sigma2, sigma3, sigma4).

But, it's all up to you :)

Derek