Stripping/zeroing chroma Samples?

[SMurf]

Hello,

I want to use some H.264 video as reference input for different transformations of the luma (Y) channel. Ideally I would like this video to contain only luma information.

Reading Wikipedia, the High/Progressive High AVC profiles are supposed to support a monochrome mode (4:0:0), however I understand that x264 in particular doesn't implement this feature as it doesn't significantly improve compression versus having zeroed chroma (U and V) planes.

Accepting that I can't have video that is "flagged" as monochrome, is there a way that I can get x264 to zero the UV coefficients in a colour source file without re-encoding the Y coefficents?

[videoh]

Technically, blanked chroma does not have values 0 for U and V!

If you want to blank the chroma, use GreyScale() in your Avisynth script.

[Keiyakusha]

Technically, blanked chroma does not have values 0 for U and V!

If you want to blank the chroma, use GreyScale() in your Avisynth script.

he needs to blank the chroma in existing h264 stream without re-encoding.

[LoRd_MuldeR]

Accepting that I can't have video that is "flagged" as monochrome, is there a way that I can get x264 to zero the UV coefficients in a colour source file without re-encoding the Y coefficents?

With x264 you can not do anything "without re-encoding", because x264 is a H.264 encoder. It takes uncompressed frames, i.e. "raw" YUV/RGB data, as input. And it returns compressed H.264 bitstream.

Yes, if you use the x264 CLI front-end, you can feed x264 with existing H.264 bitstream. But in that case your input will simply be decompressed by the built-in FFMS2 decoder and then the raw YUV/RGB data is re-encoded by the "core" library.

So, I think that your only option is to "zero out" the chroma, e.g. using the method suggested by videoh, prior to the encoding. I don't know if there exists any tool that can erase chroma information from an existing H.264 bitstream.

[pandy]

Please correct me but AFAIR chroma and luma are coded separately - this should be possible without Y re-encoding (but not with current x264).

[LoRd_MuldeR]

Please correct me but AFAIR chroma and luma are coded separately - this should be possible without Y re-encoding (but not with current x264).

Well, in theory it may be possible to "strip" the chroma information from an existing H.264 bitstream. But it's certainly not as simple as "erasing" the chroma information. You would also have to update all the headers accordingly, so the bitstream can still be decoded properly. In particular, the SPS (Sequence Parameter Set) would have to be updated to indicate the new chroma format, i.e. 4:2:0 vs. monochrome. Probably more non-trivial stuff would need to be updated/fixed.

Furthermore, we need to be aware that H.264 bit-stream doesn't store "raw" data, but entropy-coded data, using CABAC or CAVLC. I'm not sure CABAC/CAVLC encodes the luma and chroma information 100% independently. But if it does not, you'll have a hard time to remove the chroma information. You'd pretty much have to pump all data through a CABAC/CAVLC decoder, then "zero out" the chroma information and finally run the modified data through a CABAC/CAVLC encoder again.

Last but not least, by stripping the chroma information, all of the "smart" RD decisions that the encoder once made are petty much void...

[benwaggoner]

Well, in theory it may be possible to "strip" the chroma information from an existing H.264 bitstream. But it's certainly not as simple as "erasing" the chroma information. You would also have to update all the headers accordingly, so the bitstream can still be decoded properly. In particular, the SPS (Sequence Parameter Set) would have to be updated to indicate the new chroma format, i.e. 4:2:0 vs. monochrome. Probably more non-trivial stuff would need to be updated/fixed.

Furthermore, we need to be aware that H.264 bit-stream doesn't store "raw" data, but entropy-coded data, using CABAC or CAVLC. I'm not sure CABAC/CAVLC encodes the luma and chroma information 100% independently. But if it does not, you'll have a hard time to remove the chroma information. You'd pretty much have to pump all data through a CABAC/CAVLC decoder, then "zero out" the chroma information and finally run the modified data through a CABAC/CAVLC encoder again.

Last but not least, by stripping the chroma information, all of the "smart" RD decisions that the encoder once made are petty much void...

I think you've done a pretty good job outlining how a hacked version of x264 (maybe a little ffmpeg on the front end) could do what's requested.

Parse the original 4:2:0 stream
Entropy decode
Extract just the luma data, and discard the chroma data
Pass the luma data onto a later stage of x264 as if that was the output of luma encoding
Reapply entropy coding (no trellis possible, obviously)
Write out the new stream with correct monochrome headers


Not trivial, but probably not that difficult for an experienced and motivated x264 hacker. I doubt that it'd be particularly worth it from an encoding perspective (very tiny bitrate savings, and the stream would be a lot less compatible), but it would sure be cool to have a more modularized x264 that crazy stuff like this could be done with.

I think the resulting quality would probably be good, as luma is really the tail that wags the dog in terms of bitrate, rate control, etcetera.

[foxyshadis]

Since even a CAVLC->CABAC or CABAC->CAVLC converter doesn't exist and has never been seriously attempted, I think you're off in the weeds alone, SMurf. Maybe someone will whip one up sometime! I think it'd be easiest to use JM, since both encoder and decoder are already present, but maybe that's only because I'm not really familiar with x264's code.

[SMurf]

Well I've done fun things with MPEG2 before, fast split of GOPs and things like that, so I think it's within my coding abilities, but didn't fancy having to decipher another standards document. :(

I'll see how far I can get with a stream on the weekend, maybe post the results. ;)