ffmpeg commandline for maximum compatibility

An old Raspberry Pi was not playing some videos. Looked around for a transcoding option with ffmpeg, baseline x264 seemed fine, and this example worked for me -

ffmpeg -i input.avi -c:v libx264 -preset slow -crf 22 -c:a copy -profile:v baseline -level 3.0 output.mp4

by looking at

https://trac.ffmpeg.org/wiki/Encode/H.264

Another post has the 2-pass encoding example, where the bitrate is also specified. 

videos for waiting area - redux

The original idea of having a marquee which would update as in my previous post turned out to be not very workable. Even if the wifi was not flaky, updating the times etc on a computer in the office would be "too much work" for us in the middle of shows. And the wifi signal was being completely lost due to electrical noise from our solar system exhibit's motor and my room's AC compressor motor. So, the idea was adapted to showing a notice in 3 languages, that the average wait time is 30 minutes, every five minutes or so.

Notice made in Google docs and screenshotted, added an "invert" filter scrolling up-down for visibility.

The next change was to use the "smart TV" media playback for the two flat screens instead of buying Raspberry Pis for them. Since anyway the content was going to be static, did not make sense to buy. Idea suggested by S.

The "smart" TVs would only play a single video file, would need intervention after a single video file was played, would not play playlists. So, strung together all the files into a single file, repeated it for 3 hours so that no intervention would be needed. I had used avidemux, vdub, ffmpeg for doing this, but S more comfortable with VSDC on Windows.

Ffmpeg commandline for making files of known size - first calculate required bitrate by size / duration, using kbits and seconds, then something like

for half an hour 500 MB, = 500 * 1000 * 8 kbits

bitrate = file size / duration

=4000000/1800 = 2222 kbps. Let's take as 2200 kbps.

so, 2200k

ffmpeg -y -i input -c:v libx264 -preset medium -b:v 2200k -pass 1 -c:a libmp3lame -b:a 128k -f mp4 /dev/null && \ 

ffmpeg -i input -c:v libx264 -preset medium -b:v 2200k -pass 2 -c:a libmp3lame -b:a 128k output.mp4

In the ffmpeg example obtained by googling, it was AAC audio. But on my machine,
 Unknown encoder 'libfdk_aac'
So, used libmp3lame instead.

Playing the single file on the Pis had some issues. The older Pi would not play, since it did not support the codec -  x264 High Profile, I think. The other Pi had vignetting issues, the 16x9 videos were appearing too small on the 4x3 TVs. So, the Pis play playlists, and the "smart" TVs play single video files. The older Pi does not play VP8. Files downloaded from Youtube via desktop (MPEG4 codec) were fine, downloaded via mobile by S were VP8.

Also learned that the Raspberry Pi overscan controls do not work with VLC in fullscreen mode (on RPi3).

Also learned that the Raspberry Pi (2 and 3) video out pinout of the TRRS connector did not have Sleeve as ground! TRRS = L, R, GND, Video! Had to modify the TRRS to RCA cable we bought, inverting GND and VID for one of the RCAs.

For getting composite video out, 0 is NTSC and 2 is PAL,
https://www.raspberrypi.org/documentation/configuration/config-txt/video.md

if only sdtv_out=2 does not work,

https://bhavyanshu.me/tutorials/force-raspberry-pi-output-to-composite-video-instead-of-hdmi/03/03/2014/

And with the remote for shutting down the Pis, they can be operated completely independent of wifi availability.

Veracrypt fix

A Veracrypt volume on a removable (NTFS) hard disk was not mounting. Veracrypt was complaining of bad password or bad volume. I thought the password was correct. Finally, did

sudo fdisk -l

to find the device name, which was /dev/sdc1 for the removable drive in this case, and then

sudo ntfsfix /dev/sdc1

It finished in less than a second, noting that it had successfully completed. Then, tried mounting with Veracrypt, success!

After mounting, the encrypted volume was visible in Nemo with an icon to unmount it. But unmounting it with Nemo does not really unmount it, probably because Veracrypt uses su privileges to mount - you have to unmount (or Dismount) it via the Veracrypt interface. Only then would the removable drive become free of processes and unmountable via Nemo.

Thursday, May 02, 2019

Octave memory issues and workaround

I had an Octave script which was reading data from files into a variable, doing some processing, then reading some different data into the same variable, and so on. For many hundreds of MB of data, using the load function. But Octave was running out of memory, and finally I had to
killall -9 octave-gui

The workaround was to process part of the data, save the intermediate data to file, exit Octave, reload Octave, resume processing, and so on. Painful, but it worked. 

Subscribe to: Posts (Atom)