Brion Vibber @brion@mastodon.technology

That's a pretty leet bill yo

X11 ssh forwarding on local networks seems less useful than it used to be, with modern high resolution screens, GPU rendering, etc.

I was going to do a quick edit to a file on my Linux desktop from my Mac laptop, and thought "oh I'll just run my editor via ssh -Y in XQuartz!" Vveerryy cchhooppyy ppeerrffoorrmmaannccee with the Electron-based VS Code (it's uploading huge bitmaps for every screen refresh I think) to the point that it interferes with typing.

Could do it in the terminal, but meh vi...

phpunit -> punitive #SpellingSuggestions

Happy Days are here again...

MacOS X used to have a Java to Obj-C bridge. To expose an Obj-C class to Java you had to create an interface description in a ... ".jobs" file.

New skynet powered Android

Transcoding process is currently running through a bunch of old white house press briefings from the Obama days, which compress much nicer with the new settings as they're 60fps.

Also, chocolate cake!

bahahah 1992

And the histogram clearly shows the 'spreading' from the contrained quality mode versus the original fixed target bitrate, with movement of the peak towards lower bitrates.

With outliers with incorrect durations removed, the report shows a much clearer reduction in average bitrate at each resolution under VP9. Yay!

Histograms, histograms, histograms for everything!

Two big things stand out comparing the new VP9 encodes so far on top against the old VP8 encodes on bottom...

First, the VP9 files have a wider distribution; some files are much lower bitrate, others are on the higher side. This reflects the new config using constrained quality, which will use more bits for files that need it and less for those that don't.

The other is the huge spike on the 0-30kbps range on the old VP8 files. Turns out data is bad...

About 1.5% through the VP9 video transcodes if I'm reading the runes a-right.

Averaging slightly smaller bandwidth for most resolutions so far vs VP8 (there's more variance now between files that use extra bandwidth for quality and those that come in under); not sure why 1080p is skewed differently, but there's fewer files at the higher resolutions so error bars get bigger.

Beware the files done in VP9 so far may not be representative of the total working set!

Running around 48 transcodes simultaneously over servers totaling 304 CPU threads (including HT), with combined load averaging around 100 peaking at 200ish processes.

Many of the jobs are lower-resolution and don't fill out all threads, while HD resolutions can use up to 8 threads but are intermittently blocked on single-thread activity.

It looks like we could crank up the number of simultaneous jobs further, but I'd want to keep an eye on it closely.

Thanks to the improved threading config, VP9 encode times are actually sometimes better than the VP8 encode times were!

Here's for a 53-minute talking head video, which compresses nicely. "VP9" lines are the new files, "WebM" are the old VP8 ones.

At 2160p w/ 16 threads I see higher utilization during threaded portion, but single-thread-dominated regions get even slower.

This is probably where a higher clock speed and modern AVX support team up to let my 2-core/4-thread laptop be faster than my old pre-AVX 8-core/16-thread desktop on most of my encoding tests!

VP9 video encoding threading seems "spiky"...

This is 1080p at 16 threads with the new row-based multithreading: a few seconds of mostly one thread, then a few seconds where it runs a bunch of threads, then repeat.

I'm not sure what's happening in the mostly-single-thread-dominated part, exactly, or if that can be reduced with tweaking the encoding options further.

Was worried about what this every-few-seconds tiny spike in network activity was on my workstation until I remembered, I left "top" running in a ssh session from my laptop.

.

Siri, that is a basic function of the smartphone...

Fiddling with OGVKit video player stuff a little to future-proof against upcoming changes in iOS. Found some bugs and limitations I had before with an alternate rendering path got fixed in iOS 11. Neat!

https://brionv.com/log/2018/06/06/revisiting-avsamplebufferdisplaylayer-on-ios-11/