0

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.

4
  • Does this device only support MPEG-4 Part 2 video? What other formats does it support? The encoder mpeg4 only supports yuv420p.
    – llogan
    Commented Jan 17, 2019 at 23:09
  • Can you share a video that looks good on the device?
    – Gyan
    Commented Jan 18, 2019 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. Commented Jan 18, 2019 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. Commented Jan 18, 2019 at 14:17

0

You must log in to answer this question.

Browse other questions tagged .