Can compressed videos be decoded back to their uncompresed original format?
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ height:90px;width:728px;box-sizing:border-box;
}
The following is mentioned in the ffmpeg documentation.
ffmpeg calls the libavformat library (containing demuxers) to read
input files and get packets containing encoded data from them...
Encoded packets are then passed to the decoder... The decoder produces
uncompressed frames (raw video/PCM audio/...) which can be processed
further by filtering...
Does that mean that you can always extract the original large size videos from all the compressed formats/codecs like h.264?
video ffmpeg compression
add a comment |
The following is mentioned in the ffmpeg documentation.
ffmpeg calls the libavformat library (containing demuxers) to read
input files and get packets containing encoded data from them...
Encoded packets are then passed to the decoder... The decoder produces
uncompressed frames (raw video/PCM audio/...) which can be processed
further by filtering...
Does that mean that you can always extract the original large size videos from all the compressed formats/codecs like h.264?
video ffmpeg compression
17
uncompressed != original
– Bergi
Apr 2 at 20:00
Yeah, and the question is about reversing the uncompressed to it's original; which has been explained and discussed in the answers.
– mjustin
Apr 3 at 3:36
2
Aside from the technically oriented answers, a legally oriented person (a lawyer or judge or possibly the owner of the intellectual property) will, most probably, insist that the decompressed video is, in a nutshell, still the original work (even if it's copied at a much lower resolution/quality, for example).
– Klaws
Apr 3 at 16:01
@Klaws It logically makes sense. But anyway, one cannot legitimately redistribute the video/audio in an opensource format unless the original allows it to be converted or redistributed; as far as I know.
– mjustin
Apr 3 at 18:30
add a comment |
The following is mentioned in the ffmpeg documentation.
ffmpeg calls the libavformat library (containing demuxers) to read
input files and get packets containing encoded data from them...
Encoded packets are then passed to the decoder... The decoder produces
uncompressed frames (raw video/PCM audio/...) which can be processed
further by filtering...
Does that mean that you can always extract the original large size videos from all the compressed formats/codecs like h.264?
video ffmpeg compression
The following is mentioned in the ffmpeg documentation.
ffmpeg calls the libavformat library (containing demuxers) to read
input files and get packets containing encoded data from them...
Encoded packets are then passed to the decoder... The decoder produces
uncompressed frames (raw video/PCM audio/...) which can be processed
further by filtering...
Does that mean that you can always extract the original large size videos from all the compressed formats/codecs like h.264?
video ffmpeg compression
video ffmpeg compression
edited Apr 3 at 12:51
mjustin
asked Apr 2 at 10:10
mjustinmjustin
8715
8715
17
uncompressed != original
– Bergi
Apr 2 at 20:00
Yeah, and the question is about reversing the uncompressed to it's original; which has been explained and discussed in the answers.
– mjustin
Apr 3 at 3:36
2
Aside from the technically oriented answers, a legally oriented person (a lawyer or judge or possibly the owner of the intellectual property) will, most probably, insist that the decompressed video is, in a nutshell, still the original work (even if it's copied at a much lower resolution/quality, for example).
– Klaws
Apr 3 at 16:01
@Klaws It logically makes sense. But anyway, one cannot legitimately redistribute the video/audio in an opensource format unless the original allows it to be converted or redistributed; as far as I know.
– mjustin
Apr 3 at 18:30
add a comment |
17
uncompressed != original
– Bergi
Apr 2 at 20:00
Yeah, and the question is about reversing the uncompressed to it's original; which has been explained and discussed in the answers.
– mjustin
Apr 3 at 3:36
2
Aside from the technically oriented answers, a legally oriented person (a lawyer or judge or possibly the owner of the intellectual property) will, most probably, insist that the decompressed video is, in a nutshell, still the original work (even if it's copied at a much lower resolution/quality, for example).
– Klaws
Apr 3 at 16:01
@Klaws It logically makes sense. But anyway, one cannot legitimately redistribute the video/audio in an opensource format unless the original allows it to be converted or redistributed; as far as I know.
– mjustin
Apr 3 at 18:30
17
17
uncompressed != original
– Bergi
Apr 2 at 20:00
uncompressed != original
– Bergi
Apr 2 at 20:00
Yeah, and the question is about reversing the uncompressed to it's original; which has been explained and discussed in the answers.
– mjustin
Apr 3 at 3:36
Yeah, and the question is about reversing the uncompressed to it's original; which has been explained and discussed in the answers.
– mjustin
Apr 3 at 3:36
2
2
Aside from the technically oriented answers, a legally oriented person (a lawyer or judge or possibly the owner of the intellectual property) will, most probably, insist that the decompressed video is, in a nutshell, still the original work (even if it's copied at a much lower resolution/quality, for example).
– Klaws
Apr 3 at 16:01
Aside from the technically oriented answers, a legally oriented person (a lawyer or judge or possibly the owner of the intellectual property) will, most probably, insist that the decompressed video is, in a nutshell, still the original work (even if it's copied at a much lower resolution/quality, for example).
– Klaws
Apr 3 at 16:01
@Klaws It logically makes sense. But anyway, one cannot legitimately redistribute the video/audio in an opensource format unless the original allows it to be converted or redistributed; as far as I know.
– mjustin
Apr 3 at 18:30
@Klaws It logically makes sense. But anyway, one cannot legitimately redistribute the video/audio in an opensource format unless the original allows it to be converted or redistributed; as far as I know.
– mjustin
Apr 3 at 18:30
add a comment |
4 Answers
4
active
oldest
votes
Video compression is typically "lossy", in contrast to "lossless".
This means that by compressing the data, and subsequently decompressing it, you end up with an approximation of the original that is (hopefully) acceptable for the purpose.
Storing images and video using lossy compression techniques is generally fine, because humans aren't very good at perceiving the detail in an image - for example, our brain can fill in lots of details from context alone (as our eyes only have a small area in the center that is of "high resolution"), and our eyes are more sensitive to the intensity of green than red or blue (which explains the allocation in RGB565).
So, when you say:
Does that mean that you can always extract the original large size videos from all the compressed formats like mp4?
You're asking one question, but leaving lots of openings for misinterpretation.
- Can we extract the original, pixel-perfect image from a video compressed using lossy techniques?
- No
- Can we extract a single frame of a video compressed using lossy techniques that has high quality, and could be used as a static image?
Probably not - movement in a scene will cause a higher number of artifacts, while a static scene will typically look better and better over time.
- Can we extract an image of the original size, that looks "reasonable" to a human?
Yes - for a given definition of "reasonable"
This imperfect resulting image will have "Compression Artifacts". As shown in the exaggerated examples below:
As the comments have also focused heavily on Audio quality, the exact same thing occurs. However, audio is a significantly lower bandwidth medium, which allows for lossless codecs to be practical (for example FLAC).
Converting from PCM / WAV → MP3 → PCM will result in an output PCM file that has the artifacts introduced by the MP3 encode/decode process - these cannot be removed.
Additionally, concatenating codecs will allow each to introduce their own artifacts, and the order that the codecs are applied can have a significant effect on the output.
Converting PCM → MP3 → OGG vorbis → Opus is not the same as PCM → Opus, because each of the intermediary codecs are lossy.
I've made an example audio file which presents this as another exaggerated example. This is the first ~30 seconds of "Tonight" by "The 69 Eyes", alternating every 5 seconds between the following chains:
- CD → FLAC → Opus
- CD → FLAC → MP3 → Vorbis → Opus
The effect here is dramatic, with the higher frequencies (i.e: high-hat) being almost completely removed from the audio, and with significant channel (left/right) interaction that is especially noticeable at the beginning.
Comments are not for extended discussion; this conversation has been moved to chat.
– DavidPostill♦
Apr 2 at 22:17
4
re: chaining lossy codecs: The easiest way to understand this is that artefacts introduced by the first lossy codec become part of the "details" that the 2nd codec has to spend bits accurately reproducing. Any post-processing (like h.264's in-loop deblocking filter), or feeding one codec to another code, will smear out the ringing / blocking so it doesn't just become easy-to-quantize input for the next codec. (Like might happen with simple jpg -> jpg -> jpg or other simple codecs where stability might be reached.)
– Peter Cordes
Apr 3 at 4:11
3
@opa US vs UK spelling differences do not merit editing.
– mbrig
Apr 3 at 20:14
add a comment |
A short answer for codecs in general:
Any lossless codec like FLAC or ZIP can be reversed exactly.
Any lossy codec like JPEG or MP3 cannot be reversed exactly.
This principle is also valid for video codecs.
Here HuffYUV
is an example for a lossless video-codec.
And x264
is an example for a lossy video-codec.
1
Very nicely put.
– mjustin
Apr 3 at 12:53
1
To nitpick, you are mixing up some codecs (an encoder/decoder) and formats (what a codec outputs, or more specifically what an encoder outputs). To add to the confusion sometimes they can share the same name, and people use the term "codec" loosely. JPEG and MP3 are formats. LAME is an encoder that outputs MP3. FLAC is a format, butffmpeg
has a FLAC encoder/decoder (codec) named flac. x264 is an encoder that produces the H.264 video format (and to top it off x264 can output both lossy and lossless H.264).
– llogan
Apr 3 at 19:05
@llogan: Thank you for your clarification, it is surely helpful.
– zx485
Apr 3 at 20:42
There is an interesting note to be made: h.264 does have a true lossless encoding setting[2]
[3]
. It is of course not very common to see it in use in the real world, though, as it doesn't make much sense for the vast majority of applications.
– Marc.2377
Apr 4 at 3:21
@Marc.2377: That's interesting, but as you said, it's an exception.
– zx485
Apr 4 at 21:37
add a comment |
Does that mean that you can always extract the original large size videos from all the compressed formats like mp4?
No. You're misinterpreting that sentence.
You can't display compressed image, just as you can't read compressed text or read file compressed with ZIP without unpacking it first. To display any image, you have to somehow represent it uncompressed in memory, pixel-for-pixel.
This doesn't imply that the uncompressed image will be identical to original - this depends on codecs used. As far as I know there are no commonly used lossless codecs. Lossy codecs aim to represent original closely enough to make the uncompressed video indistinguishable under normal circumstances, ie. when played at predicted resolution and framerate. When looking at compressed stills (ie. framerate=0) you will certainly see artifacts, unless bitrate during compression is set impractically high (ie. producing too large output files) (this answer of mine is somehow related).
By the way, MP4 is only a file format, ie. it tells you how compressed data is stored in a file, but doesn't determine how it was compressed. MP4 can work with a variety of codecs. H.264 is probably the most popular video codec used with MP4, but don't quote me on that. Audio is usually compressed with AAC, I guess.
@Attie Now bold "original"
– Lightness Races in Orbit
Apr 3 at 9:41
1
@Attie I'm interpreting "original", "large size" in OP's question as "lossless"
– gronostaj
Apr 3 at 9:45
Well, I get to understand that if the compression is lossless and is the first transcoding from the original (not concatenated), you can always decode and encode it back to the original pixel by pixel video, but not from a lossy format.
– mjustin
Apr 3 at 12:30
@mjustin Exactly. What they mean is that decoder produces some uncompressed frames, not necessarily identical to original.
– gronostaj
Apr 3 at 12:37
@gronostaj But if the decoder is decoding from an uncompressed lossless format, then the result should be identical to the original ones, pixel by pixel. That's what I understood.
– mjustin
Apr 3 at 12:43
|
show 1 more comment
This is a very common blunder.
You can convert from a lossy format to a lossless format, but the damage is done.
The lossless output file will show all the damage (compromised details, added artifacts) that are the reason you don't like the lossy format. You can't get that back.
The only option is to contact the publisher and see if he still has the original lossless files, and would be willing to somehow upload them to you.
There's no such thing as an Enhance button. warning: TVtropes
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "3"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1420358%2fcan-compressed-videos-be-decoded-back-to-their-uncompresed-original-format%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
4 Answers
4
active
oldest
votes
4 Answers
4
active
oldest
votes
active
oldest
votes
active
oldest
votes
Video compression is typically "lossy", in contrast to "lossless".
This means that by compressing the data, and subsequently decompressing it, you end up with an approximation of the original that is (hopefully) acceptable for the purpose.
Storing images and video using lossy compression techniques is generally fine, because humans aren't very good at perceiving the detail in an image - for example, our brain can fill in lots of details from context alone (as our eyes only have a small area in the center that is of "high resolution"), and our eyes are more sensitive to the intensity of green than red or blue (which explains the allocation in RGB565).
So, when you say:
Does that mean that you can always extract the original large size videos from all the compressed formats like mp4?
You're asking one question, but leaving lots of openings for misinterpretation.
- Can we extract the original, pixel-perfect image from a video compressed using lossy techniques?
- No
- Can we extract a single frame of a video compressed using lossy techniques that has high quality, and could be used as a static image?
Probably not - movement in a scene will cause a higher number of artifacts, while a static scene will typically look better and better over time.
- Can we extract an image of the original size, that looks "reasonable" to a human?
Yes - for a given definition of "reasonable"
This imperfect resulting image will have "Compression Artifacts". As shown in the exaggerated examples below:
As the comments have also focused heavily on Audio quality, the exact same thing occurs. However, audio is a significantly lower bandwidth medium, which allows for lossless codecs to be practical (for example FLAC).
Converting from PCM / WAV → MP3 → PCM will result in an output PCM file that has the artifacts introduced by the MP3 encode/decode process - these cannot be removed.
Additionally, concatenating codecs will allow each to introduce their own artifacts, and the order that the codecs are applied can have a significant effect on the output.
Converting PCM → MP3 → OGG vorbis → Opus is not the same as PCM → Opus, because each of the intermediary codecs are lossy.
I've made an example audio file which presents this as another exaggerated example. This is the first ~30 seconds of "Tonight" by "The 69 Eyes", alternating every 5 seconds between the following chains:
- CD → FLAC → Opus
- CD → FLAC → MP3 → Vorbis → Opus
The effect here is dramatic, with the higher frequencies (i.e: high-hat) being almost completely removed from the audio, and with significant channel (left/right) interaction that is especially noticeable at the beginning.
Comments are not for extended discussion; this conversation has been moved to chat.
– DavidPostill♦
Apr 2 at 22:17
4
re: chaining lossy codecs: The easiest way to understand this is that artefacts introduced by the first lossy codec become part of the "details" that the 2nd codec has to spend bits accurately reproducing. Any post-processing (like h.264's in-loop deblocking filter), or feeding one codec to another code, will smear out the ringing / blocking so it doesn't just become easy-to-quantize input for the next codec. (Like might happen with simple jpg -> jpg -> jpg or other simple codecs where stability might be reached.)
– Peter Cordes
Apr 3 at 4:11
3
@opa US vs UK spelling differences do not merit editing.
– mbrig
Apr 3 at 20:14
add a comment |
Video compression is typically "lossy", in contrast to "lossless".
This means that by compressing the data, and subsequently decompressing it, you end up with an approximation of the original that is (hopefully) acceptable for the purpose.
Storing images and video using lossy compression techniques is generally fine, because humans aren't very good at perceiving the detail in an image - for example, our brain can fill in lots of details from context alone (as our eyes only have a small area in the center that is of "high resolution"), and our eyes are more sensitive to the intensity of green than red or blue (which explains the allocation in RGB565).
So, when you say:
Does that mean that you can always extract the original large size videos from all the compressed formats like mp4?
You're asking one question, but leaving lots of openings for misinterpretation.
- Can we extract the original, pixel-perfect image from a video compressed using lossy techniques?
- No
- Can we extract a single frame of a video compressed using lossy techniques that has high quality, and could be used as a static image?
Probably not - movement in a scene will cause a higher number of artifacts, while a static scene will typically look better and better over time.
- Can we extract an image of the original size, that looks "reasonable" to a human?
Yes - for a given definition of "reasonable"
This imperfect resulting image will have "Compression Artifacts". As shown in the exaggerated examples below:
As the comments have also focused heavily on Audio quality, the exact same thing occurs. However, audio is a significantly lower bandwidth medium, which allows for lossless codecs to be practical (for example FLAC).
Converting from PCM / WAV → MP3 → PCM will result in an output PCM file that has the artifacts introduced by the MP3 encode/decode process - these cannot be removed.
Additionally, concatenating codecs will allow each to introduce their own artifacts, and the order that the codecs are applied can have a significant effect on the output.
Converting PCM → MP3 → OGG vorbis → Opus is not the same as PCM → Opus, because each of the intermediary codecs are lossy.
I've made an example audio file which presents this as another exaggerated example. This is the first ~30 seconds of "Tonight" by "The 69 Eyes", alternating every 5 seconds between the following chains:
- CD → FLAC → Opus
- CD → FLAC → MP3 → Vorbis → Opus
The effect here is dramatic, with the higher frequencies (i.e: high-hat) being almost completely removed from the audio, and with significant channel (left/right) interaction that is especially noticeable at the beginning.
Comments are not for extended discussion; this conversation has been moved to chat.
– DavidPostill♦
Apr 2 at 22:17
4
re: chaining lossy codecs: The easiest way to understand this is that artefacts introduced by the first lossy codec become part of the "details" that the 2nd codec has to spend bits accurately reproducing. Any post-processing (like h.264's in-loop deblocking filter), or feeding one codec to another code, will smear out the ringing / blocking so it doesn't just become easy-to-quantize input for the next codec. (Like might happen with simple jpg -> jpg -> jpg or other simple codecs where stability might be reached.)
– Peter Cordes
Apr 3 at 4:11
3
@opa US vs UK spelling differences do not merit editing.
– mbrig
Apr 3 at 20:14
add a comment |
Video compression is typically "lossy", in contrast to "lossless".
This means that by compressing the data, and subsequently decompressing it, you end up with an approximation of the original that is (hopefully) acceptable for the purpose.
Storing images and video using lossy compression techniques is generally fine, because humans aren't very good at perceiving the detail in an image - for example, our brain can fill in lots of details from context alone (as our eyes only have a small area in the center that is of "high resolution"), and our eyes are more sensitive to the intensity of green than red or blue (which explains the allocation in RGB565).
So, when you say:
Does that mean that you can always extract the original large size videos from all the compressed formats like mp4?
You're asking one question, but leaving lots of openings for misinterpretation.
- Can we extract the original, pixel-perfect image from a video compressed using lossy techniques?
- No
- Can we extract a single frame of a video compressed using lossy techniques that has high quality, and could be used as a static image?
Probably not - movement in a scene will cause a higher number of artifacts, while a static scene will typically look better and better over time.
- Can we extract an image of the original size, that looks "reasonable" to a human?
Yes - for a given definition of "reasonable"
This imperfect resulting image will have "Compression Artifacts". As shown in the exaggerated examples below:
As the comments have also focused heavily on Audio quality, the exact same thing occurs. However, audio is a significantly lower bandwidth medium, which allows for lossless codecs to be practical (for example FLAC).
Converting from PCM / WAV → MP3 → PCM will result in an output PCM file that has the artifacts introduced by the MP3 encode/decode process - these cannot be removed.
Additionally, concatenating codecs will allow each to introduce their own artifacts, and the order that the codecs are applied can have a significant effect on the output.
Converting PCM → MP3 → OGG vorbis → Opus is not the same as PCM → Opus, because each of the intermediary codecs are lossy.
I've made an example audio file which presents this as another exaggerated example. This is the first ~30 seconds of "Tonight" by "The 69 Eyes", alternating every 5 seconds between the following chains:
- CD → FLAC → Opus
- CD → FLAC → MP3 → Vorbis → Opus
The effect here is dramatic, with the higher frequencies (i.e: high-hat) being almost completely removed from the audio, and with significant channel (left/right) interaction that is especially noticeable at the beginning.
Video compression is typically "lossy", in contrast to "lossless".
This means that by compressing the data, and subsequently decompressing it, you end up with an approximation of the original that is (hopefully) acceptable for the purpose.
Storing images and video using lossy compression techniques is generally fine, because humans aren't very good at perceiving the detail in an image - for example, our brain can fill in lots of details from context alone (as our eyes only have a small area in the center that is of "high resolution"), and our eyes are more sensitive to the intensity of green than red or blue (which explains the allocation in RGB565).
So, when you say:
Does that mean that you can always extract the original large size videos from all the compressed formats like mp4?
You're asking one question, but leaving lots of openings for misinterpretation.
- Can we extract the original, pixel-perfect image from a video compressed using lossy techniques?
- No
- Can we extract a single frame of a video compressed using lossy techniques that has high quality, and could be used as a static image?
Probably not - movement in a scene will cause a higher number of artifacts, while a static scene will typically look better and better over time.
- Can we extract an image of the original size, that looks "reasonable" to a human?
Yes - for a given definition of "reasonable"
This imperfect resulting image will have "Compression Artifacts". As shown in the exaggerated examples below:
As the comments have also focused heavily on Audio quality, the exact same thing occurs. However, audio is a significantly lower bandwidth medium, which allows for lossless codecs to be practical (for example FLAC).
Converting from PCM / WAV → MP3 → PCM will result in an output PCM file that has the artifacts introduced by the MP3 encode/decode process - these cannot be removed.
Additionally, concatenating codecs will allow each to introduce their own artifacts, and the order that the codecs are applied can have a significant effect on the output.
Converting PCM → MP3 → OGG vorbis → Opus is not the same as PCM → Opus, because each of the intermediary codecs are lossy.
I've made an example audio file which presents this as another exaggerated example. This is the first ~30 seconds of "Tonight" by "The 69 Eyes", alternating every 5 seconds between the following chains:
- CD → FLAC → Opus
- CD → FLAC → MP3 → Vorbis → Opus
The effect here is dramatic, with the higher frequencies (i.e: high-hat) being almost completely removed from the audio, and with significant channel (left/right) interaction that is especially noticeable at the beginning.
edited Apr 3 at 18:37
Cody
1032
1032
answered Apr 2 at 11:01
AttieAttie
13.3k43648
13.3k43648
Comments are not for extended discussion; this conversation has been moved to chat.
– DavidPostill♦
Apr 2 at 22:17
4
re: chaining lossy codecs: The easiest way to understand this is that artefacts introduced by the first lossy codec become part of the "details" that the 2nd codec has to spend bits accurately reproducing. Any post-processing (like h.264's in-loop deblocking filter), or feeding one codec to another code, will smear out the ringing / blocking so it doesn't just become easy-to-quantize input for the next codec. (Like might happen with simple jpg -> jpg -> jpg or other simple codecs where stability might be reached.)
– Peter Cordes
Apr 3 at 4:11
3
@opa US vs UK spelling differences do not merit editing.
– mbrig
Apr 3 at 20:14
add a comment |
Comments are not for extended discussion; this conversation has been moved to chat.
– DavidPostill♦
Apr 2 at 22:17
4
re: chaining lossy codecs: The easiest way to understand this is that artefacts introduced by the first lossy codec become part of the "details" that the 2nd codec has to spend bits accurately reproducing. Any post-processing (like h.264's in-loop deblocking filter), or feeding one codec to another code, will smear out the ringing / blocking so it doesn't just become easy-to-quantize input for the next codec. (Like might happen with simple jpg -> jpg -> jpg or other simple codecs where stability might be reached.)
– Peter Cordes
Apr 3 at 4:11
3
@opa US vs UK spelling differences do not merit editing.
– mbrig
Apr 3 at 20:14
Comments are not for extended discussion; this conversation has been moved to chat.
– DavidPostill♦
Apr 2 at 22:17
Comments are not for extended discussion; this conversation has been moved to chat.
– DavidPostill♦
Apr 2 at 22:17
4
4
re: chaining lossy codecs: The easiest way to understand this is that artefacts introduced by the first lossy codec become part of the "details" that the 2nd codec has to spend bits accurately reproducing. Any post-processing (like h.264's in-loop deblocking filter), or feeding one codec to another code, will smear out the ringing / blocking so it doesn't just become easy-to-quantize input for the next codec. (Like might happen with simple jpg -> jpg -> jpg or other simple codecs where stability might be reached.)
– Peter Cordes
Apr 3 at 4:11
re: chaining lossy codecs: The easiest way to understand this is that artefacts introduced by the first lossy codec become part of the "details" that the 2nd codec has to spend bits accurately reproducing. Any post-processing (like h.264's in-loop deblocking filter), or feeding one codec to another code, will smear out the ringing / blocking so it doesn't just become easy-to-quantize input for the next codec. (Like might happen with simple jpg -> jpg -> jpg or other simple codecs where stability might be reached.)
– Peter Cordes
Apr 3 at 4:11
3
3
@opa US vs UK spelling differences do not merit editing.
– mbrig
Apr 3 at 20:14
@opa US vs UK spelling differences do not merit editing.
– mbrig
Apr 3 at 20:14
add a comment |
A short answer for codecs in general:
Any lossless codec like FLAC or ZIP can be reversed exactly.
Any lossy codec like JPEG or MP3 cannot be reversed exactly.
This principle is also valid for video codecs.
Here HuffYUV
is an example for a lossless video-codec.
And x264
is an example for a lossy video-codec.
1
Very nicely put.
– mjustin
Apr 3 at 12:53
1
To nitpick, you are mixing up some codecs (an encoder/decoder) and formats (what a codec outputs, or more specifically what an encoder outputs). To add to the confusion sometimes they can share the same name, and people use the term "codec" loosely. JPEG and MP3 are formats. LAME is an encoder that outputs MP3. FLAC is a format, butffmpeg
has a FLAC encoder/decoder (codec) named flac. x264 is an encoder that produces the H.264 video format (and to top it off x264 can output both lossy and lossless H.264).
– llogan
Apr 3 at 19:05
@llogan: Thank you for your clarification, it is surely helpful.
– zx485
Apr 3 at 20:42
There is an interesting note to be made: h.264 does have a true lossless encoding setting[2]
[3]
. It is of course not very common to see it in use in the real world, though, as it doesn't make much sense for the vast majority of applications.
– Marc.2377
Apr 4 at 3:21
@Marc.2377: That's interesting, but as you said, it's an exception.
– zx485
Apr 4 at 21:37
add a comment |
A short answer for codecs in general:
Any lossless codec like FLAC or ZIP can be reversed exactly.
Any lossy codec like JPEG or MP3 cannot be reversed exactly.
This principle is also valid for video codecs.
Here HuffYUV
is an example for a lossless video-codec.
And x264
is an example for a lossy video-codec.
1
Very nicely put.
– mjustin
Apr 3 at 12:53
1
To nitpick, you are mixing up some codecs (an encoder/decoder) and formats (what a codec outputs, or more specifically what an encoder outputs). To add to the confusion sometimes they can share the same name, and people use the term "codec" loosely. JPEG and MP3 are formats. LAME is an encoder that outputs MP3. FLAC is a format, butffmpeg
has a FLAC encoder/decoder (codec) named flac. x264 is an encoder that produces the H.264 video format (and to top it off x264 can output both lossy and lossless H.264).
– llogan
Apr 3 at 19:05
@llogan: Thank you for your clarification, it is surely helpful.
– zx485
Apr 3 at 20:42
There is an interesting note to be made: h.264 does have a true lossless encoding setting[2]
[3]
. It is of course not very common to see it in use in the real world, though, as it doesn't make much sense for the vast majority of applications.
– Marc.2377
Apr 4 at 3:21
@Marc.2377: That's interesting, but as you said, it's an exception.
– zx485
Apr 4 at 21:37
add a comment |
A short answer for codecs in general:
Any lossless codec like FLAC or ZIP can be reversed exactly.
Any lossy codec like JPEG or MP3 cannot be reversed exactly.
This principle is also valid for video codecs.
Here HuffYUV
is an example for a lossless video-codec.
And x264
is an example for a lossy video-codec.
A short answer for codecs in general:
Any lossless codec like FLAC or ZIP can be reversed exactly.
Any lossy codec like JPEG or MP3 cannot be reversed exactly.
This principle is also valid for video codecs.
Here HuffYUV
is an example for a lossless video-codec.
And x264
is an example for a lossy video-codec.
edited Apr 3 at 7:24
Solomon Ucko
1013
1013
answered Apr 2 at 22:08
zx485zx485
1,4132914
1,4132914
1
Very nicely put.
– mjustin
Apr 3 at 12:53
1
To nitpick, you are mixing up some codecs (an encoder/decoder) and formats (what a codec outputs, or more specifically what an encoder outputs). To add to the confusion sometimes they can share the same name, and people use the term "codec" loosely. JPEG and MP3 are formats. LAME is an encoder that outputs MP3. FLAC is a format, butffmpeg
has a FLAC encoder/decoder (codec) named flac. x264 is an encoder that produces the H.264 video format (and to top it off x264 can output both lossy and lossless H.264).
– llogan
Apr 3 at 19:05
@llogan: Thank you for your clarification, it is surely helpful.
– zx485
Apr 3 at 20:42
There is an interesting note to be made: h.264 does have a true lossless encoding setting[2]
[3]
. It is of course not very common to see it in use in the real world, though, as it doesn't make much sense for the vast majority of applications.
– Marc.2377
Apr 4 at 3:21
@Marc.2377: That's interesting, but as you said, it's an exception.
– zx485
Apr 4 at 21:37
add a comment |
1
Very nicely put.
– mjustin
Apr 3 at 12:53
1
To nitpick, you are mixing up some codecs (an encoder/decoder) and formats (what a codec outputs, or more specifically what an encoder outputs). To add to the confusion sometimes they can share the same name, and people use the term "codec" loosely. JPEG and MP3 are formats. LAME is an encoder that outputs MP3. FLAC is a format, butffmpeg
has a FLAC encoder/decoder (codec) named flac. x264 is an encoder that produces the H.264 video format (and to top it off x264 can output both lossy and lossless H.264).
– llogan
Apr 3 at 19:05
@llogan: Thank you for your clarification, it is surely helpful.
– zx485
Apr 3 at 20:42
There is an interesting note to be made: h.264 does have a true lossless encoding setting[2]
[3]
. It is of course not very common to see it in use in the real world, though, as it doesn't make much sense for the vast majority of applications.
– Marc.2377
Apr 4 at 3:21
@Marc.2377: That's interesting, but as you said, it's an exception.
– zx485
Apr 4 at 21:37
1
1
Very nicely put.
– mjustin
Apr 3 at 12:53
Very nicely put.
– mjustin
Apr 3 at 12:53
1
1
To nitpick, you are mixing up some codecs (an encoder/decoder) and formats (what a codec outputs, or more specifically what an encoder outputs). To add to the confusion sometimes they can share the same name, and people use the term "codec" loosely. JPEG and MP3 are formats. LAME is an encoder that outputs MP3. FLAC is a format, but
ffmpeg
has a FLAC encoder/decoder (codec) named flac. x264 is an encoder that produces the H.264 video format (and to top it off x264 can output both lossy and lossless H.264).– llogan
Apr 3 at 19:05
To nitpick, you are mixing up some codecs (an encoder/decoder) and formats (what a codec outputs, or more specifically what an encoder outputs). To add to the confusion sometimes they can share the same name, and people use the term "codec" loosely. JPEG and MP3 are formats. LAME is an encoder that outputs MP3. FLAC is a format, but
ffmpeg
has a FLAC encoder/decoder (codec) named flac. x264 is an encoder that produces the H.264 video format (and to top it off x264 can output both lossy and lossless H.264).– llogan
Apr 3 at 19:05
@llogan: Thank you for your clarification, it is surely helpful.
– zx485
Apr 3 at 20:42
@llogan: Thank you for your clarification, it is surely helpful.
– zx485
Apr 3 at 20:42
There is an interesting note to be made: h.264 does have a true lossless encoding setting
[2]
[3]
. It is of course not very common to see it in use in the real world, though, as it doesn't make much sense for the vast majority of applications.– Marc.2377
Apr 4 at 3:21
There is an interesting note to be made: h.264 does have a true lossless encoding setting
[2]
[3]
. It is of course not very common to see it in use in the real world, though, as it doesn't make much sense for the vast majority of applications.– Marc.2377
Apr 4 at 3:21
@Marc.2377: That's interesting, but as you said, it's an exception.
– zx485
Apr 4 at 21:37
@Marc.2377: That's interesting, but as you said, it's an exception.
– zx485
Apr 4 at 21:37
add a comment |
Does that mean that you can always extract the original large size videos from all the compressed formats like mp4?
No. You're misinterpreting that sentence.
You can't display compressed image, just as you can't read compressed text or read file compressed with ZIP without unpacking it first. To display any image, you have to somehow represent it uncompressed in memory, pixel-for-pixel.
This doesn't imply that the uncompressed image will be identical to original - this depends on codecs used. As far as I know there are no commonly used lossless codecs. Lossy codecs aim to represent original closely enough to make the uncompressed video indistinguishable under normal circumstances, ie. when played at predicted resolution and framerate. When looking at compressed stills (ie. framerate=0) you will certainly see artifacts, unless bitrate during compression is set impractically high (ie. producing too large output files) (this answer of mine is somehow related).
By the way, MP4 is only a file format, ie. it tells you how compressed data is stored in a file, but doesn't determine how it was compressed. MP4 can work with a variety of codecs. H.264 is probably the most popular video codec used with MP4, but don't quote me on that. Audio is usually compressed with AAC, I guess.
@Attie Now bold "original"
– Lightness Races in Orbit
Apr 3 at 9:41
1
@Attie I'm interpreting "original", "large size" in OP's question as "lossless"
– gronostaj
Apr 3 at 9:45
Well, I get to understand that if the compression is lossless and is the first transcoding from the original (not concatenated), you can always decode and encode it back to the original pixel by pixel video, but not from a lossy format.
– mjustin
Apr 3 at 12:30
@mjustin Exactly. What they mean is that decoder produces some uncompressed frames, not necessarily identical to original.
– gronostaj
Apr 3 at 12:37
@gronostaj But if the decoder is decoding from an uncompressed lossless format, then the result should be identical to the original ones, pixel by pixel. That's what I understood.
– mjustin
Apr 3 at 12:43
|
show 1 more comment
Does that mean that you can always extract the original large size videos from all the compressed formats like mp4?
No. You're misinterpreting that sentence.
You can't display compressed image, just as you can't read compressed text or read file compressed with ZIP without unpacking it first. To display any image, you have to somehow represent it uncompressed in memory, pixel-for-pixel.
This doesn't imply that the uncompressed image will be identical to original - this depends on codecs used. As far as I know there are no commonly used lossless codecs. Lossy codecs aim to represent original closely enough to make the uncompressed video indistinguishable under normal circumstances, ie. when played at predicted resolution and framerate. When looking at compressed stills (ie. framerate=0) you will certainly see artifacts, unless bitrate during compression is set impractically high (ie. producing too large output files) (this answer of mine is somehow related).
By the way, MP4 is only a file format, ie. it tells you how compressed data is stored in a file, but doesn't determine how it was compressed. MP4 can work with a variety of codecs. H.264 is probably the most popular video codec used with MP4, but don't quote me on that. Audio is usually compressed with AAC, I guess.
@Attie Now bold "original"
– Lightness Races in Orbit
Apr 3 at 9:41
1
@Attie I'm interpreting "original", "large size" in OP's question as "lossless"
– gronostaj
Apr 3 at 9:45
Well, I get to understand that if the compression is lossless and is the first transcoding from the original (not concatenated), you can always decode and encode it back to the original pixel by pixel video, but not from a lossy format.
– mjustin
Apr 3 at 12:30
@mjustin Exactly. What they mean is that decoder produces some uncompressed frames, not necessarily identical to original.
– gronostaj
Apr 3 at 12:37
@gronostaj But if the decoder is decoding from an uncompressed lossless format, then the result should be identical to the original ones, pixel by pixel. That's what I understood.
– mjustin
Apr 3 at 12:43
|
show 1 more comment
Does that mean that you can always extract the original large size videos from all the compressed formats like mp4?
No. You're misinterpreting that sentence.
You can't display compressed image, just as you can't read compressed text or read file compressed with ZIP without unpacking it first. To display any image, you have to somehow represent it uncompressed in memory, pixel-for-pixel.
This doesn't imply that the uncompressed image will be identical to original - this depends on codecs used. As far as I know there are no commonly used lossless codecs. Lossy codecs aim to represent original closely enough to make the uncompressed video indistinguishable under normal circumstances, ie. when played at predicted resolution and framerate. When looking at compressed stills (ie. framerate=0) you will certainly see artifacts, unless bitrate during compression is set impractically high (ie. producing too large output files) (this answer of mine is somehow related).
By the way, MP4 is only a file format, ie. it tells you how compressed data is stored in a file, but doesn't determine how it was compressed. MP4 can work with a variety of codecs. H.264 is probably the most popular video codec used with MP4, but don't quote me on that. Audio is usually compressed with AAC, I guess.
Does that mean that you can always extract the original large size videos from all the compressed formats like mp4?
No. You're misinterpreting that sentence.
You can't display compressed image, just as you can't read compressed text or read file compressed with ZIP without unpacking it first. To display any image, you have to somehow represent it uncompressed in memory, pixel-for-pixel.
This doesn't imply that the uncompressed image will be identical to original - this depends on codecs used. As far as I know there are no commonly used lossless codecs. Lossy codecs aim to represent original closely enough to make the uncompressed video indistinguishable under normal circumstances, ie. when played at predicted resolution and framerate. When looking at compressed stills (ie. framerate=0) you will certainly see artifacts, unless bitrate during compression is set impractically high (ie. producing too large output files) (this answer of mine is somehow related).
By the way, MP4 is only a file format, ie. it tells you how compressed data is stored in a file, but doesn't determine how it was compressed. MP4 can work with a variety of codecs. H.264 is probably the most popular video codec used with MP4, but don't quote me on that. Audio is usually compressed with AAC, I guess.
edited Apr 3 at 9:47
answered Apr 3 at 9:21
gronostajgronostaj
29.3k1472108
29.3k1472108
@Attie Now bold "original"
– Lightness Races in Orbit
Apr 3 at 9:41
1
@Attie I'm interpreting "original", "large size" in OP's question as "lossless"
– gronostaj
Apr 3 at 9:45
Well, I get to understand that if the compression is lossless and is the first transcoding from the original (not concatenated), you can always decode and encode it back to the original pixel by pixel video, but not from a lossy format.
– mjustin
Apr 3 at 12:30
@mjustin Exactly. What they mean is that decoder produces some uncompressed frames, not necessarily identical to original.
– gronostaj
Apr 3 at 12:37
@gronostaj But if the decoder is decoding from an uncompressed lossless format, then the result should be identical to the original ones, pixel by pixel. That's what I understood.
– mjustin
Apr 3 at 12:43
|
show 1 more comment
@Attie Now bold "original"
– Lightness Races in Orbit
Apr 3 at 9:41
1
@Attie I'm interpreting "original", "large size" in OP's question as "lossless"
– gronostaj
Apr 3 at 9:45
Well, I get to understand that if the compression is lossless and is the first transcoding from the original (not concatenated), you can always decode and encode it back to the original pixel by pixel video, but not from a lossy format.
– mjustin
Apr 3 at 12:30
@mjustin Exactly. What they mean is that decoder produces some uncompressed frames, not necessarily identical to original.
– gronostaj
Apr 3 at 12:37
@gronostaj But if the decoder is decoding from an uncompressed lossless format, then the result should be identical to the original ones, pixel by pixel. That's what I understood.
– mjustin
Apr 3 at 12:43
@Attie Now bold "original"
– Lightness Races in Orbit
Apr 3 at 9:41
@Attie Now bold "original"
– Lightness Races in Orbit
Apr 3 at 9:41
1
1
@Attie I'm interpreting "original", "large size" in OP's question as "lossless"
– gronostaj
Apr 3 at 9:45
@Attie I'm interpreting "original", "large size" in OP's question as "lossless"
– gronostaj
Apr 3 at 9:45
Well, I get to understand that if the compression is lossless and is the first transcoding from the original (not concatenated), you can always decode and encode it back to the original pixel by pixel video, but not from a lossy format.
– mjustin
Apr 3 at 12:30
Well, I get to understand that if the compression is lossless and is the first transcoding from the original (not concatenated), you can always decode and encode it back to the original pixel by pixel video, but not from a lossy format.
– mjustin
Apr 3 at 12:30
@mjustin Exactly. What they mean is that decoder produces some uncompressed frames, not necessarily identical to original.
– gronostaj
Apr 3 at 12:37
@mjustin Exactly. What they mean is that decoder produces some uncompressed frames, not necessarily identical to original.
– gronostaj
Apr 3 at 12:37
@gronostaj But if the decoder is decoding from an uncompressed lossless format, then the result should be identical to the original ones, pixel by pixel. That's what I understood.
– mjustin
Apr 3 at 12:43
@gronostaj But if the decoder is decoding from an uncompressed lossless format, then the result should be identical to the original ones, pixel by pixel. That's what I understood.
– mjustin
Apr 3 at 12:43
|
show 1 more comment
This is a very common blunder.
You can convert from a lossy format to a lossless format, but the damage is done.
The lossless output file will show all the damage (compromised details, added artifacts) that are the reason you don't like the lossy format. You can't get that back.
The only option is to contact the publisher and see if he still has the original lossless files, and would be willing to somehow upload them to you.
There's no such thing as an Enhance button. warning: TVtropes
add a comment |
This is a very common blunder.
You can convert from a lossy format to a lossless format, but the damage is done.
The lossless output file will show all the damage (compromised details, added artifacts) that are the reason you don't like the lossy format. You can't get that back.
The only option is to contact the publisher and see if he still has the original lossless files, and would be willing to somehow upload them to you.
There's no such thing as an Enhance button. warning: TVtropes
add a comment |
This is a very common blunder.
You can convert from a lossy format to a lossless format, but the damage is done.
The lossless output file will show all the damage (compromised details, added artifacts) that are the reason you don't like the lossy format. You can't get that back.
The only option is to contact the publisher and see if he still has the original lossless files, and would be willing to somehow upload them to you.
There's no such thing as an Enhance button. warning: TVtropes
This is a very common blunder.
You can convert from a lossy format to a lossless format, but the damage is done.
The lossless output file will show all the damage (compromised details, added artifacts) that are the reason you don't like the lossy format. You can't get that back.
The only option is to contact the publisher and see if he still has the original lossless files, and would be willing to somehow upload them to you.
There's no such thing as an Enhance button. warning: TVtropes
answered Apr 3 at 18:51
HarperHarper
45915
45915
add a comment |
add a comment |
Thanks for contributing an answer to Super User!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1420358%2fcan-compressed-videos-be-decoded-back-to-their-uncompresed-original-format%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
17
uncompressed != original
– Bergi
Apr 2 at 20:00
Yeah, and the question is about reversing the uncompressed to it's original; which has been explained and discussed in the answers.
– mjustin
Apr 3 at 3:36
2
Aside from the technically oriented answers, a legally oriented person (a lawyer or judge or possibly the owner of the intellectual property) will, most probably, insist that the decompressed video is, in a nutshell, still the original work (even if it's copied at a much lower resolution/quality, for example).
– Klaws
Apr 3 at 16:01
@Klaws It logically makes sense. But anyway, one cannot legitimately redistribute the video/audio in an opensource format unless the original allows it to be converted or redistributed; as far as I know.
– mjustin
Apr 3 at 18:30