Allowed Cropping for x264 Playback on PC?

[Seraphic-]

Hi,

What are the defined parameters for cropping x264 videos for play on PC only? Will it be acceptable as long as it's mod2, mod4, mod8, or mod16? Also, will the compression hit be the same for anything that is not mod16? And are there any other downsides other then less compression if you don't use mod16?

Thanks

[Dark Shikari]

The loss in compression is the extra bits required to pad the image up to mod16.

This is not a lot of bits.

[Seraphic-]

The loss in compression is the extra bits required to pad the image up to mod16.

This is not a lot of bits.

You mean an encoder like Megui will auto add borders to mod16 during encoding?

[Dark Shikari]

You mean an encoder like Megui will auto add borders to mod16 during encoding?MeGUI isn't an encoder. Does x264 do it? Yes. They're then cropped on playback by the decoder.

[Seraphic-]

MeGUI isn't an encoder. Does x264 do it? Yes. They're then cropped on playback by the decoder.

MeGUI calls itself "MeGUI Modern Media Encoder". But using it for x264 encoding.

I'm asking because a lot of times I end up like four pixels short of mod16 when cropping. So wanted to see what is allowed for PC playback with x264.

[desta]

This isn't a test per se, but just a way of clarifying what Dark Shikari is saying. Encode a small bit of your source at the non mod16 resolution you've cropped to, play it back in the container you encoded to, mkv or mp4 - it will play back at the resolution you input.

Now demux the .h264 stream from the container, and play the demuxed stream - it will play back at the padded mod16 resolution. Obviously that works just as well when encoding straight to raw .264.

There's simply a flag in the stream that tells whatever muxed container to crop back the padded lines when played back, but when there's no container you'll see it as it was actually encoded.

[Dark Shikari]

This isn't a test per se, but just a way of clarifying what Dark Shikari is saying. Encode a small bit of your source at the non mod16 resolution you've cropped to, play it back in the container you encoded to, mkv or mp4 - it will play back at the resolution you input.

Now demux the .h264 stream from the container, and play the demuxed stream - it will play back at the padded mod16 resolution. Obviously that works just as well when encoding straight to raw .264.

There's simply a flag in the stream that tells whatever muxed container to crop back the padded lines when played back, but when there's no container you'll see it as it was actually encoded.Incorrect; the crop flag is in the stream itself, not the container.

[desta]

Incorrect; the crop flag is in the stream itself, not the container.
"There's simply a flag in the stream that tells whatever muxed container to crop back..."

[Dark Shikari]

"There's simply a flag in the stream that tells whatever muxed container to crop back..."No, it doesn't--it doesn't "tell the container" anything. Also, you said:Now demux the .h264 stream from the container, and play the demuxed stream - it will play back at the padded mod16 resolution.No, it won't, unless your muxer, demuxer, or decoder is extremely buggy.

[desta]

I guess I must be mistaken then, but it seems that it has for me. I've even looked at the video renderer info to see that the raw [non muxed] 264 stream is playing back at a mod16 resolution, whilst the same muxed stream plays back at the cropped modwhatever resolution.

raw stream:

http://img104.imageshack.us/img104/6063/rawgw5.png


muxed stream:

http://img46.imageshack.us/img46/49/muxedqp6.png


... same encode.

As I said, it will do that, for me at least, even if I encode straight to raw 264, so that rules out muxers and demuxers (unless you're talking of the graph filter variety?), and it appears to do it regardless of what decoder I use too.

:confused:

Anyway, it's no big deal, all I was doing was saying that the stream will actually be mod16 regardless of giving a non-mod16 input.

[check]

desta, blame your (differing) source filter.

To the OP:
Encoding at less than mod4 is bad in terms of playback compatibility. Quite a few combinations of GPU + driver fail to correctly decode mod2 (and less often mod4) video -- in particular nvidia 8800s and most existing drivers for them.

[Seraphic-]

I made a test video to see what the size difference would be. However, both videos came out the same size. One was 1276x716 and the other 1280x720 and both used the same encoding profile. Shouldn't the mod4 one be larger then the mod16? Or are there other downsides in mod4 vs mod16?

[Dark Shikari]

I made a test video to see what the size difference would be. However, both videos came out the same size. One was 1276x716 and the other 1200x720 and both used the same encoding profile. Shouldn't the mod4 one be larger then the mod16? Or are there other downsides in mod4 vs mod16?If you encoded with the same target bitrate of course they're going to be the same size.

[Seraphic-]

If you encoded with the same target bitrate of course they're going to be the same size.

But I thought using something other then mod16 would give less compression? (and thus a larger overall file size)

[Dark Shikari]

But I thought using something other then mod16 would give less video size compression? (and thus a larger overall file size)Its always going to be the same size if you tell x264 to make it that size, which is what target bitrate mode does. "Lower compression" means "less quality at the same bitrate" or "higher bitrate at the same quality."

[Inventive Software]

You wanna compare resolution to file size, you gotta use CRF or CQ mode. Target bitrate means target bitrate, regardless of resolution. ;)

[Seraphic-]

But even using target bit-rate, CRF or CQ mode, would the 1276x716 always have a lower picture quality then a 1280x720?

[Inventive Software]

Not if that's as a result of cropping. ;) In all likelihood, it'll be the same, but if you wanna be sure, do the tests yerself. I ain't got the CPU or sources to encode 720p! :p

[J_Darnley]

Well 1276x716 will come out the file same size as 1280x720 because 1276x716 will be padded up to 1280x720 (depends on what was cropped though). If using a constant quality mode, so you tell x264 to achieve this quality, then how it it going to end up with lower quality?

[Brother John]

Back in January I did a test:
German: http://forum.gleitz.info/showthread.php?t=36603
English (Google translation): http://translate.google.com/translate?u=http%3A%2F%2Fforum.gleitz.info%2Fshowthread.php%3Ft%3D36603&hl=de&ie=UTF8&sl=de&tl=en
If the translation is too crappy, you can read up on the methodology here: http://forum.doom9.org/showthread.php?t=125772
Note that I measured efficiency (= size difference at constant quantizer), not visual quality. I have half a mind to redo the test with something like a »HQ slow profile« CRF equivalent, but I doubt the results would change significantly.

To summarize: Mod16 was best, closely followed by mod16-2. All others (mod16-4, mod16+4, mod8, mod16+2) were somewhat worse but couldn’t be ranked clearly. Also overall efficiency decrease was small, probably nothing to worry about in anything but a heavily compressed 1-CD-like scenario.

So it seems you don’t need to worry about non-mod16 quality in anything but very special circumstances. That leaves possible playback compatibility problems as the only issue.

[Seraphic-]

Back in January I did a test:
German: http://forum.gleitz.info/showthread.php?t=36603
English (Google translation): http://translate.google.com/translate?u=http%3A%2F%2Fforum.gleitz.info%2Fshowthread.php%3Ft%3D36603&hl=de&ie=UTF8&sl=de&tl=en
If the translation is too crappy, you can read up on the methodology here: http://forum.doom9.org/showthread.php?t=125772
Note that I measured efficiency (= size difference at constant quantizer), not visual quality. I have half a mind to redo the test with something like a »HQ slow profile« CRF equivalent, but I doubt the results would change significantly.

To summarize: Mod16 was best, closely followed by mod16-2. All others (mod16-4, mod16+4, mod8, mod16+2) were somewhat worse but couldn’t be ranked clearly. Also overall efficiency decrease was small, probably nothing to worry about in anything but a heavily compressed 1-CD-like scenario.

So it seems you don’t need to worry about non-mod16 quality in anything but very special circumstances. That leaves possible playback compatibility problems as the only issue.

What do you mean by mod16-2? Is that 16 - 2 = mod14?

[Underground78]

I think that mod16-2 is for example 718, 720 is mod16 and 720 - 2 = 718 but 718 isn't mod14 ...

[Brother John]

Underground78 has it right. Mod16-2 means a mod16 number minus 2 pixels, e.g. 720-2=718, which is actually mod2. Same for all the others. Don’t ask me why I never tested mod16+6 and mod16-6. I don’t remember.

[Seraphic-]

You wanna compare resolution to file size, you gotta use CRF or CQ mode. Target bitrate means target bitrate, regardless of resolution. ;)

So if I was to use say HQ-Slowest set to Automated 3pass with a target bit-rate of 10,000. both 1276x716 and 1280x720 would have the same picture quality?

Underground78 has it right. Mod16-2 means a mod16 number minus 2 pixels, e.g. 720-2=718, which is actually mod2. Same for all the others. Don’t ask me why I never tested mod16+6 and mod16-6. I don’t remember.

Ah, I see what you mean now.

Well, in the case of these five 1280x720p videos that I'm working with, I do only need to crop 2 pixels from the right and 2 from the bottom, making it 1278x718.
However, since from what I understand mod2 is not recommended, I added a crop of 2 to the left and a crop from 2 to the top making it 1276x716 and mod4.

I think it was been already posted that mod4 is okay to use, but it is okay to use mod2 for PC playback only or not?

Edit: A mod2 crop won't even work with MeGUI (1278x718). If I try it, it just returns an error. Changing it to mod4 crop will allow the file to encode (1276x716).

[Brother John]

both 1276x716 and 1280x720 would have the same picture quality?
For all practical puposes: yes.

A mod2 crop won't even work with MeGUI (1278x718).
AviSynth forces mod4×mod2, that’s probably the reason with MeGUI.

[Comatose]

Well 1276x716 will come out the file same size as 1280x720 because 1276x716 will be padded up to 1280x720 (depends on what was cropped though). If using a constant quality mode, so you tell x264 to achieve this quality, then how it it going to end up with lower quality?
In that case, it would be "higher bitrate at the same quality."