Lossless encoding without increasing size

[Megafox]

Is there a way to re-encode video in lossless mode without getting a fivefold increase in size? I know that the problem is that codec thinks that the video is without artifacts of compression, and does not ignore them, so they began to occupy 4/5 the size of the video. But is there any h264/h265 codec that could find all the artifacts and how they were formed to simplify their encoding? My x264 settings were able to reduce video size by only 400 kb (it was 6.1 mb, it became 5.59 mb), despite fact that the original weighs only 1.5 mb in 2 seconds. If codec can not be configured for such a slow work, then I assume it can be done differently: all that I changed in video is to match fields and delete duplicates, I can import old and new id of each frame, which was not deleted using a script, into a text file, and then a special codec through this file will read original mpeg-2 file, and check how these frames are coded, finding artefacts of compression. After that applies all changes to fields/frames, and increases overall compression of video to its capabilities (h264 is more efficient than mpeg2). After such a slow and complex operation, size should not only approach the original, but become smaller. Is there anything you can do about it? Or am I mistaken and I will have to spoil quality of video?

[Hoser Rob]

No, you seem to think these codecs are capable of much more than they actually are.

[poisondeathray]

Is there a way to re-encode video in lossless mode without getting a fivefold increase in size? I know that the problem is that codec thinks that the video is without artifacts of compression, and does not ignore them, so they began to occupy 4/5 the size of the video. But is there any h264/h265 codec that could find all the artifacts and how they were formed to simplify their encoding? My x264 settings were able to reduce video size by only 400 kb (it was 6.1 mb, it became 5.59 mb), despite fact that the original weighs only 1.5 mb in 2 seconds. If codec can not be configured for such a slow work, then I assume it can be done differently: all that I changed in video is to match fields and delete duplicates, I can import old and new id of each frame, which was not deleted using a script, into a text file, and then a special codec through this file will read original mpeg-2 file, and check how these frames are coded, finding artefacts of compression. After that applies all changes to fields/frames, and increases overall compression of video to its capabilities (h264 is more efficient than mpeg2). After such a slow and complex operation, size should not only approach the original, but become smaller. Is there anything you can do about it? Or am I mistaken and I will have to spoil quality of video?

No

When you re-encode something, it gets decoded to uncompressed data first, then re-compressed . The "lossless" compression refers to the decoded, uncompressed state . You lose everything about the original compression characteristics and decisions when it's decoded . If you're complaining about 5x increase in size, it's actually much larger if you compare to the uncompressed state.

Lossy compression means you lose something. Bits are discarded, forever lost. The MPEG2 is lossy compared to it's original. You don't have the actual original master (the version before the MPEG2) .

[Megafox]

Is there a way to re-encode video in lossless mode without getting a fivefold increase in size? I know that the problem is that codec thinks that the video is without artifacts of compression, and does not ignore them, so they began to occupy 4/5 the size of the video. But is there any h264/h265 codec that could find all the artifacts and how they were formed to simplify their encoding? My x264 settings were able to reduce video size by only 400 kb (it was 6.1 mb, it became 5.59 mb), despite fact that the original weighs only 1.5 mb in 2 seconds. If codec can not be configured for such a slow work, then I assume it can be done differently: all that I changed in video is to match fields and delete duplicates, I can import old and new id of each frame, which was not deleted using a script, into a text file, and then a special codec through this file will read original mpeg-2 file, and check how these frames are coded, finding artefacts of compression. After that applies all changes to fields/frames, and increases overall compression of video to its capabilities (h264 is more efficient than mpeg2). After such a slow and complex operation, size should not only approach the original, but become smaller. Is there anything you can do about it? Or am I mistaken and I will have to spoil quality of video?

No

When you re-encode something, it gets decoded to uncompressed data first, then re-compressed . The "lossless" compression refers to the decoded, uncompressed state . You lose everything about the original compression characteristics and decisions when it's decoded . If you're complaining about 5x increase in size, it's actually much larger if you compare to the uncompressed state.

Lossy compression means you lose something. Bits are discarded, forever lost. The MPEG2 is lossy compared to it's original. You don't have the actual original master (the version before the MPEG2) .

Is it possible to somehow do without decoding and immediately encode MPEG-4 over MPEG-2? And tell codec what frames/fields have moved to where. Because, if the video could compress to 1.5 with this quality, then this should be possible, but difficult. I need a codec that can work with the old one, take information from it. Then he will know where these compression artifacts and video will be of normal size.
Because there are also programs, that cut the video without re-encoding. It's same here, only first mpeg2 is converted to mpeg4, in same encoded form, based on the old data, and then these frames are added to stream in a certain order.

[_Al_]

The way encoding works, you store references for frames. You cannot reconstruct a frame without knowing the codec and decompressing it first.

[Megafox]

The way encoding works, you store references for frames. You cannot reconstruct a frame without knowing the codec and decompressing it first.

If there was a multi-codec that can read mpeg2 and immediately encode mpeg4 based on this information, then everything would work out. I'm talking about information about discarded parts.

[Bernix]

Best way you can get is lossless H.264 codec. But size will be enormous. Lossless compression means to keep even unwanted artifacts. To use some filters, you can get rid of them, but there is no way to get pixel pixel same video other than using lossless codec. Or option lossless in codecs that supports LL compression. So you can get rid of artifacts, and get smaller size but it will lost for example artifacts information = No lossless.


Edit If you set same bitrate as original video has (MPEG2) for H264 2pass with some insane option, you can get very near, but never lossless.



Bernix

[Cornucopia]

The way encoding works, you store references for frames. You cannot reconstruct a frame without knowing the codec and decompressing it first.

If there was a multi-codec that can read mpeg2 and immediately encode mpeg4 based on this information, then everything would work out. I'm talking about information about discarded parts.

If the strategy & syntax of later codecs (h264 & h265, etc) were complete supersets of earlier codecs (mpeg1, mpeg2...) AND if a dct-transform-level transcoding app were aware of parameters of all syntaxes and their translation, AND if it were possible to transform the transform without loss, then a system might could be built that ONLY incurred the loss of the additional transform (never zero). But that's just theoretical and a whole lot of IFs. Nothing like this has ever been built, and it is such a large task with few uses (except something like yours, which could be considered a cheap, consumerist way to cheat the system) that there is basically no likelihood of it ever getting built. Certainly not cheaply. And that's not even saying that there is a good possibility that existing methods of fully decoding and fully re-encoding don't give you the same efficiency and same loss...

Scott

[_Al_]

The way encoding works, you store references for frames. You cannot reconstruct a frame without knowing the codec and decompressing it first.

If there was a multi-codec that can read mpeg2 and immediately encode mpeg4 based on this information, then everything would work out. I'm talking about information about discarded parts.

Do you mean to store sequences of algorithms that were used for encoding and then reversing these to have original?

That would perhaps violate some law of thermodynamics at some point. Information itself and something extra like instructions might have less than you started with.

[Bernix]

Sorry if I don't understand. Are you talking about procedure, that on ordinary PC can last say 3-4 day for 20min video? If implemented?
Edit: _Al_ yes some reverse engeneering probably I don't know if is it real name for this thing

Bernix

[Eric-jan]

Audio has lossless codecs, video has much more bandwith, and needs also to be fast in coding and decoding, ProRes422 is a visual lossless codec