Could MPEG2 be losslessly put into H.264 without complex encoding?

[Sleepysonic]

My two questions are:

1. Whether it should be possible.
and
2. Whether it already is possible.

Many devices now support H.264 but not MPEG2, web browsers in particular.
It would be nice if there was a way to losslessly put MPEG2 into a H.264 stream without much/any increase in file size and without complex cpu operations.
Can H.264 handle everything that MPEG2 does within the same parameters?

Even if I use intel quicksync, or the 'superfast' x264 option at the same bitrate, it is still going to require hefty of cpu usage, especially if doing a lot at once.
My specific usage in mind, is low (but high) bitrate DVB-T MPEG2 files, which already have a lot of pixelation. The pixelation probably wouldn't compress well at any bitrate, so lossless is really ideal.

I would like to be able to convert 15 MPEG-2 DVB-T streams on-the-fly to H.264, without needing a hefty computer to do so. Compressing isn't needed, just compatibility with H.264.

[Asmodian]

No, it is not possible.

[Sleepysonic]

What are some of the compression features/settings that only MPEG2 is able to do, which H.264 doesn't have the capability?

[Asmodian]

What are some of the compression features/settings that only MPEG2 is able to do, which H.264 doesn't have the capability?

It isn't as simple as you seem to think. This is like asking someone to "do something" to a german book so an english speaker can understand it, but without translating it.

[Sleepysonic]

It isn't as simple as you seem to think. This is like asking someone to "do something" to a german book so an english speaker can understand it, but without translating it.

But I'm asking about WITH translation.

I want a program to look at the MPEG2, and then translate to H.264, without needing to use any of the efficiency features of H.264. This would make it extremely fast as it doesn't have to 'think' but just 'do'.

If it can follow the same p-frame/b-frame movements, and blow up the macroblocks or whatever to the same in-efficent mpeg2 sizes, and still has the dumber-algorithms necessary to show a mpeg-2 intra-frame, then this should be possible right?

Obviously it can't just be placed into a H.264 instantly, but something could be theoretically made to do this extremely fast if H.264 has all the capabilities of MPEG-2, right?

In which case, there would also be little-to-no reason not to convert DVD's to H.264, because it would literally be lossless and pretty much the same size.

[Asmodian]

There might be bits of the information that you could use without completely decoding to the spacial domain, such as Converting DCT Coefficients to H.264/AVC (https://ai2-s2-pdfs.s3.amazonaws.com/a5e4/c0ed0e57472673bab1097edc55ddfe528acb.pdf). I have never seen anyone do anything with it. They really are a lot more different than you think.

"Capabilities" and "does it exactly the same way" are very different concepts. Translating is decoding to raw YUV 4:2:0 video and encoding in the new format. :)

[pandy]

Definitely it is possible, motion vectors information can be converted without any loss, frequency domain i can imagine also very accurate conversion. Such file will be suboptimal from H.264 perspective (as MPEG-2 is limited in usable tools when compared to H.264).
Lossless conversion should be possible - there is only one problem - IMHO such tool not exist (as commercial solution - there is no open source solution for sure).

[FancyMouse]

Definitely it is possible, motion vectors information can be converted without any loss, frequency domain i can imagine also very accurate conversion. Such file will be suboptimal from H.264 perspective (as MPEG-2 is limited in usable tools when compared to H.264).
Lossless conversion should be possible - there is only one problem - IMHO such tool not exist (as commercial solution - there is no open source solution for sure).

You probably overlooked that, apart from a lot of stuff that can be losslessly converted, these following processes have to exactly match:
1. transform/quantize procedure
2. predictions (intra modes, how to interpolate half pel mv, how to handle edge cases, etc.)

And I'm afraid the first one is already making it impossible (from what I searched there's already difference for this procedure between mpeg2 and h263) (oh, and in the paper cited before - see authors said integer approximation of DCT-to-HT? so probably even without quantization, the transform itself isn't losslessly convertible in integers already).

[pandy]

You probably overlooked that, apart from a lot of stuff that can be losslessly converted, these following processes have to exactly match:
1. transform/quantize procedure
2. predictions (intra modes, how to interpolate half pel mv, how to handle edge cases, etc.)

And I'm afraid the first one is already making it impossible (from what I searched there's already difference for this procedure between mpeg2 and h263) (oh, and in the paper cited before - see authors said integer approximation of DCT-to-HT? so probably even without quantization, the transform itself isn't losslessly convertible in integers already).

Ok, first area is to not quantize uniform signal representation (i.e. stay within 0..1 not 0..255), secondly - motion precision in H.264 was extended when compared to H.262 but you can still use half PEL precision in H.264.
H.264 use anyway integer transformation as such float DCT representation need to be transposed.

I never wrote that this is easy process but for sure information can be reused during H.262 -> H.264 conversion.

[benwaggoner]

Ok, first area is to not quantize uniform signal representation (i.e. stay within 0..1 not 0..255), secondly - motion precision in H.264 was extended when compared to H.262 but you can still use half PEL precision in H.264.
H.264 use anyway integer transformation as such float DCT representation need to be transposed.

I never wrote that this is easy process but for sure information can be reused during H.262 -> H.264 conversion.
We looked at this back at Microsoft for MPEG-2 to VC-1 conversion. Which in some ways could have been a bit easier than to H.264, but suffered from the same iDCT difference.

After a bunch of experimentation, reuse of the H.262 data allowed for faster transcoding, but not better quality. A hybrid approach of reusing some of the data but allowing new features (quarter-pel, for example) probably would have been optimal. But in the end, the #1 way to make for a better transcode from MPEG-2 was to use a smart autodeblocking MPEG-2 decoder that used the 262 data to reconstruct better output frames and then do a fresh encode from those.

[pandy]

We looked at this back at Microsoft for MPEG-2 to VC-1 conversion. Which in some ways could have been a bit easier than to H.264, but suffered from the same iDCT difference.

After a bunch of experimentation, reuse of the H.262 data allowed for faster transcoding, but not better quality. A hybrid approach of reusing some of the data but allowing new features (quarter-pel, for example) probably would have been optimal. But in the end, the #1 way to make for a better transcode from MPEG-2 was to use a smart autodeblocking MPEG-2 decoder that used the 262 data to reconstruct better output frames and then do a fresh encode from those.

I agree - old codecs with simpler tools will prevent fully use new tools from newer codec and as such conversion perhaps will be faster but results suboptimal... and usually this is not only about new codec but also adding additional processing to improve overall quality (deringing, demosquito etc).