Parameters for ffmpeg conversion

[prestontrouble]

I'd like to batch-convert some files using ffmpeg, which I believe is the backend to the TinyTV converter. Could someone share the parameters / arguments fed into ffmpeg to correctly generate the compatible AVI files?

Thanks in advance!

P-

[Ben Rose]

Yep, it's ffmpeg. Here's one of the commands the converter runs: ffmpeg -i "input.mp4" -r 24 -vf "scale=210:135,hqdn3d" -b:v 1500k -maxrate 1500k -bufsize 64k -c:v mjpeg -acodec pcm_u8 -ar 10000 -ac 1 output.avi”

Alternate scale options:

scale=210:135:force_original_aspect_ratio=increase,crop=210:135:exact=1,hqdn3d
scale=210:135:force_original_aspect_ratio=decrease,format=yuv444p,pad=210:135:(ow-iw)/2:(oh-ih)/2,format=yuv420p,hqdn3d

We'll try to get this documented in the near future- basically the expected format is MJPG with 8 bit 10KHz audio. Some input videos cause enough difference in output format/content to be incompatible with our firmware- we're still tracking down different examples of that and hope to get everything fixed on the firmware side.

Thanks,
Ben

[prestontrouble]

Thanks Ben! These parameters worked great, I converted a sample file both with the provided converter and a batch converter with the provided flags / arguments and got the same file outputs! This will save me a lot of time doing batch conversions.

[RavenWorks]

I'll also toss in here that you'll need a

Code: [Select]

-pix_fmt yuv420p if the source video isn't in that format already.

[standardman]

hi, would you mind explaining to a total noob how to do this?

[RavenWorks]

Assuming you've already installed ffmpeg:  if you've got an input file named IN.MP4, you would open the terminal in the folder that the video file is in, and then type

Code: [Select]

ffmpeg -i "IN.MP4" -r 24 -pix_fmt yuv420p -vf "scale=210:135:force_original_aspect_ratio=increase,crop=210:135:exact=1,hqdn3d" -b:v 1500k -maxrate 1500k -bufsize 64k -c:v mjpeg -acodec pcm_u8 -ar 10000 -ac 1 "OUT.AVI"
and you can change the bit after -vf according to the suggestions in the earlier post to get different results (like squashing the content, or having letterboxes).

Actually, here's one that I like:

Code: [Select]

-vf "crop=1024:658:112:62,scale=210:135,hqdn3d"
The screen is so tiny that sometimes I like to focus in on just a specific portion of the frame, to make the subject as visible as possible.   This setting takes a 1024x658 region of the original video, that's 112 pixels over and 62 pixels down from the top left corner of the original video.  Obviously that's just the numbers that fit the last video that I did this way, and you'd replace them with whatever works best for the video you're converting, based on measuring a screenshot of the original video.

[Ben Rose]

Thank you for posting those details! Can you let me know what "-pix_fmt yuv420p" fixed for you? Maybe we can integrate it into the app.

[RavenWorks]

I was getting the blue "file is invalid" screen (or whatever it says, I forget exactly) on some converted videos.   I eventually narrowed it down to the source files being *not* chroma subsampled, which ffmpeg respects and carries over to the converted files unless you say otherwise;  non-420 video formats are fairly rare in standard video-playback contexts, but you'll run into it if you're rendering out something lossless to be compressed by a separate program, or something like a .PNG image sequence (or a .GIF) that you're asking ffmpeg to turn into a video.

[RavenWorks]

While I think of it, I might as well document that the other situation that sometimes stymies my ffmpeg conversions is trying to convert a video that completely *lacks* an audio track;  I fix it by first running something like this on the input file:

Code: [Select]

ffmpeg -f lavfi -i anullsrc -i inputfile.mp4 -shortest -c:v copy -c:a aac outputfile.mp4
to add an audio track of silence, and then running the typical tinytv ffmpeg command on this previous command's result.

[adam.langley]

Thanks guys.

I've expanded on these scripts to add non-linear squeezing of videos for the Tiny TV Mini's square display.

Code: [Select]

for i in *.mkv; do ffmpeg -y -i "$i" -r 24 -vf "[0:v]scale=-1:128,split=2[left][right];
[left]crop=iw/2:ih:0:0,geq='p(X * (3 * W - X) / (2 * W),Y)',scale=oh/2:ih[left_scaled];
[right]crop=iw/2:ih:iw/2:0,geq='p(X * (W + X) / (2 * W),Y)',scale=oh/2:ih[right_scaled];
[left_scaled][right_scaled]hstack=2,scale=64:64:force_original_aspect_ratio=increase,hqdn3d[output]" -sws_flags experimental -b:v 300k -maxrate 300k -bufsize 64K -c:v mjpeg -acodec pcm_u8 -ar 10000 -ac 1 "${i%.*}.avi"; done
Here I'm converting MKV files to AVIs for a TinyTV mini.
It splits the screen left and right, then uses quartic scaling (power 4) to scale each side, keeping the center undistorted, and pushing the distortion to the edges.

These are the things you might need to tweak for your own use

1. "*.mkv" - change this for your input video extension
2. scale=128:128. This is for performance reasons, before non-linear scaling, do a linear scale to twice your output resolution. This reduces the number of pixels that need pushing through the non-linear algorithm. I get encode speeds of 60x with this. Don't do the initial rescale, and your encode speed might be only 2 or 3 times realtime.
3. scale-64:64 - of course this is your final output resolution, yay!
4. sws (software scaling) is set to experimental to get a good balance of speed and quality
Here's an example frame of output (attached)

[mrchristian]

After converting a couple of movies, I discovered that even at max volume it was barely audible on the TinyTV2.

To work around that, I've experimented with adding

Code: [Select]

-af  "volume=2.0" (200%) which seems to help.

I may experiment with some normalization as well, at some point. https://github.com/slhck/ffmpeg-normalize

[Ben Rose]

Thanks! I should keep up with this thread with some things I've found recently. We've needed to add some additional audio filters to handle certain input streams, the audio filter portion we're testing looks like:

Code: [Select]

-ac 1 -acodec pcm_u8 -af "volume=0.0dB,aresample=10000,aresample=async=1000,aresample=osf=u8,asetnsamples=n=210:p=0"
The asetnsamples is the important part, 210 is a somewhat arbitrary value that results in about 2 chunks of samples per video frame, which the TV firmware can easily consume. Typically ffmpeg does something like that with the average mp4 input, but some inputs can result in huge chunks of audio spanning many frames, which the TV firmware can't handle.

Somewhat unexpectedly, the conversion to 8 bit seems to lower amplitude on some streams, so it seems like we need to run volumedetect on a resampled stream, for example:

Code: [Select]

ffmpeg -i input.mp4 -vn -ac 1 -af "aresample=10000,aresample=async=1000,asetnsamples=n=210:p=0,aresample=osf=u8,volumedetect" -f null /dev/null

The absolute value of the peak output value can replace the 0.0dB in the first snippet to normalize the way that https://github.com/slhck/ffmpeg-normalize does peak normalization. This seems to get things peak normalized without clipping in the testing we've done.

We do plan to get this integrated into the app but I'm not sure exactly when!

[RavenWorks]

out of curiosity, while we're talking about things that don't quite behave normally -- has anyone looked into whether it's handling gamma properly?   I've put some dim videos on there that looked far far too bright/pale and banded, and I had to tweak the levels manually in ffmpeg to get them to look even remotely like they do on my desktop....   but I haven't sat down and investigated it properly yet.

[Ben Rose]

Hmm.. I think this is most likely an issue at the LCD initialization level or possibly in the JPEGDEC library. Also keep in mind some limitations of a lower cost LCD with 16 bit color, but I do think it can be better. I'll try to look at the initialization today.

[Ben Rose]

Some LCD initialization values seem to have changed back to some generic values instead of what was recommended by the LCD manufacturer(well, distributor)- I attached an adjusted file that you could throw in your TinySceen library within the firmware source folder. It definitely changes how some colors are displayed, other stuff, not so much- I'm not sure if the change is 'good' or not really. Let me know if you try it.