ffmpeg yuv420p to yuv422p and back
So I have a raw video in yuv420p format - input.yuv, and I know its frame size. I execute 2 commands:
ffmpeg -pix_fmt yuv420p -s 352x288 -i input.yuv -pix_fmt yuv422p input_yuv422p.yuv
and then
ffmpeg -pix_fmt yuv422p -s 352x288 -i input_yuv422p.yuv -pix_fmt yuv420p input_decoded.yuv
The problem is that files input.yuv and input_decoded.yuv differ. My understanding is that when we convert to yuv422p from yuv420p - we should essentially copy existing U and V components to produce more samples to fill in; then, when converting back - we should simply drop these samples, and receive the original file back, but that's not what I see. Am I doing something wrong here, and is it possible to receive original yuv420p back?
ffmpeg yuv
asked Feb 5 at 9:30
IvanIvanovichIvanIvanovich
11
|
show 1 more comment
So I have a raw video in yuv420p format - input.yuv, and I know its frame size. I execute 2 commands:
ffmpeg -pix_fmt yuv420p -s 352x288 -i input.yuv -pix_fmt yuv422p input_yuv422p.yuv
and then
ffmpeg -pix_fmt yuv422p -s 352x288 -i input_yuv422p.yuv -pix_fmt yuv420p input_decoded.yuv
The problem is that files input.yuv and input_decoded.yuv differ. My understanding is that when we convert to yuv422p from yuv420p - we should essentially copy existing U and V components to produce more samples to fill in; then, when converting back - we should simply drop these samples, and receive the original file back, but that's not what I see. Am I doing something wrong here, and is it possible to receive original yuv420p back?
ffmpeg yuv
asked Feb 5 at 9:30
IvanIvanovichIvanIvanovich
11
1
Rounding errors, I guess? Can you quantify the differences in luma/chroma?
– slhck
Feb 5 at 9:41
Hm, if we simply copy bytes when doing420pto422pand drop bytes when converting back - there should be no possible source for rounding errors. Maybe my assumption about how the conversion420pto422pis performed is wrong, andffmpegdoes some kind of interpolation indeed. Will check differences now, thanks.
– IvanIvanovich
Feb 5 at 10:10
So I get this PSNR between original and converted back:PSNR y:inf u:51.837944 v:51.936866so only chroma differs. Is it possible to somehow instructffmpegto use the simple copying/dropping bytes when converting betweenyuv420pandyuv422pforward/backward?
– IvanIvanovich
Feb 5 at 10:20
No, don't think so. In principle copying the bytes is what would be needed, but the image is decoded and encoded back to the new format, hence possible interpolation errors. You could check a hex dump of a small example (or use rawpixels.net) to see where the error comes from — or how big it is.
– slhck
Feb 5 at 13:42
Yeah, I guess ffmpeg performs some interpolation when upsampling from 420 to 422 and antialiasing when downsampling back from 422 to 420 - at least that's the default behavior of similar Matlab library: mathworks.com/help/vision/ref/chromaresampling.html. And it looks like this library actually has the options to achieve the behavior I wanted, which would result in no difference between the original yuv420p and "converted back", in case anyone also needs this. How do I close this question as answered?)
– IvanIvanovich
Feb 7 at 14:15
|
show 1 more comment
So I have a raw video in yuv420p format - input.yuv, and I know its frame size. I execute 2 commands:
ffmpeg -pix_fmt yuv420p -s 352x288 -i input.yuv -pix_fmt yuv422p input_yuv422p.yuv
and then
ffmpeg -pix_fmt yuv422p -s 352x288 -i input_yuv422p.yuv -pix_fmt yuv420p input_decoded.yuv
The problem is that files input.yuv and input_decoded.yuv differ. My understanding is that when we convert to yuv422p from yuv420p - we should essentially copy existing U and V components to produce more samples to fill in; then, when converting back - we should simply drop these samples, and receive the original file back, but that's not what I see. Am I doing something wrong here, and is it possible to receive original yuv420p back?
ffmpeg yuv
asked Feb 5 at 9:30
IvanIvanovichIvanIvanovich
11
So I have a raw video in yuv420p format - input.yuv, and I know its frame size. I execute 2 commands:
ffmpeg -pix_fmt yuv420p -s 352x288 -i input.yuv -pix_fmt yuv422p input_yuv422p.yuv
and then
ffmpeg -pix_fmt yuv422p -s 352x288 -i input_yuv422p.yuv -pix_fmt yuv420p input_decoded.yuv
The problem is that files input.yuv and input_decoded.yuv differ. My understanding is that when we convert to yuv422p from yuv420p - we should essentially copy existing U and V components to produce more samples to fill in; then, when converting back - we should simply drop these samples, and receive the original file back, but that's not what I see. Am I doing something wrong here, and is it possible to receive original yuv420p back?
ffmpeg yuv
ffmpeg yuv
asked Feb 5 at 9:30
IvanIvanovichIvanIvanovich
11
asked Feb 5 at 9:30
IvanIvanovichIvanIvanovich
11
asked Feb 5 at 9:30
IvanIvanovichIvanIvanovich
11
asked Feb 5 at 9:30
IvanIvanovichIvanIvanovich
11
asked Feb 5 at 9:30
IvanIvanovichIvanIvanovich
11
11
1
Rounding errors, I guess? Can you quantify the differences in luma/chroma?
– slhck
Feb 5 at 9:41
Hm, if we simply copy bytes when doing420pto422pand drop bytes when converting back - there should be no possible source for rounding errors. Maybe my assumption about how the conversion420pto422pis performed is wrong, andffmpegdoes some kind of interpolation indeed. Will check differences now, thanks.
– IvanIvanovich
Feb 5 at 10:10
So I get this PSNR between original and converted back:PSNR y:inf u:51.837944 v:51.936866so only chroma differs. Is it possible to somehow instructffmpegto use the simple copying/dropping bytes when converting betweenyuv420pandyuv422pforward/backward?
– IvanIvanovich
Feb 5 at 10:20
No, don't think so. In principle copying the bytes is what would be needed, but the image is decoded and encoded back to the new format, hence possible interpolation errors. You could check a hex dump of a small example (or use rawpixels.net) to see where the error comes from — or how big it is.
– slhck
Feb 5 at 13:42
Yeah, I guess ffmpeg performs some interpolation when upsampling from 420 to 422 and antialiasing when downsampling back from 422 to 420 - at least that's the default behavior of similar Matlab library: mathworks.com/help/vision/ref/chromaresampling.html. And it looks like this library actually has the options to achieve the behavior I wanted, which would result in no difference between the original yuv420p and "converted back", in case anyone also needs this. How do I close this question as answered?)
– IvanIvanovich
Feb 7 at 14:15
|
show 1 more comment
1
Rounding errors, I guess? Can you quantify the differences in luma/chroma?
– slhck
Feb 5 at 9:41
Hm, if we simply copy bytes when doing420pto422pand drop bytes when converting back - there should be no possible source for rounding errors. Maybe my assumption about how the conversion420pto422pis performed is wrong, andffmpegdoes some kind of interpolation indeed. Will check differences now, thanks.
– IvanIvanovich
Feb 5 at 10:10
So I get this PSNR between original and converted back:PSNR y:inf u:51.837944 v:51.936866so only chroma differs. Is it possible to somehow instructffmpegto use the simple copying/dropping bytes when converting betweenyuv420pandyuv422pforward/backward?
– IvanIvanovich
Feb 5 at 10:20
No, don't think so. In principle copying the bytes is what would be needed, but the image is decoded and encoded back to the new format, hence possible interpolation errors. You could check a hex dump of a small example (or use rawpixels.net) to see where the error comes from — or how big it is.
– slhck
Feb 5 at 13:42
Yeah, I guess ffmpeg performs some interpolation when upsampling from 420 to 422 and antialiasing when downsampling back from 422 to 420 - at least that's the default behavior of similar Matlab library: mathworks.com/help/vision/ref/chromaresampling.html. And it looks like this library actually has the options to achieve the behavior I wanted, which would result in no difference between the original yuv420p and "converted back", in case anyone also needs this. How do I close this question as answered?)
– IvanIvanovich
Feb 7 at 14:15
1
1
Rounding errors, I guess? Can you quantify the differences in luma/chroma?
– slhck
Feb 5 at 9:41
Rounding errors, I guess? Can you quantify the differences in luma/chroma?
– slhck
Feb 5 at 9:41
Hm, if we simply copy bytes when doing
420p to 422p and drop bytes when converting back - there should be no possible source for rounding errors. Maybe my assumption about how the conversion 420p to 422p is performed is wrong, and ffmpeg does some kind of interpolation indeed. Will check differences now, thanks.– IvanIvanovich
Feb 5 at 10:10
Hm, if we simply copy bytes when doing
420p to 422p and drop bytes when converting back - there should be no possible source for rounding errors. Maybe my assumption about how the conversion 420p to 422p is performed is wrong, and ffmpeg does some kind of interpolation indeed. Will check differences now, thanks.– IvanIvanovich
Feb 5 at 10:10
So I get this PSNR between original and converted back:
PSNR y:inf u:51.837944 v:51.936866 so only chroma differs. Is it possible to somehow instruct ffmpeg to use the simple copying/dropping bytes when converting between yuv420p and yuv422p forward/backward?– IvanIvanovich
Feb 5 at 10:20
So I get this PSNR between original and converted back:
PSNR y:inf u:51.837944 v:51.936866 so only chroma differs. Is it possible to somehow instruct ffmpeg to use the simple copying/dropping bytes when converting between yuv420p and yuv422p forward/backward?– IvanIvanovich
Feb 5 at 10:20
No, don't think so. In principle copying the bytes is what would be needed, but the image is decoded and encoded back to the new format, hence possible interpolation errors. You could check a hex dump of a small example (or use rawpixels.net) to see where the error comes from — or how big it is.
– slhck
Feb 5 at 13:42
No, don't think so. In principle copying the bytes is what would be needed, but the image is decoded and encoded back to the new format, hence possible interpolation errors. You could check a hex dump of a small example (or use rawpixels.net) to see where the error comes from — or how big it is.
– slhck
Feb 5 at 13:42
Yeah, I guess ffmpeg performs some interpolation when upsampling from 420 to 422 and antialiasing when downsampling back from 422 to 420 - at least that's the default behavior of similar Matlab library: mathworks.com/help/vision/ref/chromaresampling.html. And it looks like this library actually has the options to achieve the behavior I wanted, which would result in no difference between the original yuv420p and "converted back", in case anyone also needs this. How do I close this question as answered?)
– IvanIvanovich
Feb 7 at 14:15
Yeah, I guess ffmpeg performs some interpolation when upsampling from 420 to 422 and antialiasing when downsampling back from 422 to 420 - at least that's the default behavior of similar Matlab library: mathworks.com/help/vision/ref/chromaresampling.html. And it looks like this library actually has the options to achieve the behavior I wanted, which would result in no difference between the original yuv420p and "converted back", in case anyone also needs this. How do I close this question as answered?)
– IvanIvanovich
Feb 7 at 14:15
|
show 1 more comment
1 Answer
1
active
oldest
votes
It seems that ffmpeg performs some interpolation when upsampling from 420 to 422 and antialiasing when downsampling back from 422 to 420 - at least that's the default behavior of similar Matlab library: mathworks.com/help/vision/ref/chromaresampling.html. And it looks like this library actually has the options to achieve the behavior of simply copying/dropping chrominance values which would result in no difference between the original yuv420p and "converted back", in case anyone also needs this.
answered Feb 8 at 12:17
IvanIvanovichIvanIvanovich
11
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%2f1402182%2fffmpeg-yuv420p-to-yuv422p-and-back%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
It seems that ffmpeg performs some interpolation when upsampling from 420 to 422 and antialiasing when downsampling back from 422 to 420 - at least that's the default behavior of similar Matlab library: mathworks.com/help/vision/ref/chromaresampling.html. And it looks like this library actually has the options to achieve the behavior of simply copying/dropping chrominance values which would result in no difference between the original yuv420p and "converted back", in case anyone also needs this.
answered Feb 8 at 12:17
IvanIvanovichIvanIvanovich
11
add a comment |
It seems that ffmpeg performs some interpolation when upsampling from 420 to 422 and antialiasing when downsampling back from 422 to 420 - at least that's the default behavior of similar Matlab library: mathworks.com/help/vision/ref/chromaresampling.html. And it looks like this library actually has the options to achieve the behavior of simply copying/dropping chrominance values which would result in no difference between the original yuv420p and "converted back", in case anyone also needs this.
answered Feb 8 at 12:17
IvanIvanovichIvanIvanovich
11
add a comment |
It seems that ffmpeg performs some interpolation when upsampling from 420 to 422 and antialiasing when downsampling back from 422 to 420 - at least that's the default behavior of similar Matlab library: mathworks.com/help/vision/ref/chromaresampling.html. And it looks like this library actually has the options to achieve the behavior of simply copying/dropping chrominance values which would result in no difference between the original yuv420p and "converted back", in case anyone also needs this.
answered Feb 8 at 12:17
IvanIvanovichIvanIvanovich
11
It seems that ffmpeg performs some interpolation when upsampling from 420 to 422 and antialiasing when downsampling back from 422 to 420 - at least that's the default behavior of similar Matlab library: mathworks.com/help/vision/ref/chromaresampling.html. And it looks like this library actually has the options to achieve the behavior of simply copying/dropping chrominance values which would result in no difference between the original yuv420p and "converted back", in case anyone also needs this.
answered Feb 8 at 12:17
IvanIvanovichIvanIvanovich
11
answered Feb 8 at 12:17
IvanIvanovichIvanIvanovich
11
answered Feb 8 at 12:17
IvanIvanovichIvanIvanovich
11
answered Feb 8 at 12:17
IvanIvanovichIvanIvanovich
11
11
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%2f1402182%2fffmpeg-yuv420p-to-yuv422p-and-back%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
1
Rounding errors, I guess? Can you quantify the differences in luma/chroma?
– slhck
Feb 5 at 9:41
Hm, if we simply copy bytes when doing
420pto422pand drop bytes when converting back - there should be no possible source for rounding errors. Maybe my assumption about how the conversion420pto422pis performed is wrong, andffmpegdoes some kind of interpolation indeed. Will check differences now, thanks.– IvanIvanovich
Feb 5 at 10:10
So I get this PSNR between original and converted back:
PSNR y:inf u:51.837944 v:51.936866so only chroma differs. Is it possible to somehow instructffmpegto use the simple copying/dropping bytes when converting betweenyuv420pandyuv422pforward/backward?– IvanIvanovich
Feb 5 at 10:20
No, don't think so. In principle copying the bytes is what would be needed, but the image is decoded and encoded back to the new format, hence possible interpolation errors. You could check a hex dump of a small example (or use rawpixels.net) to see where the error comes from — or how big it is.
– slhck
Feb 5 at 13:42
Yeah, I guess ffmpeg performs some interpolation when upsampling from 420 to 422 and antialiasing when downsampling back from 422 to 420 - at least that's the default behavior of similar Matlab library: mathworks.com/help/vision/ref/chromaresampling.html. And it looks like this library actually has the options to achieve the behavior I wanted, which would result in no difference between the original yuv420p and "converted back", in case anyone also needs this. How do I close this question as answered?)
– IvanIvanovich
Feb 7 at 14:15