black and white movie specific options?

StriatedFoot · 9th October 2007, 23:57

I encode a lot of older movies in black and white. Are there any options that can be turned on or off for a more efficient coding? For example, should I disable chroma motion estimation for B&W encodes?

[PS - sorry I didn't include this in my other question...]

J_Darnley · 10th October 2007, 00:10

x264 has a --no-chroma-me option. I would guess that it disables the processing on the chroma planes. This might just cause x264 to copy the luma motion estimation to the chroma thus eliminating any benefit for the lack of chroma info.

There is also a --chroma-qp-offset option which you could then set to 51 to force the chroma quantisers to be 51 but I also don't know if this would affect a B&W clip.

x264 does lack some of the 'advanced' options like those of ffmpeg.

akupenguin · 10th October 2007, 00:40

If the chroma planes are empty, they won't take any bits anyway. The only possible benefit from B&W specific options is to save cpu time. And --no-chroma-me is the only such option in x264.
But make sure chroma is really empty (pure digital 128). Just because the content doesn't have color doesn't mean the DVD masterers didn't manage to screw it up and introduce a little color somewhere.

StriatedFoot · 10th October 2007, 01:35

Aku, do you mean CPU during the encode or the decode? Or both? And will there be any effect on the output at all, either in terms of file size or quality by disabling chroma during the conversion?

And how do I go about making sure that chroma is really empty? [FWIW, I'm using megui...]

Dark Shikari · 10th October 2007, 01:46

Quote:

Originally Posted by StriatedFoot

Aku, do you mean CPU during the encode or the decode? Or both? And will there be any effect on the output at all, either in terms of file size or quality by disabling chroma during the conversion?

And how do I go about making sure that chroma is really empty? [FWIW, I'm using megui...]

Encode, not decode. There will be no measurable effect on the output.

akupenguin · 10th October 2007, 02:01

Quote:

Originally Posted by StriatedFoot

Aku, do you mean CPU during the encode or the decode? Or both?

Both, but they're independent. If the decoder has any grayscale optimizations, they can be enabled regardless of what options you set in the encoder.

Quote:

And will there be any effect on the output at all, either in terms of file size or quality by disabling chroma during the conversion?

If the chroma planes are really empty, then there's no difference in the output. If there is some erroneous chroma data, then removing it will reduce bitrate.
If x264 supported an actual grayscale colorspace, that would save a few bits per frame. But it doesn't, since I never implemented it, since the benefits are so small.

Quote:

And how do I go about making sure that chroma is really empty? [FWIW, I'm using megui...]

I don't know off-hand, but there must be some avisynth filter that can set saturation to zero.

Dark Shikari · 10th October 2007, 02:19

Quote:

Originally Posted by akupenguin

I don't know off-hand, but there must be some avisynth filter that can set saturation to zero.

Greyscale() works I think.

foxyshadis · 10th October 2007, 04:38

You might as well set the chroma qp to 1 instead of 51, to ensure no deblocking gets done. It won't change the picture, nothing is nothing whether you blur it or not, but it'll make the decoder happy. I have no idea whether this would happen automatically if you just left it alone, I don't know how to analyze chroma planes like that.

akupenguin · 10th October 2007, 07:31

Dunno about other decoders, but lavc isn't optimized for that case. Few people use chroma-qp-offset, and it would be a useless extra branch for most streams. So lavc always runs chroma deblocking whenever luma deblocking is appropriate, and if chroma qp is lower it just has reduced strength, possibly 0.

pandy · 10th October 2007, 15:32

Quote:

I don't know off-hand, but there must be some avisynth filter that can set saturation to zero.

Limiter(0, 255, 128, 128) works very well

Sergey A. Sablin · 11th October 2007, 02:19

there is also chroma MC, which is used regardless of chroma residuals and chroma quantizer. And it takes another few %% of decoding. So using 4:0:0 color space at encoder in this case will save you some CPU consumption at decoding.

akupenguin · 11th October 2007, 07:53

That's what I said: If the decoder supports 4:0:0, it can benefit from that. But while it's nice for the file's colorspace to match the content, the decoder can also treat a video as 4:0:0 even if it isn't at the bistream level.

9th October 2007, 23:57	#1 \| Link
StriatedFoot Registered User Join Date: Sep 2007 Posts: 10	black and white movie specific options? I encode a lot of older movies in black and white. Are there any options that can be turned on or off for a more efficient coding? For example, should I disable chroma motion estimation for B&W encodes? [PS - sorry I didn't include this in my other question...]

10th October 2007, 00:10	#2 \| Link
J_Darnley Registered User Join Date: May 2006 Posts: 957	x264 has a --no-chroma-me option. I would guess that it disables the processing on the chroma planes. This might just cause x264 to copy the luma motion estimation to the chroma thus eliminating any benefit for the lack of chroma info. There is also a --chroma-qp-offset option which you could then set to 51 to force the chroma quantisers to be 51 but I also don't know if this would affect a B&W clip. x264 does lack some of the 'advanced' options like those of ffmpeg. __________________ x264 log explained \|\| x264 deblocking how-to preset -> tune -> user set options -> fast first pass -> profile -> level Doom10 - Of course it's better, it's one more.

10th October 2007, 00:40	#3 \| Link
akupenguin x264 developer Join Date: Sep 2004 Posts: 2,392	If the chroma planes are empty, they won't take any bits anyway. The only possible benefit from B&W specific options is to save cpu time. And --no-chroma-me is the only such option in x264. But make sure chroma is really empty (pure digital 128). Just because the content doesn't have color doesn't mean the DVD masterers didn't manage to screw it up and introduce a little color somewhere. Last edited by akupenguin; 10th October 2007 at 00:44.

10th October 2007, 01:35	#4 \| Link
StriatedFoot Registered User Join Date: Sep 2007 Posts: 10	Aku, do you mean CPU during the encode or the decode? Or both? And will there be any effect on the output at all, either in terms of file size or quality by disabling chroma during the conversion? And how do I go about making sure that chroma is really empty? [FWIW, I'm using megui...]

10th October 2007, 04:38	#8 \| Link
foxyshadis Angel of Night Join Date: Nov 2004 Location: Tangled in the silks Posts: 9,549	You might as well set the chroma qp to 1 instead of 51, to ensure no deblocking gets done. It won't change the picture, nothing is nothing whether you blur it or not, but it'll make the decoder happy. I have no idea whether this would happen automatically if you just left it alone, I don't know how to analyze chroma planes like that.

10th October 2007, 07:31	#9 \| Link
akupenguin x264 developer Join Date: Sep 2004 Posts: 2,392	Dunno about other decoders, but lavc isn't optimized for that case. Few people use chroma-qp-offset, and it would be a useless extra branch for most streams. So lavc always runs chroma deblocking whenever luma deblocking is appropriate, and if chroma qp is lower it just has reduced strength, possibly 0.

11th October 2007, 02:19	#11 \| Link
Sergey A. Sablin Registered User Join Date: Dec 2004 Location: Tomsk, Russia Posts: 366	there is also chroma MC, which is used regardless of chroma residuals and chroma quantizer. And it takes another few %% of decoding. So using 4:0:0 color space at encoder in this case will save you some CPU consumption at decoding.

11th October 2007, 07:53	#12 \| Link
akupenguin x264 developer Join Date: Sep 2004 Posts: 2,392	That's what I said: If the decoder supports 4:0:0, it can benefit from that. But while it's nice for the file's colorspace to match the content, the decoder can also treat a video as 4:0:0 even if it isn't at the bistream level.