Suggestions for improving the quality!

[diimaan]

Hi All,
I am a long time reader of the forums.

I used to convert all my dvd-9 ntsc dvd's to 2 cd or 1 cd rips depending upon the duration of the movies.

I was using xvid 1 pass quant mode.

After reading about the avc, I started to encode using two pass mode in x264.
And the quality is obvioussly better atleast to my bare eyes :)

so please suggest/assist me whether I am doing everything all right or not. I just want to hear from the experts that am not doing anything wrong. Thanks

my avisynth:

Loadplugin("D:\dgmpgdec158\DGDecode.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\SmoothDeinterlacer.dll")

mpeg2source("D:\My_Rips\KANK\dvd2avi.d2v")

Telecide(post=false,guide=2,blend=false)
Decimate(cycle=5)
SmoothDeinterlace(tff=true,doublerate=false,lacethresh=5,edgethresh=20,staticthresh=0)

AutoCrop(mode=0, threshold=50)
Spline36Resize(640,272)


my x264:

x264.exe "D:\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 "D:\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 "D:\m1.mkv"


I used ref 12 because 2073600/640*272 = 11.9!
correct me if i'm wrong.

My system!
Windows Vista 64 bit Ultimate
Core i3 530 2.93 G
4 GB DDR 3 RAM
ATI Radeon 5770

:confused:

[Inspector.Gadget]

1) As far as an Avisynth script goes, nobody can make one for every source: they're source-dependent. That said, why on earth are you IVTCing AND deinterlacing? Second, why would you resize all DVDs regardless of 4:3 or 16:9 coding (to say nothing of actual movie image dimensions!) to the same dimensions?

2) --thread-input is deprecated, your settings are probably overkill, and I'm sure the x264 devs and very experienced users will have more to point out.

[diimaan]

oops i missed the log from DGIndex!


Stream Type: MPEG2 Program
Profile: main@main
Frame Size: 720x480
Display Size: [not specified]
Aspect Ratio: 16:9 [3]
Frame Rate: 29.970030 fps
Video Type: Film 99.43%
Frame Type: Interlaced
Coding Type: B
Colorimetry: BT.470-2 B,G*
Frame Structure: Frame
Field Order: Top
Coded Number: 277575
Playback Number: 2
Frame Repeats: 0
Field Repeats: 0
VOB ID: 1
Cell ID: 26
Bitrate:
Bitrate (Avg):
Bitrate (Max):
Audio Stream: 80: AC3 3/2 448
Timestamp: 3:12:43
Elapsed: 0:02:02
Remain: FINISH
FPS:
Info:


I did not do a forced film from DGIndex so I did IVTC and deinterlace!

and AutoCrop suggested results are equal to this Crop(2,56,-8,-56)!
after cropping the suggested resolution was 710x368!

And in my dvd it was mentioned 2.35:1! so i thought resizing to 640x272 would be fine.

[LoRd_MuldeR]

diimaan, you could replace most of your x264 options with a simple "--preset veryslow". This will also exclude the placebos you are using currently...

[LoRd_MuldeR]

I did not do a forced film from DGIndex so I did IVTC and deinterlace!

This makes no sense at all :confused:

If you were forcing film on a "soft telecined" source, then you'd neither need Deinterlace nor IVTC.

If your source is "hard telecined" you need only IVTC, but not a Deinterlacer. And if your source is "true" interlaced, you need a Deinterlacer (IVTC won't work in that case).

Well, maybe in rare cases you may need something like TDeint(full=false) as a post-processor for IVTC, which will only deinterlace the frames that are still combed.

But blindly deinterlacing all frames that have been IVTC'd already is nonsense...

[diimaan]

diimaan, you could replace most of your x264 options with a simple "--preset veryslow". This will also exclude the placebos you are using currently...

Oh Thanks Lord! :)

[diimaan]

This makes no sense at all :confused:

If were forcing film on a "soft telecined" source, then you'd neither need Deinterlace nor IVTC.

If your source is "hard telecined" you need only IVTC, but not a Deinterlacer. And if your source is "true" interlaced, you need a Deinterlacer (IVTC won't work in that case).

Well, maybe in rare cases you may need something like TDeint(full=false) asa post-processor for IVTC.

But blindly deinterlacing all frames that have been IVTC'd already is nonsense...

I just posted my DGIndex log!
what is my source?

I can see it as interlaced! But don't know about others! :confused:

[diimaan]

But blindly deinterlacing all frames that have been IVTC'd already is nonsense...

so this would be fine without the deinterlacer! right?


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

[LoRd_MuldeR]

so this would be fine without the deinterlacer! right?


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


I don't know what your source is. You didn't post a sample. So only you can see it at the moment.

The DGIndex log cannot tell use the nature of your content either, because it only tells use how the video was encoded, not what it actually is.

If and only if, your source is "hard telecined", then all you need is an IVTC filter (no Deinterlacer). If and only if your source is "true" interlaced, then you need a Deinterlacer (no IVTC).

Lats but not least: If and only if your source is progressive (or "Force Film" was used on "soft telecined" footage) then you don't need anything like that!

[diimaan]

I don't know what your source is. You didn't post a sample. So only you can see it at the moment.

The DGIndex log cannot tell use the nature of your content either, because it only tells use how the video was encoded, not what it actually is.

If and only if, your source is "hard telecined", then all you need is an IVTC filter (no Deinterlacer). If and only if your source is "true" interlaced, then you need Deinterlacer (no IVTC).

Lats but not least: If and only if your source is progressive (or "Force Film" was used on "soft telecined" footage) then you don't need anything like that!

can I post a screenshot of my source?

[LoRd_MuldeR]

can I post a screenshot of my source?

You can, but it won't be helpful. Better post a short unprocessed segment from the original VOB file.

[diimaan]

hmm! actually how you clip vob's? i mean which tool you use? or can i use virtual dub with uncompressed and save as avi?

[LoRd_MuldeR]

hmm! actually how you clip vob's? i mean which tool you use? or can i use virtual dub with uncompressed and save as avi?

Please post a segement from the original VOB file, don't process or re-encode it. You can use DGSplit (http://neuron2.net/dgsplit/dgsplit11.zip) for that purpose, for example.

BTW: A good site for uploading the file would be http://www.mediafire.com/ ;)

[BigDid]

Hi All,
...
I used to convert all my dvd-9 ntsc dvd's to 2 cd or 1 cd rips depending upon the duration of the movies!
I was using xvid 1 pass quant mode!
After reading about the avc, I started to encode using two pass mode in x264!

HI,

There is also a 1 pass quality (CRF) that gives very good results with x264; try crf=22 (higher quality and output size) to 26 (lower output size) with a a recent x264 rev and you will be also pleased by the results with less encoding time and equivalent output size !


my avisynth:
[/code]
...
Spline36Resize(640,272)
[/code]

You could get 1 to 2 cd size without resizing (even getting anamorphic encode)!


my x264:

x264.exe "D:\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
...

I used ref 12 because 2073600/640*272 = 11.9!
correct me if i'm wrong.

:confused:
See bold items:
- 12 ref frames AND 16 B frames seems overkill..
- crf 22 to 26 (1 pass) instead of bitrate 925 (2 pass)

Not being an expert in x264 settings, I use a tuned avisynth script as input to Ripbot 264.
It is also possible to use and tune the avisynth script from Ripbot but it is more complicated...
Ripbot will take care of usual settings as a start; you can further change settings if wanted.

I will let experts comment on the x264 settings if needed.

Did

[diimaan]

HI,

There is also a 1 pass quality (CRF) that gives very good results with x264; try crf=22 (higher quality and output size) to 26 (lower output size) with a a recent x264 rev and you will be also pleased by the results with less encoding time and equivalent output size !


You could get 1 to 2 cd size without resizing (even getting anamorphic encode)!


See bold items:
- 12 ref frames AND 16 B frames seems overkill..
- crf 22 to 26 (1 pass) instead of bitrate 925 (2 pass)

Not being an expert in x264 settings, I use a tuned avisynth script as input to Ripbot 264.
It is also possible to use and tune the avisynth script from Ripbot but it is more complicated...
Ripbot will take care of usual settings as a start; you can further change settings if wanted.

I will let experts comment on the x264 settings if needed.

Did

Hi Thanks did! :)
but when i tried encoding with crf! the settings was like 19.5 to 21! It was varied for different movies. But I heard 2 pass encode is slightly (only slightly) better than single pass crf as crf is not equivalent of 1 pass quant of xvid!

[LoRd_MuldeR]

Hi Thanks did! :)
but when i tried encoding with crf! the settings was like 19.5 to 21! It was varied for different movies. But I heard 2 pass encode is slightly (only slightly) better than single pass crf as crf is not equivalent of 1 pass quant of xvid!

The quality of CRF is equivalent to the quality of 2-Pass -- at the same file size!

The big difference between CRF and 2-Pass is that with 2-Pass you can predict the resulting file size in advance, while with CRF you can't ;)

Still CRF is extremely good if you want to hit a certain level of quality and hinting a specific file size isn't important...

(And yes, CRF is not equivalent to Xvid's CQ mode, as it uses variable quantizers. Xvid doesn't have anything similar to x264's CRF mode)

[diimaan]

The quality of CRF is equivalent to the quality of 2-Pass -- at the same file size!

The big difference between CRF and 2-Pass is that with 2-Pass you can predict the resulting file size in advance, while with CRF you can't ;)

Still CRF is extremely good if you want to hit a certain level of quality and hinting a specific file size isn't important...

Yeah well said LoRd_MuldeR! for me size is kind of more important! :(
otherwise i would go with 18 or 19 crf! :)

[diimaan]

@ LoRd_MuldeR

are you the developer of avidemux?

[LoRd_MuldeR]

@ LoRd_MuldeR

are you the developer of avidemux?

Negative. Most of the work is done by Mean and Gruntster. I wrote the AVS Proxy GUI from the scratch. And I make patched x264 builds for Avidemux now and then...

[diimaan]

Please post a segement from the original VOB file, don't process or re-encode it. You can use DGSplit (http://neuron2.net/dgsplit/dgsplit11.zip) for that purpose, for example.

BTW: A good site for uploading the file would be http://www.mediafire.com/ ;)

Yeah Thanks LoRd_MuldeR!
obviously i've used mediafire ;)

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

sample from my source!

[diimaan]

Negative. Most of the work is done by Mean and Gruntster. I wrote the AVS Proxy GUI from the scratch. And I make patched x264 builds for Avidemux now and then...

Oh! gr8! saw the link in your sig! so thought of asking.
It is one of the best software after vdub! :)

but only thing it lacks is the muxing of ogg(audio-external)! :(!

[LoRd_MuldeR]

diimaan, the sample you have posted contains "progressive" frames. You neither need a Deinterlacer nor IVTC for that!

I have no idea where you see interlacing there :confused:

(Only make sure that "Forced Film" is set when you pipe that through DGIndex)

[diimaan]

diimaan, the sample you have posted is plain "progressive" footage. You neither need a Deinterlacer nor IVTC for that!

I have no idea where you see interlacing there :confused:

you sure? :-o
but when i feed the d2v file to vdub! it showed lines?

or even opening the vob file in vdub shows lines!

[LoRd_MuldeR]

you sure? :-o
but when i feed the d2v file to vdub! it showed lines?

or even opening the vob file in vdub shows lines!

It certainly doesn't here :p

[diimaan]

i just opened the file in vdub! no processing! just drag and drop, and when i used the slider to seek! i see this!


http://i50.tinypic.com/2ufsv3b.png

[LoRd_MuldeR]

That's due to the 2:3 Pulldown (http://en.wikipedia.org/wiki/Telecine#2:3_pulldown) (aka "soft telecine"). Use DGIndex, set "Field Operation" to "Forced Film", save the D2V file and open it via Avisynth.

You'll see nice "progressive" frames at 23.976 fps ;)

[diimaan]

That's due to the 2:3 Pulldown (http://en.wikipedia.org/wiki/Telecine#2:3_pulldown) (aka "soft telecine"). Use DGIndex, set "Field Operation" to "Forced Film", save the D2V file and open it via Avisynth.

You'll see nice "progressive" frames at 23.976 fps ;)

ohh! okay!
btw how you find it's interlaced or progressive source?

[LoRd_MuldeR]

ohh! okay!
btw how you find it's interlaced or progressive source?

Use your eyes! Plus some experience.

Not everything that looks "interlaced" actually is interlaced. Often it's "telecined" and thus the original progressive frames can be restored.

Cinema movies always are progressive at 24 fps, so on NTSC DVD's they are first slowed down to 23.976 fps and then the 2:3 Pulldown to 29.97 is applied.

"True" interlaced (with actual motion in all fields) is mostly found in TV productions/shows and some "live" music DVD's...

[diimaan]

Use your eyes! Plus some experience.

Cinema movies always are progressive at 24 fps, so on NTSC DVD's they are first slowed down to 23.976 fps and then the 2:3 Pulldown to 29.97 is applied.

"True" interlaced (with motion in all fields) is mostly found in TV productions/shows and some "live" music DVD's...

thanks LoRd_MuldeR!
you are of great help... :)

so now my avisynth:

Loadplugin("D:\dgmpgdec158\DGDecode.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\SmoothDeinterlacer.dll")

mpeg2source("D:\My_Rips\KANK\dvd2avi.d2v")

AutoCrop(mode=0, threshold=50)
Spline36Resize(640,272)


is there a need for resize? or can i go with the 710x368 after the crop!

[LoRd_MuldeR]

is there a need for resize? or can i go with the 710x368 after the crop!

There's no need for resize, if you are going to encode it anamorphic, i.e. specify the required PAR when encoding.

If you want a PAR of 1:1 (aka "Square Pixels") you will have to resize it to 854x480 pixels -- not taking the crop into account!

(After the crop I end up with something like 842x364)

[diimaan]

There's no need for resize, if you are going to encode it anamorphic.

If you want a PAR of 1:1 (aka "Square Pixels") you will have to resize it to 854x480 pixels -- not taking the crop into account!

will there be a more loss in quality in enlarging than in reducing the size? if i've to enlarge Spline36 would do the resize fine right?

[LoRd_MuldeR]

will there be a more loss in quality in enlarging than in reducing the size?

Enlarging results in more data, but not more detail. This potentially hurts quality at compression, as more pixels need to be stored at the same file size.

Downsizing directly destroys quality/details, already before compression. But potentially there's less loss in the compression stage, as fewer pixels need to be stored at the same size.

So you probably should simply keep it at the original size and encode it anamorphic. Or you enlarge it to a PAR of 1:1 and give it enough bits to not suffer from compression.

if i've to enlarge Spline36 would do the resize fine right?

SplineXXResize, LanczosXResize, whatever you like best. For 2x or even 4x upscaling I would use NNEDI2/3, but that's not the case here...

[diimaan]

Enlarging results in more data, but not more detail. This potentially hurts quality after compression, as more pixels need to be stored at the same file size.

Downsizing directly destroys quality/details, already before compression.

So you probably should simply keep it at the original size and encode it anamorphic. Or you enlarge it to a PAR of 1:1 and give it enough bits to not suffer from compression.



SplineXXResize, LanczosXResize, whatever you like best. For 2x or even 4x upscaling I would use NNEDI2/3, but that's not the case here...

oh! so If I want to encode with the original size, after cropping it comes to 710x368 which are not divisible by 16

so 704 x 368 which is divisible by 16! can i resize to this resolution and encode?

[diimaan]

Enlarging results in more data, but not more detail. This potentially hurts quality at compression, as more pixels need to be stored at the same file size.

Downsizing directly destroys quality/details, already before compression. But potentially there's less loss in the compression stage, as fewer pixels need to be stored at the same size.

So you probably should simply keep it at the original size and encode it anamorphic. Or you enlarge it to a PAR of 1:1 and give it enough bits to not suffer from compression.



SplineXXResize, LanczosXResize, whatever you like best. For 2x or even 4x upscaling I would use NNEDI2/3, but that's not the case here...

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

[diimaan]

when i load the avs in gknot! the bits/pixel*frame goes below 0.18 if i use the resolution above 704!

can i go ahead and encode with the upscaled resoultion in x264?

[Blue_MiSfit]

I'd suggest not cropping or resizing at all :) Your source doesn't have nasty little artifacts on the borders, so there's no real reason to crop.. Just set 16x9 DAR when you mux the result.

Bits/pixel*frame means absolutely nothing, because it doesn't take into consideration source complexity.

Derek

[diimaan]

thanks for your suggestions Derek!

I'll be waiting for your script! :)

[Blue_MiSfit]

Sorry about that, I didn't read the whole thread by mistake :) I thought nobody had discussed the source content with you, but Lord_Mulder's analysis is 100% correct. You should enable force film for cases like these, and not touch it with a deinterlacer.

[diimaan]

Sorry about that, I didn't read the whole thread by mistake :) I thought nobody had discussed the source content with you, but Lord_Mulder's analysis is 100% correct. You should enable force film for cases like these, and not touch it with a deinterlacer.

yeah Lord_Mulder was of great help! :)
hope i'll try to follow his analysis for my upcoming encodes!

The only part I'm not sure about is the PAR and the resolutions!

[diimaan]

also if i use preset very slow and
used me tesa! will it override the settings of the preset? or it will use the umh which is set in the preset?:confused:

[Blue_MiSfit]

If you use --preset veryslow and also force --me tesa, then it will use tesa.

However, don't use tesa :) It's a huge waste of time!! Honestly, the benefits of going from --preset slow to --preset veryslow aren't always worth the huge jump in encoding time. Of course, I leave that decision up to you!

Also, here's the score on x264 and anamorphic video. Let's be clear on our terminology!

SAR (in x264 terminology) is the "sample aspect ratio", or the shape of the pixels.

For 4x3 content, and a frame aspect ratio of 1.5 (720x480), you should use --sar 8:9. For 16x9 content, use --sar 32:27.

Basically, display AR = sample AR * frame AR. SO:

4/3 = 8/9 * 1.5
16/9 = 32/27 * 1.5

To keep it simple, just remember 32:27 and 8:9 for ntsc :devil:! Oh, and don't crop your input at all, otherwise the AR will be off in the end.

~MiSfit

[diimaan]

If you use --preset veryslow and also force --me tesa, then it will use tesa.

However, don't use tesa :) It's a huge waste of time!! Honestly, the benefits of going from --preset slow to --preset veryslow aren't always worth the huge jump in encoding time. Of course, I leave that decision up to you!

~MiSfit

really? you mean --preset slow or slower?
cos there is no trellis 2 in slow preset! i heard trellis to is a good thing!

[Blue_MiSfit]

Yes it is. But, it's always a very slow thing :)

If you can afford the time to use --preset veryslow, then by all means!! I'm just saying you may not see much benefit in all cases.

Do some test encodes. I'm amazed at how good x264 is even on very fast settings, given reasonable bitrates.

~MiSfit

[diimaan]

Yes it is. But, it's always a very slow thing :)

If you can afford the time to use --preset veryslow, then by all means!! I'm just saying you may not see much benefit in all cases.

Do some test encodes. I'm amazed at how good x264 is even on very fast settings, given reasonable bitrates.

~MiSfit

bitrates! i'm short of bitrates~! ;)
i need 2cd encodes or 1 cd! :)

so the max bitrate i would be using is around 700-900 kbps!

[diimaan]

my source aspect ratio is 2.35:1

so these are the resolutions i computed upon!

848 x 360

800 x 340

720 x 304

640 x 272

so which one would be the ideal resolution?

for my cropped video of 710 x 368? you said don't crop! oops it is 720 x 480 then!!!

[diimaan]

also the red colors doesn't look good! not on 100% size but on a full screen! they look pixelated! all the encodes xvid/divx/x264!

is there any way to avoid this?

i've tried encoding using the placebo preset too! still i'm seeing the pixelation of red colors! or red colored objects
but only if zoomed in i.e full screeen! or it is the shortfall of the encoders?

Thanks!

[Blue_MiSfit]

That's a playback problem. I'd suggest using a recent build of Media Player Classic HC with the "EVR-CP" renderer.

It's definitely NOT x264s fault (or any other encoder for that matter). It's simply a limitation of YV12 that can be worked around with high quality RGB conversion.

Again, just encode at 720x480 and set sar to 32:27, and / or set 16x9 as the aspect ratio when you mux the result. It will display correctly.

Also, why use CDs? They're horribly unreliable, expensive and cramped. At least use DVD+R, or better yet, keep everything on hard drives. Much cheaper that way, and you can use CRF encoding :devil:

~MiSfit

[diimaan]

That's a playback problem. I'd suggest using a recent build of Media Player Classic HC with the "EVR-CP" renderer.

It's definitely NOT x264s fault (or any other encoder for that matter). It's simply a limitation of YV12 that can be worked around with high quality RGB conversion.

Again, just encode at 720x480 and set sar to 32:27, and / or set 16x9 as the aspect ratio when you mux the result. It will display correctly.

Also, why use CDs? They're horribly unreliable, expensive and cramped. At least use DVD+R, or better yet, keep everything on hard drives. Much cheaper that way, and you can use CRF encoding :devil:

~MiSfit

i use either vlc or gomplayer! as mpc has some strange problem of displaying a diagonal green lines on some encodes!

can we change the renderer in these players too?

i use avimux gui! but there's no option to set AR while muxing! :(

[creamyhorror]

To keep it simple, just remember 32:27 and 8:9 for ntsc :devil:! Oh, and don't crop your input at all, otherwise the AR will be off in the end.
What? SAR remains the same whether you crop or not. And you should absolutely crop out the black bars in the encode.


for my cropped video of 710 x 368? you said don't crop! oops it is 720 x 480 then!!!
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).

[MokrySedeS]

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.

[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

[diimaan]

ohh goood!

how you spread across the sigma values?

from lower in sigma to higher in sigma4?

[diimaan]

Hey, it showed some error in the second pass that it couldn't create file and some direct3d error?

could it be a problem cos i was playing football manager 2010! :D

[Blue_MiSfit]

DOH! No playing video games while your PC is encoding!!!! :)

For the sigma values, I usually do a bell curve - kinda sorta...

sigma=.7, sigma2=1.5, sigma3=1.8, sigma4=.5 is a rough approximation of the shape I often go for. You need to spend time tweaking each band, ideally with the help of something like this

a=last
fft3dgpu(...)
interleave(a,last)

histogram(mode="luma")


It helps :devil:

Derek

[diimaan]

ohh, thanks again Derek!
I found the problem, i think it's cos i was using the 64 bit x264 using pipebuf! :)

the 32 bit version works alright...
and yea fm 2010 is not gpu intensive, cos i used to play that and even i've played assassin'screed 2! but that time i did not used fft3dgpu

[diimaan]

hey,

can anyone have a look at the samples??

samples (http://www.mediafire.com/?omohntgjtim)

i donno which is causing trouble in the test 1 file! some blocky tearing or artefacts appear... it happens to be the problem with the x264!

these are my avisynth script and x264


avisynth:
---------

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("C:\Users\Admin\Desktop\test\dvd2avi.d2v")
#Info()

AssumeTFF()
Telecide()
Decimate()

AutoCrop(mode=0, threshold=50)

UnDot()

a = last.RemoveGrain(mode=17)
b = a.FFT3dGPU(sigma=0.5, sigma2=1.5, sigma3=2, sigma4=0.5, plane=4, bw=48, bh=48, bt=4)
SeeSaw(a,b)



x264 for test 1:
---------------

@echo off
"D:\CLI\x264.exe" "C:\Users\Admin\Desktop\test\test.avs" --preset slower --sar 128:135 --crf 23 --output "C:\Users\Admin\Desktop\test\test.mkv"
pause


x264 for test 2:
---------------

@echo off
"D:\CLI\x264.exe" "C:\Users\Admin\Desktop\test\test.avs" --preset fast --me umh --sar 128:135 --crf 23 --output "C:\Users\Admin\Desktop\test\test.mkv"
pause



some setting in the slower profile did not like the file i think?
what do you ppl say?

edited:
also i tested the same source with veryslow and placebo presets! all goes fine! slower seems to be the problem!
strange... i'm using komisar's latest builds... is this a kind of any bug????

[nm]

hey,

can anyone have a look at the samples??

samples (http://www.mediafire.com/?omohntgjtim)

i donno which is causing trouble in the test 1 file! some blocky tearing or artefacts appear... it happens to be the problem with the x264!

I'm having a hard time spotting those artefacts. Which frames should I look at, or could you also post screenshots that exhibit the problem?

also i tested the same source with veryslow and placebo presets! all goes fine! slower seems to be the problem!
strange... i'm using komisar's latest builds... is this a kind of any bug????

Have you tried a second time with the slower preset? Maybe it was just a fluke in one of your filters (likely FFT3dGPU)?

[diimaan]

here are some screens...

http://i46.tinypic.com/2yjsyoi.jpg

http://i45.tinypic.com/fumdjp.jpg

http://i49.tinypic.com/eth3bc.jpg

i did tried without fft3dgpu! but still it's the same...

[diimaan]

screenshots are from test (1).mkv

[nibus]

DOH! No playing video games while your PC is encoding!!!! :)


Really? I play games all the time when I am encoding. Does it interfere with quality? Because I haven't noticed any issues with my encodes.

[nm]

screenshots are from test (1).mkv
I don't see those artifacts here, so it's a decoding problem. It looks like the weightp issue in older CoreAVC versions (http://forum.doom9.org/showthread.php?t=150776). Which decoder are you using?

[diimaan]

MPC video decoder? i think so!

or i should say haali splitter? :??

[diimaan]

I use media player classic home cinema...

and whatever decoder it uses, it should be the one... i'm sure i'm not using core avc... :)

also i've posted the source for this encode a few posts back, so you can test encode too...

here the link again (http://www.mediafire.com/?qj5m3mqllqn)


I can't see LoRd_MuldeR posting these days, hope he hasn't flew too South Africa! :D

No offense LoRd_MuldeR!!! :)

[diimaan]

here i'm yet again with a tricky source! :D

when i forced film and run a test encode it showed interlaced lines...
so i used honour pull down flags and i used telecide and decimate
still i can see a slight interlaced lines in the movie! :confused:

i'm uploading a sample here! what kind of source is this? and what should i do with it to encode!

i donno why i'm always end up with strange sources! :(

here you go friends (http://www.mediafire.com/?xzmck052umt)

[Groucho2004]

here i'm yet again with a tricky source! :D

This looks like some hybrid source.
You might consider reading through the Decomb tutorial that Donald was nice enough to supply and follow the steps to find the best approach for that source. You may actually learn something when you're not being spoon-fed the solutions every time.

[diimaan]

I would not ask for each and every source...
I do my test encodes with various parameters and update my post if i came to a solution!

I've read that tutorial and this one looks kinda like a 5:4 pull down! :o

[diimaan]

I think

TFM()
TDecimate()

should work fine!

hope am doing the right thing... :)

[diimaan]

well TFM() didn't do well on my source!

after testing with

yadif
tomsmocomp
nnedi3
tdeint

I'm settling with this


TDeint(mode=2, order=-1, field=-1, type=2, mtnmode=3, full=false, slow=2)


gives me great result for this particular source!!! :devil:
i wouldn't say it's fast... :p it averages around 8 fps with veryslow preset...

[nm]

I use media player classic home cinema...

and whatever decoder it uses, it should be the one... i'm sure i'm not using core avc... :)

Well, MPC-HC can be set to use internal libavcodec (which should decode your sample fine), some DirectShow decoder or hardware decoding through DXVA. You should try changing the decoder.

Also try VLC or MPlayer to confirm that the stream is ok.

[diimaan]

i'm running a two pass encode at 1500 kbps

but after the first pass, the log displays

x264 [info]: final ratefactor: 22.74

so if i run a crf with 22.74, will my output be of the same size compared to the one with a two pass encode?

[nurbs]

Generally no, because when you encode with crf you'll be using completely different settings than you used in the first pass.

[diimaan]

--preset placebo --tune film --sar 32:27 --pass 1 --bitrate 1500 --stats "encode.stats" --output NUL

this was my 1 pass...

plz don't pounce on me for placebo's :), i'm just trying to push my cpu... and am using nnedi3 on my avs... (i'm getting around 1.4 fps):p

so back to the topic

and if my crf is like this

--preset placebo --tune film --sar 32:27 --crf 22.74 --output "*.mkv"


still my outputs will be of different sizes?

[J_Darnley]

Probably not different sizes but there will be lower quality in the first one because that is 1-pass ABR. Running the second pass will correct that.

[diimaan]

Probably not different sizes but there will be lower quality in the first one because that is 1-pass ABR. Running the second pass will correct that.

Oh yeah, thanks darnley...

that was the first pass only i did run a 2nd pass with mkv output! :)


--preset placebo --tune film --sar 32:27 --pass 1 --bitrate 1500 --stats "encode.stats" --output NUL
--preset placebo --tune film --sar 32:27 --pass 2 --bitrate 1500 --stats "encode.stats" --output "*.mkv"


this is the full code... :)