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.