Consumer ready 360° cameras are becoming ever more accessible and many people are experimenting with a variety of 360° content. Out of the many cameras on the market the Ricoh Theta S is one of the most user-friendly, turn-key solutions with lots of built-in features. However, the camera's videos are limited 1920x960 resolution and the Theta+ app only lets you create a timelapse with up to 300 or 400 images. The workaround is to use interval shooting to capture as many images as you'd like at the 5376x2688 to full resolution and then stitch them together manually into an HD video. There are few GUI solutions (especially open-source/free) which let you do this with ease. Here's how you do it:
#! /bin/bash | |
VBR="1500k" | |
FPS="30" | |
QUAL="veryfast" | |
YOUTUBE_URL="rtmp://a.rtmp.youtube.com/live2" | |
KEY="" | |
VIDEO_SOURCE="/home/ubuntu/video3.mp4" |
Brought to you by Headjack
FFmpeg is one of the most powerful tools for video transcoding and manipulation, but it's fairly complex and confusing to use. That's why I decided to create this cheat sheet which shows some of the most often used commands.
Let's start with some basics:
ffmpeg
calls the FFmpeg application in the command line window, could also be the full path to the FFmpeg binary or .exe file
mkdir enhanced | |
for sp in *.jpg; do | |
echo "Converting Image: $sp" | |
convert -auto-gamma -auto-level -normalize $sp "enhanced/$sp" | |
done | |
# from http://superuser.com/questions/370920/auto-image-enhance-for-ubuntu |
Once in a while, you may need to cleanup resources (containers, volumes, images, networks) ...
// see: https://github.com/chadoe/docker-cleanup-volumes
$ docker volume rm $(docker volume ls -qf dangling=true)
$ docker volume ls -qf dangling=true | xargs -r docker volume rm
module ActiveRecordExtension | |
extend ActiveSupport::Concern | |
module ClassMethods | |
# Simple left join taking advantage of existing Rails & Arel code | |
def left_joins(*args) | |
inner_joins = self.joins(*args).arel.join_sources | |
left_joins = inner_joins.map do |join| | |
Arel::Nodes::OuterJoin.new(join.left, join.right) | |
end |
Picking the right architecture = Picking the right battles + Managing trade-offs
- Clarify and agree on the scope of the system
- User cases (description of sequences of events that, taken together, lead to a system doing something useful)
- Who is going to use it?
- How are they going to use it?
When using react-rails for an internationalized app it makes a lot of sense to use i18n-js for translations, so that you can reuse the the strings from your rails app's .yml files (and all the tooling & services that exist around that).
When you use the prerender feature of react-rails you face 2 problems:
- The first is that
translation.js
&i18n.js
from i18n-js need to be loaded inside the server-side JS prerendering processes, which is achieved by loading them inside thecomponents.js
. - The second problem is the server processes need to be aware of the current
locale
of each HTTP request. This is done by adding a custom renderer and using thebefore_render
hook to configure i18n-js accordingly for each render call.