This patch adds libndi_newtek to last ffmpeg version, and fix timecode related issues that produces wrong PTS/DTS timestamps that seems to happen with newer NDI SDKs.
| #include <array> | |
| #include <cmath> | |
| #include <fstream> | |
| #include <iostream> | |
| #include <vector> | |
| struct Vec { | |
| float x, y, z; | |
| Vec(float vx, float vy, float vz) : x(vx), y(vy), z(vz) {} | |
| Vec operator+(Vec vec) { return {x + vec.x, y + vec.y, z + vec.z}; } |
| #!/bin/bash | |
| # poor-man's quantum photon detector randomizer | |
| # ~1kb/s | |
| # over a test of a thousand time, global entropy was equal to 7.99/8 and passed nearly all Dieharder tests, as well as FIPS 140-2 | |
| # however, sigma, mean and chi-square stats aren't too much enthusiastic | |
| # overall, the result is pretty impressive, but of course, don't use it in production :) | |
| DEVICE=/dev/video0 | |
| # for external cameras should be /dev/video1 |
| From 88287f270df660645b3f6c813ab3fd7ad522e64c Mon Sep 17 00:00:00 2001 | |
| From: KSC-VBU-SR <[email protected]> | |
| Date: Wed, 14 Jun 2017 21:33:54 +0800 | |
| Subject: [PATCH] The RTMP protocol extensions for H.265/HEVC | |
| --- | |
| libavformat/flv.h | 1 + | |
| libavformat/flvdec.c | 16 +++++++++++++--- | |
| libavformat/flvenc.c | 29 ++++++++++++++++++++--------- | |
| 3 files changed, 34 insertions(+), 12 deletions(-) |
This is a script for checking if any of the passwords you have stored in LastPass have been exposed through previous data breaches.
To use the script you need to have Python 3 installed and you need a CSV export of your LastPass vault. The export can be generated from the LastPass CLI with:
lpass export > lastpass.csv
or can be extracted with the browser plugin by going to the LastPass icon → More Options → Advanced → Export → LastPass CSV File (note that I did have problems getting this to work).
| #!/usr/bin/env bash | |
| set -e | |
| [ -z "$CLUSTER_SECRET" ] && echo "Need to set CLUSTER_SECRET" && exit 1; | |
| echo 'export IPFS_PATH=/data/ipfs' >>~/.bash_profile | |
| echo 'export IPFS_CLUSTER_PATH=/data/ipfs-cluster' >>~/.bash_profile | |
| source ~/.bash_profile |
AnnexB format:
([start code] NALU) | ( [start code] NALU) |
AVCC format:
([extradata]) | ([length] NALU) | ([length] NALU) |
| pragma solidity ^0.4.10; | |
| interface ERC20 { | |
| function balanceOf(address who) public view returns (uint256); | |
| function transfer(address to, uint256 value) public returns (bool); | |
| function allowance(address owner, address spender) public view returns (uint256); | |
| function transferFrom(address from, address to, uint256 value) public returns (bool); | |
| function approve(address spender, uint256 value) public returns (bool); | |
| event Transfer(address indexed from, address indexed to, uint256 value); |
I was talking to a coworker recently about general techniques that almost always form the core of any effort to write very fast, down-to-the-metal hot path code on the JVM, and they pointed out that there really isn't a particularly good place to go for this information. It occurred to me that, really, I had more or less picked up all of it by word of mouth and experience, and there just aren't any good reference sources on the topic. So… here's my word of mouth.
This is by no means a comprehensive gist. It's also important to understand that the techniques that I outline in here are not 100% absolute either. Performance on the JVM is an incredibly complicated subject, and while there are rules that almost always hold true, the "almost" remains very salient. Also, for many or even most applications, there will be other techniques that I'm not mentioning which will have a greater impact. JMH, Java Flight Recorder, and a good profiler are your very best friend! Mea
| package demo; | |
| public interface Node {} |
