Cropping h264 file without reencoding?

[yesgrey]

Hi,
Sorry if it's a dumb question, but since H264 divides the frame in several blocks, is it possible to remove some of them without decoding/reencoding?

For example:
Some movies are encoded to 1920x1080 but in the height only use 816 pixels of the 1080 available. Since all those pixels are black, is it possible to manipulate the h264 file and create a new file just by removing those blocks?
Is the size occupied by these "black" blocks insignificant?

Thanks.

[Selur]

is it possible to remove some of them without decoding/reencoding?
No, it's not.

[yesgrey]

Thanks.

[Dark Shikari]

It is possible, by modifying the cropleft/croptop/cropright/cropbottom flags, but it won't save you any bits. Not like it costs any to begin with. And many decoders don't support cropping of >= 16 pixels, or cropping of top/left.

[Sagekilla]

Someone posted about this earlier in another topic, the basic idea is that: The black borders are perfectly black (no noise) so the MBs coding them are filled with zeros which take (relatively) no bits to encode.

So you have nothing to worry about, since the 264 lines of borders take up < 0.001% of all the bitrate, if even that much.

[LoRd_MuldeR]

When muxing to MKV one can specify cropping parameters for the video stream:
--cropping <TID:left,top,right,bottom>

This of course won't save any bits, which should be no problem (as explained by Sagekilla). However I'm not sure which players actually read cropping flags from MKV files...

[madshi]

And many decoders don't support cropping of >= 16 pixels, or cropping of top/left.
Thanks for that piece of information, didn't know that.

I was thinking of using cropping to make some specific frames (e.g. corrupted frames or advertizing leftovers) completely black. I guess I can forget about that idea now. I was anticipating potential problems with some decoders when changing cropping values in the middle of a stream, but I didn't anticipate that cropping support was *that* much limited in many decoders... :(

[Selur]

So you have nothing to worry about, since the 264 lines of borders take up < 0.001% of all the bitrate, if even that much.
Had to test this. :)

using: (cropping black bars)
decoderCL:
mencoder "cropTest.vob" -really-quiet -ovc raw -noskip -mc 0 -nosound -vf yadif=0,crop=720:432:0:72,format=i420 -ofps 25 -of rawvideo -o -
encoderCL:
x264 --crf 18 --level 4.1 --ref 1 --keyint 250 --min-keyint 25 --scenecut 40 --ratetol 1 --cplxblur 20 --qcomp 0.6 --qblur 0.5 --vbv-maxrate 50000 --vbv-bufsize 62500 --qpmin 1 --qpmax 51 --qpstep 4 --ipratio 1.4 --pbratio 1.3 --chroma-qp-offset 0 --direct-8x8 1 --partitions none --me dia --merange 4 --mvrange 64 --subme 0 --no-chroma-me --aq-mode 0 --deadzone-inter 24 --deadzone-intra 11 --threads auto --no-cabac --sar 1422:1000 --filter 0,0 --no-psnr --no-ssim --stats "C:\Dokumente und Einstellungen\Selur\Desktop\cropped_174034015.stats" --progress --fps 25 --output "cropped.mp4" - 720x432
gave me a file size of 4.390.384 Bytes

using: (not cropping)
decoderCL:
mencoder "cropTest.vob" -really-quiet -ovc raw -noskip -mc 0 -nosound -vf format=i420,yadif=0 -ofps 25 -of rawvideo -o -
encoderCL:
x264 --crf 18 --level 4.1 --ref 1 --keyint 250 --min-keyint 25 --scenecut 40 --ratetol 1 --cplxblur 20 --qcomp 0.6 --qblur 0.5 --vbv-maxrate 50000 --vbv-bufsize 62500 --qpmin 1 --qpmax 51 --qpstep 4 --ipratio 1.4 --pbratio 1.3 --chroma-qp-offset 0 --direct-8x8 1 --partitions none --me dia --merange 4 --mvrange 64 --subme 0 --no-chroma-me --aq-mode 0 --deadzone-inter 24 --deadzone-intra 11 --threads auto --no-cabac --sar 1422:1000 --filter 0,0 --no-psnr --no-ssim --stats "C:\Dokumente und Einstellungen\Selur\Desktop\not_cropped_174336390.stats" --progress --fps 25 --output "not_cropped.mp4" - 720x576
gave me a file size of: 4.973.239 Bytes

uploaded source + encodes to: http://www.megaupload.com/de/?d=BKBFKPKS

To be frank I was a bit surprised that the filesize of the not-cropped version is smaller. Is this some funky side effect of --subme 0 (used it for testing only to get a fast result :)), was it expectable or is it related to the clip I used?
(using git sources from yesterday with hrd patch applied)

Cu Selur

[LoRd_MuldeR]

didn't anticipate that cropping support was *that* much limited in many decoders...

I think that's because it doesn't make much sense to crop more than 15 pixels. In the worst case a non-mod16 source needs to be padded by 15 pixels.

Cropping away more pixels than the pixels that had been added during the encoding process is nonsensical. These pixels could have been removed before the encode!

So why should anybody waste bits for pixels that will never be displayed? The only reason is non-mod16 support and that's it.

I see why you want to crop more than 15 pixels in this case. But you should have cropped the video before the encode instead of trying to fix it afterwards...

[Dark Shikari]

To be frank I was a bit surprised that the filesize of the not-cropped version is smaller. Is this some funky side effect of --subme 0 (used it for testing only to get a fast result :)), was it expectable or is it related to the clip I used?
(using git sources from yesterday with hrd patch applied)

Cu SelurThe reason is because CRF weights frame quantizers by overall frame complexity.

Having large black areas in a frame makes it simpler, so CRF lowers the quantizer.

Thus, the only valid way to measure the effect of the black areas on compression is constant-quantizer encoding, or qcomp=1 encoding with CRF.

[Selur]

with constant quant 18:
cropped.mp4 -> 3.750.613 Bytes
not_cropped.mp4 -> 3.759.761 Bytes
-> world is in harmony again
Thanks for explaining :)

Cu Selur

[madshi]

But you should have cropped the video before the encode instead of trying to fix it afterwards...
I wanted to "fix" the original broadcast video stream without reencoding it.

[LoRd_MuldeR]

I wanted to "fix" the original broadcast video stream without reencoding it.

Which doesn't change the fact that the areas you want to "hide" should have never been included into the stream.

It can't be desirable to encode any areas into the video stream that will never appear on the screen. Even if this are "black" borders and they cost only few bits, they still cost some bits at least. The only valid reason to use the H.264 cropping flags is none-mod16 support and I think that's what these flags were intended for. Not for "fixing" badly encoded streams...

What about the Matroska method mentioned above? It can crop as many pixels as you want. You only need to use a suitable player ;)

[yesgrey]

It is possible, by modifying the cropleft/croptop/cropright/cropbottom flags, but it won't save you any bits.
I was thinking in removing them from the file, to create a new, but smaller.

the 264 lines of borders take up < 0.001% of all the bitrate, if even that much.
with constant quant 18:
cropped.mp4 -> 3.750.613 Bytes
not_cropped.mp4 -> 3.759.761 Bytes
0.24%;)

the only valid way to measure the effect of the black areas on compression is constant-quantizer encoding, or qcomp=1 encoding with CRF.
The question started with a test I have made, with crf18, to see how much space the ending credits used, and it was a lot! So I removed them. Now I understand, I should have used qcomp=1 for my test... I have to try again... Thanks for the info.:)

Which doesn't change the fact that the areas you want to "hide" should have never been included into the stream.
Yes, but when we buy a blu-ray, there's not much we can do about it...;) but since the space used is minimal, no problem.

[madshi]

Which doesn't change the fact that the areas you want to "hide" should have never been included into the stream.

It can't be desirable to encode any areas into the video stream that will never appear on the screen. Even if this are "black" borders and they cost only few bits, they still cost some bits at least. The only valid reason to use the H.264 cropping flags is none-mod16 support and I think that's what these flags were intended for. Not for "fixing" badly encoded streams...

What about the Matroska method mentioned above? It can crop as many pixels as you want. You only need to use a suitable player ;)
I think you are misunderstanding me. I'm talking about capturing a movie broadcasted by satellite and I do not want to reencode it. Sometimes such a capture isn't clean, but there's some corruption in there (caused by bad reception due to e.g. heavy thunderstorm). Now you can say: "The corruption you want to "hide" should have never been included into the stream". Doh! Of course nobody wants to have corruption in a recorded broadcast! But sometimes that's just the way it is and there's nothing you can do against that.

Using the MKV method doesn't work AT ALL for my purpose cause I wanted to blend out only the corrupted frames and not the whole movie.

Another purpose of blending out specific frames would be (again with broadcasts) when a movie doesn't start on an IDR frame. In such a situation it would be nice to be able to make all frames from the IDR frame to the beginning of the movie black. I thought I could eventually use cropping for that, but evidently I can't... :(

[me7]

using: (cropping black bars)
...
gave me a file size of 4.390.384 Bytes

using: (not cropping)
...
gave me a file size of: 4.973.239 Bytes
...
To be frank I was a bit surprised that the filesize of the not-cropped version is smaller.


Isn't the not-cropped version bigger?

[nurbs]

In post #8 the non-cropped version is bigger.
In post #10 Dark Shikari tells Selur why he should have tested with the cq mode.
In post #11 there are the correct results.

[me7]

I see it that way:

In post #8 the non-cropped version is bigger but Selur says that the non-cropped is smaller.
In post #10 Dark Shikari explains why the non-cropped is smaller (although it isn't, just look at the filesize).
In post #11 the non-cropped version is still bigger, but this time everyone is satisfied.
In post #16 I'm very confused???

[nurbs]

In post #10 Dark Shikari explains why the non-cropped version, the one with the black bar, is that much bigger. Having large black areas in a frame makes it simpler, so CRF lowers the quantizer.
I can see that Selur wrote it's smaller, but that's obviously just a typo.

edit:
The reason why the non cropped version is supposed to be bigger is, that the black bars are a bit harder to encode than whatever x264 uses to pad non mod16 resolutions.

[Selur]

yup, was a typo on my end, sorry for the mixup :)

[Sagekilla]

@nurbs: That's part of the reason, not the whole. Having borders with nothing in them will still consume bits (few, mind you) and having a sharp transition at the very last border line on the top and bottom eats some more.. x264 pads by repeating the last line, which tends to be easier to encode.

[bond]

It is possible, by modifying the cropleft/croptop/cropright/cropbottom flags, but it won't save you any bits. Not like it costs any to begin with. And many decoders don't support cropping of >= 16 pixels, or cropping of top/left.h264info should be able to do that

[chenm001]

I think someone can do not reencoder when crop, but can not found any tools how. You need to write a tool.
The tool need re-calculate the MV, reference frame id, etc.

[evlo]

How can i most easily determine how many pixels to crop?

[eathasa]

How can i most easily determine how many pixels to crop?

I'm not a video encoding/tools expert. I'm an occasional user, so you may get a better answer - But two ways I have used:
1) If you are trying to crop letterboxes (black bars on top and bottom) from a movie, you can calculate the pixels to crop based on the aspect ratio of the film itself. The exact number of pixels to crop also depends on the source video's aspect ratio (including the letterboxes -- 4:3 or 16:9 for DVD and broadcast captures) and the pixel aspect ratio (square pixels or NTSC/PAL PARs).
2) Nero Recode allows you to preview any frame of the video and drag crop bars to crop exactly to the edge of the part of the video you want to retain. Other tools may have this feature as well -- I'm not sure. If you have Nero Recode, you could use this feature to calculate your crop and then use the numbers in other tools rather than continuing with the Nero encode.

I created an OpenOffice spreadsheet a few years ago that automates calculating cropping and resizing for converting videos with square, NTSC, or PAL pixels (including overscan compensation for NTSC and PAL). I was unable to find any tools at the time to assist in making all the calculations. I've never shared it before, but I can post the spreadsheet if anyone's interested.


As to the original question in this thread (which I see is quite old), I can't remember what tool it was offhand, but in years past there was a tool I used that could quickly crop at least TS and DVR-MS files without reencoding. It was designed for use with Windows Media Center 2005. I don't know what it was, if it's continued to be updated, or if it has expanded to support other formats, but it seemed to be kind of one-of-a-kind at the time. I think it also could make cuts (including an automated commercial removal feature) although I didn't use that function.