MPEG compression question

[Katie Boundary]

Do MPEG-based codecs compare two consecutive un-encoded frames during encoding, record the changes, and try to apply them to the last encoded frame during decoding? Or do they look at the differences between the previous encoded frame and the current un-encoded frame, and record those? The latter solution is the smart one, but I've seen artifacts that can only be explained if the former was true.

[sneaker_ger]

It's not specified how an encoder must create the bitstream, only that the bitstream must be spec compliant. Since the decoder can only access the encoded frames the encoder can only really store the differences between them. Of course not necessarily only from the predecessor of the current frame, codecs are more complicated nowadays (e.g. b frames).

[filler56789]

FWIW, P-frames and B-frames may get *worse* quality (I mean, higher quantization) than the I-frames. Depending on the scene complexity && the bitrate constraints, then, some artifacts will be inevitable, regardless of how "smart" the encoder was designed to be.

[Katie Boundary]

It's not specified how an encoder must create the bitstream, only that the bitstream must be spec compliant. Since the decoder can only access the encoded frames the encoder can only really store the differences between them.

Let me rephrase. Will the codec try to take the differences between two uncompressed frames, and apply those differences to a compressed frame to get the next compressed frame? And is this why certain spatial artifacts will persist in still parts of an image instead of being detected as movement and cleaned up?

[wonkey_monkey]

The encoder should take into account the fact that the decoder will only be working with compressed frames. If it fails to do this, then yes, it may cause artefacts to remain because, as far as it is concerned, no change has taken place or needs to be encoded.

sneaker_ger's point is that the MPEG standards don't define how an encoder encodes, they only specify what kind of input the decoder expects to receive, so we can't say what any particular, or all, MPEG encoder(s) may or may not do.

There could be other reasons for whatever you're seeing, of course, but since you probably won't provide a sample we may never find out.

[StainlessS]

Where whatever frames may have been encoded so far, (before or following), then the encoder has to still target the un-encoded frame, relative to the 'so-far-encoded' frames, otherwise,
what's to point of life, the universe or anything.