Why isn't cropping an embedded function in the encoder?

[bot]

Why isn't cropping an embedded function in the encoder?
Is it a question of purism, or is there a more practical reason why?

[Kedirekin]

In some sense, it is a matter of purism.


How strange - I remember typing more than what shows above when I first posted this.

In another sense, cropping is just not part of what an encoder does. You can certainly tack a cropping feature on to encoding software, but it doesn't really become an embedded function of the encoder, merely an add on. It's like welding a screw driver onto a hammer - now the hammer is able to drive screws, but the screw driver isn't an embedded function of the hammer (i.e. your not driving a screw while you're hammering, or visa-versa).

And if you're going to add features to the encoding software, why limit it to just cropping? Why not resizing and filtering and what have you? Now your hammer is starting to look awfully strange, and it's maybe not so good as a hammer any more (too bloated with non-hammer functions).

[Cyberman]

Why should it, anyway? The codec´s supposed to EN or DEcode the data. For editing/cropping I´d use a video editor.

[bot]

Originally posted by Cyberman
Why should it, anyway? The codec´s supposed to EN or DEcode the data. For editing/cropping I´d use a video editor.


It's supposed to enCOde and DECode the information. There is no information in the black borders. Hence the notion of built in cropping in the codec.
It does not necessarily has to be faster than using a crop filter in vdub, but I wouldn't be surprised if it was.


@Kedirekin
Although resizing and noise filtering affects the amount of data to be encoded, they affect the data itself in a way that cropping does not. Cropping is merely a way to remove redundancy in the signal, which is very much the same as what the encoder tries to do.

[Kedirekin]

Good point. It certainly seems efficient to crop away any blackness to avoid having to encode it, then simply place indicators in the stream to tell how much black border to add back when decoding.

To play devil's advocate, I think you'd find that the bandwidth required to encode perfect blackness (ignoring the constraints imposed by the codec - macroblock constaints for example - which would be present in either case) are almost negligible. There are no motion vectors, and the DCT coefficients all go to zero. You might only be talking about a couple of dozen bytes per frame.

On top of that (continuing to play advocate), there aren't many situations where you need to preserve the black border at all. You certainly don't need to preserve it for any PC codec (divx for example). Letterboxing on DVD (or VCD/SVCD) is about the only situation I can think of where you absolutely must preserve a black border.

It might be that it isn't worth the hassle to encorporate this type of crop border/add border detail into a codec's specification, let alone the implementation.

[bot]

Aah, I see. Thank you! I thought it used up more space. And I was thinking about the increasing number of hardware decoders (and guessing that borders would be important for them).

In a completely unscientific test, I encoded 33 seconds twice from Moulin Rouge (without sound), using VP61 one pass good quality fast encoding @ 135kB/s.
The first time with the null filter to crop the borders, the second time without cropping. The results were interesting.

Null+Crop - about 2 minutes encoding and 4.85MB
Uncropped - about 3 minutes encoding and 4.81MB

Encoding the black borders gave a smaller file size (in this case, I should add).


Edit:
Gspot says,
Null+Crop - 1178 kb/s + 0.188 bits/pixel
Uncropped - 1168kb/s + 0.141 bits/pixel

If it's correct to subtract the percentage of border and difference in bitrate, the bits/pixel of the signal are identical in both cases.

[Cyberman]

Ah - right, I didn´t think of the black borders.
Isn´t the reason for eliminating the black borders that they produce a sharp line, which lossy codecs can´t handle? So, I think if the borders are multiples of 16, there shouldn´t be a problem - but if they aren´t - well, I once tried to encode an interlaced video(without telling the codec it was interlaced, of course) - the result wasn´t nice...