(by @andrestaltz)
If you prefer to watch video tutorials with live-coding, then check out this series I recorded with the same contents as in this article: Egghead.io - Introduction to Reactive Programming.
#!/bin/bash | |
# for a blogpost on this, check: http://www.aktau.be/2013/09/22/detecting-interlaced-video-with-ffmpeg/ | |
# detect interlacing with the ffmpeg "idet" filter, the longer | |
# you let this run, the better, though it's never 100% accurate | |
# flags: | |
# -an = discard audio, we don't need it | |
# -f rawvideo = output raw video |
(by @andrestaltz)
If you prefer to watch video tutorials with live-coding, then check out this series I recorded with the same contents as in this article: Egghead.io - Introduction to Reactive Programming.
https://www.ffmpeg.org/doxygen/trunk/dump_8c_source.html#l00454
st->avg_frame_rate
st->r_frame_rate
st->time_base
st->codec->time_base
Average framerate.
avformat_find_stream_info()
.avformat_write_header()
.#!/usr/bin/python | |
''' | |
SCTE-35 Decoder | |
The MIT License (MIT) | |
Copyright (c) 2014 Al McCormack |
There are three easy to make mistakes in go. I present them here in the way they are often found in the wild, not in the way that is easiest to understand.
All three of these mistakes have been made in Kubernetes code, getting past code review at least once each that I know of.
What do these lines do? Make predictions and then scroll down.
func print(pi *int) { fmt.Println(*pi) }
Spin up three m3.medium
EC2 ubuntu 14.04
instances with public DNS enabled and configure them for high network traffic by increasing these limits:
Added fs.file-max=80000
to /etc/sysctl.conf
Added the following lines to /etc/security/limits.conf
#!/usr/bin/env python | |
"""Simple server using epoll.""" | |
from __future__ import print_function | |
from contextlib import contextmanager | |
import socket | |
import select | |
/* | |
C socket server example, handles multiple clients using threads | |
Compile | |
gcc server.c -lpthread -o server | |
*/ | |
#include<stdio.h> | |
#include<string.h> //strlen | |
#include<stdlib.h> //strlen | |
#include<sys/socket.h> |
On Twitter the other day, I was lamenting the state of OCSP stapling support on Linux servers, and got asked by several people to write-up what I think the requirements are for OCSP stapling support.
Support for keeping a long-lived (disk) cache of OCSP responses.
This should be fairly simple. Any restarting of the service shouldn't blow away previous responses that were obtained. This doesn't need to be disk, just stable - and disk is an easy stable storage for most server