Hey! So, I’ve neglected this blog for long enough, and I think I’ve finally found something that I can talk about for now. Lots and lots and lots and lots of things have gone on in my life over the past few months that I’d consider blog-worthy, but I haven’t really been talking about it in a public forum largely to keep things private.
What I do wish to say is that I’m doing extraordinarily well in my new job. I feel like I’m surpassing even my own expectations with how well I’m doing, and to some degree I’m kinda afraid that I’m going to burn brightly and peak out very quickly, while everyone’s expectations of me keep climbing. But oh well, I’ve passed my own test and I feel like I’m acclimating to the new job very well.
The other thing that I want to mention on a personal note is that I’m intending to move out of my current apartment here soon. My new job affords me the ability to live alone and keep paying the bills. Aside from things that I will not discuss here, I’m mostly looking for a change of environment and a place to truly call my own. I’m actually really excited about it to a certain degree! Right now most of my things are stuffed into a teeny tiny bedroom at the current spot, and with a whole apartment to myself (even if it’s a small studio) I can spread myself out just that much more. I love changing things around and stuff, so it has me excited.
Ah, but now I will move on to other things. Past few days I’ve been writing on facebook and twitter about Linux technology things. I don’t really have a purpose in doing it. Just want to share knowledge in little snippets. I know someone out there is enjoying the reads. So, below I’ll provide the first few posts below and I’ll probably update this blog with additional items moving forward. Enjoy!
OpenVPN is really neat. It’s probably one of the best documented technologies I’ve played with so far. They’ve got a very well fleshed out getting started page here: https://openvpn.net/in…/open-source/documentation/howto.html
What makes OpenVPN so neat is primarily this. You can set up a network of sorts that’s completely isolated from other networks. The server will be your router, and it’ll hand out virtual IPs using “tunnels” to all of the clients that you connect to it.
Where is this useful? Well, consider that you have an ISP with dynamic IPs. Your public IP is always changing, but you want to be able to host things within your home LAN as though you have a static IP. So, you buy a small server in a datacenter somewhere (such as with cloudatcost.com), install openvpn and create a server, and then create a client on your home device to that openvpn server.
Even though your ISP IP is always changing, the tunnel IP that openvpn gives your device will never change, and ideally the public IP of that server you bought in the datacenter will never change either. Bam! You now have a static IP address for a “router” that will connect your home device to the web, and you’ve gotten around your dynamic IP address problem.
I have a love-hate relationship with FFMPEG. It’s probably the coolest and most frustrating thing I’ve dabbled in so far. FFMPEG is the technology I use to power my infamous “Lizard Cam.” You know… It’s that tech-tech that makes this thing work:http://chopstick.lizard.camera/
So what is FFMPEG? FFMPEG is basically a “transcoder.” It takes video or sound input, and then recodes it into another format/size, and it can do this all over the command line. For example, it can take raw input from a web cam and recode it into flash video formats. Often, the formats are referred to as “codecs.”
That’s where things get tricky, though. There are a gazillion different codecs for both video and audio. Some are only compatible with a select few. Like, AAC audio codecs won’t be compatible with flash codecs. Only mp3 will be. And then there’s a matter of whether you have compiled your FFMPEG program with support for the codecs that you’re intending to use. And then there’s the matter of figuring out the proper syntax for the command that you’re going to use to grab and transcode your audio/video input. And THEN there’s the matter of figuring out a working configuration in your FFserver (more about this in a minute) file so that you can stream it.
It very very quickly gets complicated. The documentation isn’t any help either, because it focuses more on concepts rather than a good “getting started” or on definitions, commands, compatibilities, or working setups. Then again, the documentation looks different now than it did when I first started dabbling: https://www.ffmpeg.org/documentation
FFserver, on the other hand, is the portion of the technology that allows you to stream whatever it is that you’re capturing. I wouldn’t say that it’s any easier, but it does kinda put itself together once you figure FFMPEG out.
All in all, very very neat technology, but exceedingly frustrating and poorly documented (as of a year ago, anyway).
WORKING FFMPEG EXAMPLE:
I’m now going to present a working FFMPEG command, along with explanations of all the little bits.
nohup ffmpeg -video_size 1920×1080 -framerate 20 -f x11grab -i :0.0 -f alsa -ac 2 -i pulse http://localhost:9537/screencast.ffm &
*nohup = This detaches the command from your current terminal session. It writes the output to a file called nohup.out, and if you close your terminal session the command will stay running.
*ffmpeg = This is the actual ffmpeg command. Everything following that is a modifier/option that changes its behavior.
*video_size = This sets the size of the frame that your video will be, in this case a full 1920×1080 pixels.
*framerate = This is fairly self explanatory. This tells FFMPEG how many frames to grab per second. The higher the framerate, the higher the quality, but the higher the bitrate and the more internet bandwidth your little stream here will require. In this case, the framerate is 20, which is about standard.
*-f x11grab = The ‘-f’ stands for format. In this first case, we’re telling FFMPEG that our video format is going to be x11grab. In Linux, any desktop GUI environment is basically generated by a program called X11, so this tells FFMPEG to grab the video input from X11 directly. A screencast, if you will.
*-i :0.0 = In X11, the computer screens are referred to as displays. The -i tells FFMPEG to get input, and :0.0 refers to the first display. :0.1 would be my second computer screen. So basically, grab input from the first computer screen (in my case, my left screen).
*-f alsa -ac 2 -i pulse = Gonna do this as a whole, since they all go together. This time, the -f (format) tells FFMPEG about what audio we’re going to capture from the system. Alsa is actually a part of the Linux core kernel, and it interfaces with other programs to give a Linux computer sound. So we’re telling it to get stuff from the sound system directly. ‘-ac 2’ tells FFMPEG to create two audio channels. Meant to be played over two speakers, basically. Finally, the ‘-i pulse’ is telling FFMPEG to capture the sound from the Pulse Audio system. It’s similar to specifying the exact screen that we want our video from, like I described above.
*http://localhost:9537/screencast.ffm = FINALLY we have our output file. All that stuff that I described above is basically specifying inputs to FFMPEG and modifying that input’s parameters. This is where all that garbage goes after FFMPEG has processed it. The screencast.ffm file is a dynamic streaming file, which is designed to be streamed live over the internet for other viewers.
*& = This little ampersand basically runs your command in the background of your terminal session, so that you can run additional commands while this one runs. It sorta goes hand in hand with the nohup portion at the beginning.
An exhausting command, but a working one! As you can probably guess, this is designed to grab my actual desktop screen and stream it to the internet. If I were actually running this, you’d be able to see it here:
I originally came up with this because I couldn’t find a good Linux screencasting option out of all the options out there (like Livestream or Ustream, etc). Ended up just making my own.
LINUX COMMAND LINE:
First, about “command lines” in general. When I think of a command line, I think of that blinky cursor thing that appears on a black screen, and you type weird voodoo into it to make things happen on a computer. I would imagine that most people probably associate the command line (or command prompt) with hackers, computer geniuses, geeks, nerds, and things like that. But mostly hackers.
The command line is actually not a very difficult concept to grasp if it’s properly explained. Let’s break it down…
1) A command line is a place where you input commands to a computer.
2) The commands that you input are defined by a “shell.” I like to think of a shell as a type of programming language. It has a syntax (way of writing commands), defined commands that you’re allowed to use, logic, and so forth.
3) The most popular command line shell for Linux is called BASH.
I think the next place to take this is to think about the commands themselves, and how they work in general.
Most commands are actually little tiny programs in and of themselves. They perform very simple tasks, and their behavior can be modified within the overall command that you feed into your command line. Let me give you an example:
“ls” — This command is a program designed to list files and folders within a certain directory (folder).
“ls -a” — Here, I’m using ls and I’m adding a modifier (or option) to the command, telling it to list all. The ‘a’ here stands for “all.” Often, there are hidden files and folders within a directory and this modifier will make them visible.
“ls -a /home/jesse/foldername” — Here, I’m specifying a specific folder path that I want to have listed.
You see how I’m doing this? I start with my command, and I add modifiers to it, and it performs a task that I want it to perform. Easy to grasp conceptually, but much more complicated once you get into the more complicated commands, and you start stringing them together into complicated scripts (or ‘one-liners’ as some people call them).