FFMPEG: How to convert 24 bpp MP4 to 16 bpp AVI that has rgb565le format?
SUMMARY: I'm trying to figure out (get an example, I guess) how to use the scaler src_format/dst_format tags to convert to a specific 16 bpp RGB format for a target device.
I'm dealing with some older hardware that plays videos off a small 64 MB SD card. Yeah, MB. The display is only 640x480, and I've recently figured out that is has a 16 bits per pixel video driver that I think is 5:6:5 RGB. This last piece is new, and probably explains why input files that had gradient fills in animation sections display with strange banding behaviors - lots of flickery blocks.
The input files are a mix of things - various sized video files sourced from all over (but 45 seconds or less), and I'm using FFMPEG to convert from the input format to my target format:
AVI container
XVID video at 300 kbps or so
MP3 audio at 96 kbps mono or stereo
640x480 size to fit screen
small file size so that 10 or so files can fit on the SD card, along with the playback looping program (it's an old, and low-tech by today's standards, device, and isn't changeable for several reasons)
I had a conversion setup running a few weeks ago for the first batch of conversion, but people weren't happy with the quality of the output, and MediaInfo kept reporting that the bit rate with a lot more than the 300K desired value.
I'd been using the libxvid codec, but there's actually a bug logged (#6217) that indicate the -b:v 300K attribute doesn't work with that, but that the mpeg4 codec does work. Some experiments over the past couple of days makes me believe that. I also found that I could increase the target bit rate to about 500 kbps with the mpeg4 codec and end up with a reasonable size output file (about 3 MB for a 40s file).
What I've ended up with so far is this:
ffmpeg -y -i "input.mp4" -s 640x480 -aspect 4:3 -vf fps=24 -g 12 -c:v mpeg4 -vtag xvid -src_format yuv420p -sws_flags full_chroma_int+accurate_rnd+lanczos -b:v 500k -pass 1 -an -f avi NUL
ffmpeg -y -i "input.mp4" -s 640x480 -aspect 4:3 -vf fps=24 -g 12 -c:v mpeg4 -vtag xvid -sws_flags full_chroma_int+accurate_rnd+lanczos -b:v 500k -pass 2 -c:a libmp3lame -b:a 96k "output.avi"
I get files that work on the device, but gradient sections are very blocky and flicker a lot, and areas that have a large rectangle of a red shade have all sorts of artifacts when played back on the target device. The artifacts are also visible when I play the output video in VLC on my Windows laptop. They just look worse on the target device.
I tried using -q:v n (where n was between 2 and 8) - the quality was somewhat better, but the file size was impractical.
And I do realize that I'm fighting an uphill battle in trying to get a pleasing video when I'm shrinking to my output size and trying to cut the resulting file significantly.
However, in my vast amount of Googling, I ran across something today referring to pixel conversion from YUV (which is what MediaInfo says my particular test files are) to 16bpp RBG. But I can't figure out what the proper incantation is to try and generate an output file that attempts to account for the lower color depth of my device. Tried a few things that objected to my adding -dst_format rgb565le to my command line.
Can anyone explain this, or point me to a sample where this is being done on the command line? Thanks.
ffmpeg video-conversion video-encoding
asked Jan 17 at 22:56
GuyWithDogsGuyWithDogs
1012
add a comment |
SUMMARY: I'm trying to figure out (get an example, I guess) how to use the scaler src_format/dst_format tags to convert to a specific 16 bpp RGB format for a target device.
I'm dealing with some older hardware that plays videos off a small 64 MB SD card. Yeah, MB. The display is only 640x480, and I've recently figured out that is has a 16 bits per pixel video driver that I think is 5:6:5 RGB. This last piece is new, and probably explains why input files that had gradient fills in animation sections display with strange banding behaviors - lots of flickery blocks.
The input files are a mix of things - various sized video files sourced from all over (but 45 seconds or less), and I'm using FFMPEG to convert from the input format to my target format:
AVI container
XVID video at 300 kbps or so
MP3 audio at 96 kbps mono or stereo
640x480 size to fit screen
small file size so that 10 or so files can fit on the SD card, along with the playback looping program (it's an old, and low-tech by today's standards, device, and isn't changeable for several reasons)
I had a conversion setup running a few weeks ago for the first batch of conversion, but people weren't happy with the quality of the output, and MediaInfo kept reporting that the bit rate with a lot more than the 300K desired value.
I'd been using the libxvid codec, but there's actually a bug logged (#6217) that indicate the -b:v 300K attribute doesn't work with that, but that the mpeg4 codec does work. Some experiments over the past couple of days makes me believe that. I also found that I could increase the target bit rate to about 500 kbps with the mpeg4 codec and end up with a reasonable size output file (about 3 MB for a 40s file).
What I've ended up with so far is this:
ffmpeg -y -i "input.mp4" -s 640x480 -aspect 4:3 -vf fps=24 -g 12 -c:v mpeg4 -vtag xvid -src_format yuv420p -sws_flags full_chroma_int+accurate_rnd+lanczos -b:v 500k -pass 1 -an -f avi NUL
ffmpeg -y -i "input.mp4" -s 640x480 -aspect 4:3 -vf fps=24 -g 12 -c:v mpeg4 -vtag xvid -sws_flags full_chroma_int+accurate_rnd+lanczos -b:v 500k -pass 2 -c:a libmp3lame -b:a 96k "output.avi"
I get files that work on the device, but gradient sections are very blocky and flicker a lot, and areas that have a large rectangle of a red shade have all sorts of artifacts when played back on the target device. The artifacts are also visible when I play the output video in VLC on my Windows laptop. They just look worse on the target device.
I tried using -q:v n (where n was between 2 and 8) - the quality was somewhat better, but the file size was impractical.
And I do realize that I'm fighting an uphill battle in trying to get a pleasing video when I'm shrinking to my output size and trying to cut the resulting file significantly.
However, in my vast amount of Googling, I ran across something today referring to pixel conversion from YUV (which is what MediaInfo says my particular test files are) to 16bpp RBG. But I can't figure out what the proper incantation is to try and generate an output file that attempts to account for the lower color depth of my device. Tried a few things that objected to my adding -dst_format rgb565le to my command line.
Can anyone explain this, or point me to a sample where this is being done on the command line? Thanks.
ffmpeg video-conversion video-encoding
asked Jan 17 at 22:56
GuyWithDogsGuyWithDogs
1012
Does this device only support MPEG-4 Part 2 video? What other formats does it support? The encodermpeg4only supports yuv420p.
– llogan
Jan 17 at 23:09
Can you share a video that looks good on the device?
– Gyan
Jan 18 at 5:14
Device only supports AVI containers with Xvid codec. Using libxvid or mpeg4 creates playable videos, but only mpeg4 appears to also allow for the bitrate limiting we need to keep the file size down and not swamp the CPU at playback. And I only confirmed yesterday that the color depth is 16bpp, while almost all of the input is 24bpp so far.
– GuyWithDogs
Jan 18 at 14:17
I really don't have a video that looks good - all videos are displaying the blocky behavior, which is why I started looking in to it. A generalization would be that animations (especially with gradients) being input are usually (subjectively) worse than just normal "around town" video (like a TV commercial, or a music video). And large areas of black background show up at pulsing blocks of gray-black squares.
– GuyWithDogs
Jan 18 at 14:17
add a comment |
SUMMARY: I'm trying to figure out (get an example, I guess) how to use the scaler src_format/dst_format tags to convert to a specific 16 bpp RGB format for a target device.
I'm dealing with some older hardware that plays videos off a small 64 MB SD card. Yeah, MB. The display is only 640x480, and I've recently figured out that is has a 16 bits per pixel video driver that I think is 5:6:5 RGB. This last piece is new, and probably explains why input files that had gradient fills in animation sections display with strange banding behaviors - lots of flickery blocks.
The input files are a mix of things - various sized video files sourced from all over (but 45 seconds or less), and I'm using FFMPEG to convert from the input format to my target format:
AVI container
XVID video at 300 kbps or so
MP3 audio at 96 kbps mono or stereo
640x480 size to fit screen
small file size so that 10 or so files can fit on the SD card, along with the playback looping program (it's an old, and low-tech by today's standards, device, and isn't changeable for several reasons)
I had a conversion setup running a few weeks ago for the first batch of conversion, but people weren't happy with the quality of the output, and MediaInfo kept reporting that the bit rate with a lot more than the 300K desired value.
I'd been using the libxvid codec, but there's actually a bug logged (#6217) that indicate the -b:v 300K attribute doesn't work with that, but that the mpeg4 codec does work. Some experiments over the past couple of days makes me believe that. I also found that I could increase the target bit rate to about 500 kbps with the mpeg4 codec and end up with a reasonable size output file (about 3 MB for a 40s file).
What I've ended up with so far is this:
ffmpeg -y -i "input.mp4" -s 640x480 -aspect 4:3 -vf fps=24 -g 12 -c:v mpeg4 -vtag xvid -src_format yuv420p -sws_flags full_chroma_int+accurate_rnd+lanczos -b:v 500k -pass 1 -an -f avi NUL
ffmpeg -y -i "input.mp4" -s 640x480 -aspect 4:3 -vf fps=24 -g 12 -c:v mpeg4 -vtag xvid -sws_flags full_chroma_int+accurate_rnd+lanczos -b:v 500k -pass 2 -c:a libmp3lame -b:a 96k "output.avi"
I get files that work on the device, but gradient sections are very blocky and flicker a lot, and areas that have a large rectangle of a red shade have all sorts of artifacts when played back on the target device. The artifacts are also visible when I play the output video in VLC on my Windows laptop. They just look worse on the target device.
I tried using -q:v n (where n was between 2 and 8) - the quality was somewhat better, but the file size was impractical.
And I do realize that I'm fighting an uphill battle in trying to get a pleasing video when I'm shrinking to my output size and trying to cut the resulting file significantly.
However, in my vast amount of Googling, I ran across something today referring to pixel conversion from YUV (which is what MediaInfo says my particular test files are) to 16bpp RBG. But I can't figure out what the proper incantation is to try and generate an output file that attempts to account for the lower color depth of my device. Tried a few things that objected to my adding -dst_format rgb565le to my command line.
Can anyone explain this, or point me to a sample where this is being done on the command line? Thanks.
ffmpeg video-conversion video-encoding
asked Jan 17 at 22:56
GuyWithDogsGuyWithDogs
1012
SUMMARY: I'm trying to figure out (get an example, I guess) how to use the scaler src_format/dst_format tags to convert to a specific 16 bpp RGB format for a target device.
I'm dealing with some older hardware that plays videos off a small 64 MB SD card. Yeah, MB. The display is only 640x480, and I've recently figured out that is has a 16 bits per pixel video driver that I think is 5:6:5 RGB. This last piece is new, and probably explains why input files that had gradient fills in animation sections display with strange banding behaviors - lots of flickery blocks.
The input files are a mix of things - various sized video files sourced from all over (but 45 seconds or less), and I'm using FFMPEG to convert from the input format to my target format:
AVI container
XVID video at 300 kbps or so
MP3 audio at 96 kbps mono or stereo
640x480 size to fit screen
small file size so that 10 or so files can fit on the SD card, along with the playback looping program (it's an old, and low-tech by today's standards, device, and isn't changeable for several reasons)
I had a conversion setup running a few weeks ago for the first batch of conversion, but people weren't happy with the quality of the output, and MediaInfo kept reporting that the bit rate with a lot more than the 300K desired value.
I'd been using the libxvid codec, but there's actually a bug logged (#6217) that indicate the -b:v 300K attribute doesn't work with that, but that the mpeg4 codec does work. Some experiments over the past couple of days makes me believe that. I also found that I could increase the target bit rate to about 500 kbps with the mpeg4 codec and end up with a reasonable size output file (about 3 MB for a 40s file).
What I've ended up with so far is this:
ffmpeg -y -i "input.mp4" -s 640x480 -aspect 4:3 -vf fps=24 -g 12 -c:v mpeg4 -vtag xvid -src_format yuv420p -sws_flags full_chroma_int+accurate_rnd+lanczos -b:v 500k -pass 1 -an -f avi NUL
ffmpeg -y -i "input.mp4" -s 640x480 -aspect 4:3 -vf fps=24 -g 12 -c:v mpeg4 -vtag xvid -sws_flags full_chroma_int+accurate_rnd+lanczos -b:v 500k -pass 2 -c:a libmp3lame -b:a 96k "output.avi"
I get files that work on the device, but gradient sections are very blocky and flicker a lot, and areas that have a large rectangle of a red shade have all sorts of artifacts when played back on the target device. The artifacts are also visible when I play the output video in VLC on my Windows laptop. They just look worse on the target device.
I tried using -q:v n (where n was between 2 and 8) - the quality was somewhat better, but the file size was impractical.
And I do realize that I'm fighting an uphill battle in trying to get a pleasing video when I'm shrinking to my output size and trying to cut the resulting file significantly.
However, in my vast amount of Googling, I ran across something today referring to pixel conversion from YUV (which is what MediaInfo says my particular test files are) to 16bpp RBG. But I can't figure out what the proper incantation is to try and generate an output file that attempts to account for the lower color depth of my device. Tried a few things that objected to my adding -dst_format rgb565le to my command line.
Can anyone explain this, or point me to a sample where this is being done on the command line? Thanks.
ffmpeg video-conversion video-encoding
ffmpeg video-conversion video-encoding
asked Jan 17 at 22:56
GuyWithDogsGuyWithDogs
1012
asked Jan 17 at 22:56
GuyWithDogsGuyWithDogs
1012
asked Jan 17 at 22:56
GuyWithDogsGuyWithDogs
1012
asked Jan 17 at 22:56
GuyWithDogsGuyWithDogs
1012
asked Jan 17 at 22:56
GuyWithDogsGuyWithDogs
1012
1012
Does this device only support MPEG-4 Part 2 video? What other formats does it support? The encodermpeg4only supports yuv420p.
– llogan
Jan 17 at 23:09
Can you share a video that looks good on the device?
– Gyan
Jan 18 at 5:14
Device only supports AVI containers with Xvid codec. Using libxvid or mpeg4 creates playable videos, but only mpeg4 appears to also allow for the bitrate limiting we need to keep the file size down and not swamp the CPU at playback. And I only confirmed yesterday that the color depth is 16bpp, while almost all of the input is 24bpp so far.
– GuyWithDogs
Jan 18 at 14:17
I really don't have a video that looks good - all videos are displaying the blocky behavior, which is why I started looking in to it. A generalization would be that animations (especially with gradients) being input are usually (subjectively) worse than just normal "around town" video (like a TV commercial, or a music video). And large areas of black background show up at pulsing blocks of gray-black squares.
– GuyWithDogs
Jan 18 at 14:17
add a comment |
Does this device only support MPEG-4 Part 2 video? What other formats does it support? The encodermpeg4only supports yuv420p.
– llogan
Jan 17 at 23:09
Can you share a video that looks good on the device?
– Gyan
Jan 18 at 5:14
Device only supports AVI containers with Xvid codec. Using libxvid or mpeg4 creates playable videos, but only mpeg4 appears to also allow for the bitrate limiting we need to keep the file size down and not swamp the CPU at playback. And I only confirmed yesterday that the color depth is 16bpp, while almost all of the input is 24bpp so far.
– GuyWithDogs
Jan 18 at 14:17
I really don't have a video that looks good - all videos are displaying the blocky behavior, which is why I started looking in to it. A generalization would be that animations (especially with gradients) being input are usually (subjectively) worse than just normal "around town" video (like a TV commercial, or a music video). And large areas of black background show up at pulsing blocks of gray-black squares.
– GuyWithDogs
Jan 18 at 14:17
Does this device only support MPEG-4 Part 2 video? What other formats does it support? The encoder
mpeg4 only supports yuv420p.– llogan
Jan 17 at 23:09
Does this device only support MPEG-4 Part 2 video? What other formats does it support? The encoder
mpeg4 only supports yuv420p.– llogan
Jan 17 at 23:09
Can you share a video that looks good on the device?
– Gyan
Jan 18 at 5:14
Can you share a video that looks good on the device?
– Gyan
Jan 18 at 5:14
Device only supports AVI containers with Xvid codec. Using libxvid or mpeg4 creates playable videos, but only mpeg4 appears to also allow for the bitrate limiting we need to keep the file size down and not swamp the CPU at playback. And I only confirmed yesterday that the color depth is 16bpp, while almost all of the input is 24bpp so far.
– GuyWithDogs
Jan 18 at 14:17
Device only supports AVI containers with Xvid codec. Using libxvid or mpeg4 creates playable videos, but only mpeg4 appears to also allow for the bitrate limiting we need to keep the file size down and not swamp the CPU at playback. And I only confirmed yesterday that the color depth is 16bpp, while almost all of the input is 24bpp so far.
– GuyWithDogs
Jan 18 at 14:17
I really don't have a video that looks good - all videos are displaying the blocky behavior, which is why I started looking in to it. A generalization would be that animations (especially with gradients) being input are usually (subjectively) worse than just normal "around town" video (like a TV commercial, or a music video). And large areas of black background show up at pulsing blocks of gray-black squares.
– GuyWithDogs
Jan 18 at 14:17
I really don't have a video that looks good - all videos are displaying the blocky behavior, which is why I started looking in to it. A generalization would be that animations (especially with gradients) being input are usually (subjectively) worse than just normal "around town" video (like a TV commercial, or a music video). And large areas of black background show up at pulsing blocks of gray-black squares.
– GuyWithDogs
Jan 18 at 14:17
add a comment |
0
active
oldest
votes
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%2f1395565%2fffmpeg-how-to-convert-24-bpp-mp4-to-16-bpp-avi-that-has-rgb565le-format%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
0
active
oldest
votes
0
active
oldest
votes
active
oldest
votes
active
oldest
votes
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%2f1395565%2fffmpeg-how-to-convert-24-bpp-mp4-to-16-bpp-avi-that-has-rgb565le-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
Does this device only support MPEG-4 Part 2 video? What other formats does it support? The encoder
mpeg4only supports yuv420p.– llogan
Jan 17 at 23:09
Can you share a video that looks good on the device?
– Gyan
Jan 18 at 5:14
Device only supports AVI containers with Xvid codec. Using libxvid or mpeg4 creates playable videos, but only mpeg4 appears to also allow for the bitrate limiting we need to keep the file size down and not swamp the CPU at playback. And I only confirmed yesterday that the color depth is 16bpp, while almost all of the input is 24bpp so far.
– GuyWithDogs
Jan 18 at 14:17
I really don't have a video that looks good - all videos are displaying the blocky behavior, which is why I started looking in to it. A generalization would be that animations (especially with gradients) being input are usually (subjectively) worse than just normal "around town" video (like a TV commercial, or a music video). And large areas of black background show up at pulsing blocks of gray-black squares.
– GuyWithDogs
Jan 18 at 14:17