Video encoding - How low can CRF values go?

[mpalm887]

I'm trying to test and experiment with quality settings in some x264 front end tools. There seems to be some debate about CRF vs. 2-pass encoding and which is better. I understand if you have a file-size target than 2-pass is better whereas the CRF will give you better quality control for an unknown filesize.

RipBot's lowest CRF value is 18 but can I manually input 15 and get even better quality or will it just default back to 18 when the encode happens?

Filesize isn't an issue and most of my blu-rays won't have video compression but my DVD collection is a little different. I've got several DVD's that were advertized as widescreen but were infact 2.4:1 AR movies letterboxed in a 4:3 frame. So playback on HDTV's leaves you zooming in as the only way to get a good view of the actual film while keeping people's faces looking normal. Some cropping/encoding will be necessary.

[poisondeathray]

Yes you can manually enter values; you're not limited to the drop down presets. CRF15 will give better quality (and larger filesize) than CRF18

[jagabo]

I've got several DVD's that were advertized as widescreen but were infact 2.4:1 AR movies letterboxed in a 4:3 frame. So playback on HDTV's leaves you zooming in as the only way to get a good view of the actual film while keeping people's faces looking normal. Some cropping/encoding will be necessary.

Unless your TV has a particularly bad zoom, cropping and encoding in software won't improve the picture.

[mpalm887]

I've got several DVD's that were advertized as widescreen but were infact 2.4:1 AR movies letterboxed in a 4:3 frame. So playback on HDTV's leaves you zooming in as the only way to get a good view of the actual film while keeping people's faces looking normal. Some cropping/encoding will be necessary.

Unless your TV has a particularly bad zoom, cropping and encoding in software won't improve the picture.

I'm not counting on an actual increase in visual quality, I just don't want to be staring at a rectangle inside a black square which is itself in a black rectangle again. Simplifies things to crop so that I don't have to zoom. Furthermore I find that the DVD's that have this problem are typically not the most stellar PQ anyway, and the x264 gives almost zero noticeable quality loss after encoding.

[mpalm887]

Yes you can manually enter values; you're not limited to the drop down presets. CRF15 will give better quality (and larger filesize) than CRF18

Thanks.

On a side-note, will a 2-pass encode give a variable or constant bitrate? And if you KNEW the output filesize would the 2-pass mode be a better choice for quality/GB?

[Ethlred]

On a side-note, will a 2-pass encode give a variable or constant bitrate?

x264 is always variable bit rate. It is inherent in the way it encodes.

And if you KNEW the output filesize would the 2-pass mode be a better choice for quality/GB?

When you have a specific size you want to achieve then 2-pass will get the best results possible for that size. If you don't care about the size then CRF is the best choice. Myself I test with the CRF to get an idea of how well the file will compress because I do care about the size but don't have a specific target. I like to keep between one and two gigbytes. I find that CRF 20 or 21 usually is right for me but I might find that I should have been using lower CRF numbers when I get a larger monitor.

Ethelred

[jagabo]

Simplifies things to crop so that I don't have to zoom... Furthermore I find that the and the x264 gives almost zero noticeable quality loss after encoding.

If you're going to reencode with x264 anyway you might as well crop, yes.

On a side-note, will a 2-pass encode give a variable or constant bitrate? And if you KNEW the output filesize would the 2-pass mode be a better choice for quality/GB?

With bitrate based encoding you know the file size but you don't know the quality. With quality based encoding you know the quality but not the file size. If you perform a CRF encode and the file turns out a certain size, then go back and do a 2-pass VBR encode for the same size (without changing other settings) the quality of the two files will be very similar.

By the way, you can set CRF as low as zero -- lossless encoding. But the file size will be enormous.

[NY2LA]

By the way, you can set CRF as low as zero -- lossless encoding. But the file size will be enormous.

So what would happen if I did this to my raw DV stream files? Would I get all I-frame H.264 video, at the same 13GB per hour as DV? Does H.264 support such a thing?

If so, perhaps it would be one way to make the DV more playable on miscellaneous devices?

[jagabo]

By the way, you can set CRF as low as zero -- lossless encoding. But the file size will be enormous.

So what would happen if I did this to my raw DV stream files? Would I get all I-frame H.264 video, at the same 13GB per hour as DV? Does H.264 support such a thing?

If so, perhaps it would be one way to make the DV more playable on miscellaneous devices?

It won't really work. There are several issues:

1) NTSC DV uses YUV 4:1:1 chroma subsampling. x264 doesn't support that. You would have to convert to interlaced YV12. There will be some losses from that conversion.

2) Few playback devices support lossless h.264.

3) The resulting video will usually have a higher bitrate than the source DV. About 2x, in my experience.

[NY2LA]

It won't really work. There are several issues:

1) NTSC DV uses YUV 4:1:1 chroma subsampling. x264 doesn't support that. You would have to convert to interlaced YV12. There will be some losses from that conversion.

2) Few playback devices support lossless h.264.

3) The resulting video will usually have a higher bitrate than the source DV. About 2x, in my experience.

Okay, forget that idea (DV to H.264 losslessly). Can you recommend any particular settings when going from DV to H.264 (with MP4 wrapper) that would result in H.264 video without a visible difference? Perhaps using an x264 encoder, though not necessarily. The objective would be files that will playback on something like a WD TV Media Player.

Encoding time would not be an issue. I can even render the DV as uncompressed, 10-bit, 4:2:2 video (in Final Cut Pro X), and compress that to H.264, if you think there would be any point.

[NY2LA]

Sorry, I didn't notice this is a blu-ray ripping forum. I should post my last post elsewhere.

[jagabo]

Can you recommend any particular settings when going from DV to H.264 (with MP4 wrapper) that would result in H.264 video without a visible difference? Perhaps using an x264 encoder, though not necessarily. The objective would be files that will playback on something like a WD TV Media Player.

Encoding at CRF 10 will get you files that are nearly indistinguishable from the original even when looking at enlarged still frames. Be sure to specify --bff (interlaced, bottom field first for DV AVI) and the correct aspect ratio*:

x264 --crf 10 --bff --sar 10:11 --output filename.mp4 filename.avi

The resulting files should be playable on most media players that can play h.264 mp4. And they will usually be smaller than the source.

That's just the video of course. You'll have to encode and mux in the audio separately. Or use one of the x264 front ends that handles audio along with the video.


* DV pixel aspect ratios (called sample aspect ratios in x264) :

NTSC 4:3: --sar 10:11
NTSC 16:9: --sar 40:33
PAL 4:3: --sar 12:11
PAL 16:9: --sar 16:11

[NY2LA]

Be sure to specify --bff (interlaced, bottom field first for DV AVI) and the correct aspect ratio*:

I'd rather deinterlace, if feasible, rather than depend on a player to handle it.

* DV pixel aspect ratios (called sample aspect ratios in x264) :

NTSC 4:3: --sar 10:11

The PAR (aka sar) is confusing. 10:11 will horizontally scale 720 x 480 to production aperture of 654 x 480. The video also needs to be cropped on the left and right to clean aperture of 640 x 480. Where does that take place? Does the H.264 recognize both apertures, and the player is supposed to know what to do? Or should the DV video be both horizontally scaled and cropped when compressing to H.264, and the resulting H.264 consist of only the pixels representing the clean aperture?

[jagabo]

Be sure to specify --bff (interlaced, bottom field first for DV AVI) and the correct aspect ratio*:

I'd rather deinterlace, if feasible, rather than depend on a player to handle it.

Then deinterlace with your favorite deinterlacer and encode progressive. I'd use QTGMC() in AviSynth and encode at 60 fps.

* DV pixel aspect ratios (called sample aspect ratios in x264) :

NTSC 4:3: --sar 10:11

The PAR (aka sar) is confusing. 10:11 will horizontally scale 720 x 480 to production aperture of 654 x 480. The video also needs to be cropped on the left and right to clean aperture of 640 x 480. Where does that take place?

DV follows the ITU 601 D1 spec. The 4:3 image in a DV frame is in the central 704x480 subsection of the frame. 704 * 10 / 11 = 640. The entire 720x480 DV frame is slightly wider than 4:3.

When you set --sar in h.264 you are setting the sample aspect ratio (aka pixel aspect ratio). It becomes the player's responsibility to resize the image for display. If you want to resize to square pixel, crop the DV frame down to 704x480 and resize to 640x480 or some other 4:3 frame size.

[NY2LA]

DV follows the ITU 601 D1 spec. The 4:3 image in a DV frame is in the central 704x480 subsection of the frame. 704 * 10 / 11 = 640. The entire 720x480 DV frame is slightly wider than 4:3.

When you set --sar in h.264 you are setting the sample aspect ratio (aka pixel aspect ratio). It becomes the player's responsibility to resize the image for display. If you want to resize to square pixel, crop the DV frame down to 704x480 and resize to 640x480 or some other 4:3 frame size.

So you are saying, h.264 supports the ITU 601 D1 spec, and the video can still be non-square 720 x 480 pixels, and the player supposedly understands what to do? Is the player supposed to actually "read" the sar?

I think I would prefer to crop and scale the video to square pixels beforehand, to account for players that won't know what to do.

[jagabo]

So you are saying, h.264 supports the ITU 601 D1 spec

No, h.264 supports sample aspect ratios. The SAR can conform to ITU 601 or not.

and the video can still be non-square 720 x 480 pixels, and the player supposedly understands what to do? Is the player supposed to actually "read" the sar?

Yes, the player is supposed to read the SAR and resize for display.

I think I would prefer to crop and scale the video to square pixels beforehand, to account for players that won't know what to do.

I'd rather keep all the resolution and let the player do the scaling.

[NY2LA]

I'd rather keep all the resolution and let the player do the scaling.

So if I am scaling and cropping to 640 x 480 (as opposed to some other 4:3 size), you would consider that not keeping all the resolution?

[jagabo]

I'd rather keep all the resolution and let the player do the scaling.

So if I am scaling and cropping to 640 x 480 (as opposed to some other 4:3 size), you would consider that not keeping all the resolution?

Resizeing 720 pixels down to 640 pixels is losing resolution. When a media player plays a 720x480 video it does not scale the 720x480 frame to 640x480 then scale it again to the output resolution. It scales directly from the 720x480 frame.

[NY2LA]

Resizeing 720 pixels down to 640 pixels is losing resolution. When a media player plays a 720x480 video it does not scale the 720x480 frame to 640x480 then scale it again to the output resolution. It scales directly from the 720x480 frame.

I see. Good point.

[_Al_]

I use 640x480 , recently rather 720x540 resize , not feeling good about to leave 720x480 and to set 4:3 NTSC aspect ratio by MeGui , I use DVXA SD HQ settings, CQ18.
from Vegas timeline:

AviSource("D:\server.avi")
ConvertToYV12(interlaced=true,matrix="pc.601")
QTGMC( Preset="Slow" )
Lanczos4Resize(640,480) #or 720x540

very good result, the only problem is possible pixelation in very dark areas, shades, dark gradients, is there a way to consolidate it within MeGui ? CQ ussualy sets bit rate very well, but in this case it is the only problem that doesn't look like original after close look

[gonwk]

... I find that CRF 20 or 21 usually is right for me but I might find that I should have been using lower CRF numbers when I get a larger monitor.

Ethelred

Hi Ethelred,

Can you tell me what size is your Current Monitor size!?!?

Thanks!

G!

[jagabo]

I use DVXA SD HQ settings, CQ18... the only problem is possible pixelation in very dark areas, shades, dark gradients, is there a way to consolidate it within MeGui

The only way to combat that really is to raise the bitrate. I use --qcomp=0.85. The default is 0.6 and the max is 1.0.

[Ethlred]

Hi Ethelred,

Can you tell me what size is your Current Monitor size!?!?

It's a 19inch CRT Viewsonic. I use it at 1024x768 most of the time and switch to 1280x960 when I am watching higher resolution video. My PC is too decrepit to push 1080P video.

Ethelred

[Ethlred]

very good result, the only problem is possible pixelation in very dark areas, shades, dark gradients, is there a way to consolidate it within MeGui ?

The only way to combat that really is to raise the bitrate. I use --qcomp=0.85. The default is 0.6 and the max is 1.0.

I have been using the default of .6.

Perhaps this setting would help him more directly. It was created for just this purpose. I read about the predecessor settings on Doom 9 in Dark Shakiri's comments on the issue of blocking. The blocking in flat and dark areas was a major annoyance for me I used Xvid much longer than I otherwise would have.

From
http://mewiki.project357.com/wiki/X264_Settings#qcomp

aq-mode

Adaptive Quantization Mode

Default: 1

Without AQ, x264 tends to underallocate bits to less-detailed sections. AQ is used to better distribute the available bits between all macroblocks in the video. This setting changes what scope AQ re-arranges bits in:

0: Do not use AQ at all.
1: Allow AQ to redistribute bits across the whole video and within frames.
2: Auto-variance AQ (experimental) which attempts to adapt strength per-frame.

See also: --aq-strength
aq-strength

Adaptive Quantization Strength

Default: 1.0

Sets the strength of AQ bias towards low detail ('flat') macroblocks. Negative values are not allowed. Values outside the range 0.0 - 2.0 are probably a bad idea.

See also: --aq-mode

I am using the default settings of aq-mode=2 and aq-strength=1.0. Since that is the default. Al may have it turned off.


It has the same defaults in the latest version

 --aq-mode <integer>     AQ method [1]
                             - 0: Disabled
                             - 1: Variance AQ (complexity mask)
                             - 2: Auto-variance AQ (experimental)
 --aq-strength <float>   Reduces blocking and blurring in flat and
                         textured areas. [1.0]

Ethelred

[jagabo]

Using aq-mode and aq-strength I think he'll have to set the strength to about 2.0. But I'm not using the latest release of AviSynth. Maybe things have changed.

[Ethlred]

The defaults were good enough to stop the blocking for me.

I suppose AviSynth could be a source of blocking but it has nothing to do aq-mode as that is a x264 setting. Unless I am missing something.

I have looking over some threads on doom10.org, Dark Shikari's 'I am pissed at Doom9' site and a number of the problems some have had is that they disabled the aq-mode and then wondered why they got poor results.

Ethelred

[jagabo]

Sorry, I wasn't thinking straight when I mentioned AviSynth. I meant x264.