[Toybox] Toybox tutorial videos.

Rob Landley rob at landley.net
Wed Mar 2 23:10:55 PST 2022


One of my https://patreon.com/landley goals is creating toybox instructional
videos, and that goal was met recently thanks to a generous donor, so I've been
learning how to record and edit video.

I just got permission to send the list a lightly anonymized version of our
recent email exchanges about that:

-------- Forwarded Message --------
Subject: Re: Um, wow.
Date: Sun, 20 Feb 2022 19:34:35 -0600
From: Rob Landley <rob at landley.net>

> Hi Robert,
> thanks for the additional links.
> 
> My offer is still vali: If you have a (server) source with the raw screencast
> footage and some hints on what to trim, mute and cut then I would do the
> editing for you and reupload it to your preferred destination in what ever
> video container you prefer. Let me know if that lowers your distraction ;-).

Sorry for the delay, still working out the design of the tutorial videos.

Out of curiosity: if you were to edit
https://landley.net/toybox/video/truefalse-raw.mp4 what would the result look
like? (Does that recording location have too much background noise? It sounds ok
to me but I already know what I said. That place is easier for me to record
from, but I dunno about the quality of the resulting audio. I can hear an air
conditioner hum while I'm there, but can't tell if the microphone picks it up...)

I sort of want to do two videos for each command: one on usage and one on
implementation. But it may sometimes make sense to pair them up. In this case
true/false make more sense explained together (why return success, why _not_
return success...) So that's kind of two videos in one take (with an obvious-ish
split point), each of which _could_ have been two videos but wasn't...

I also need to do a bunch of background/implementation videos, but don't want to
require massive infodumps before you see anything real either? So there's going
to be a bit of handwaving whatever I do...

I also wind up easily diverging into stuff like:

---

Hello and skeleton.
  You don't usually run either of these. Neither y in defconfig. Most useful as
  templates for creating new commands.
  - hello is simple
  - skeleton tries to show an example of everything, quick place to check syntax

That said, hello's got a couple uses:

If you want to play with a lib/ command, add a call to hello_main(), run it, and
"git checkout toys/*/hello.c" to clear it out again. (Build in toybox context.)

Hello world is a good smoketest for system bringup:
  - First compiler smoketest is "vmlinux compiles".
  - Second is "I got boot messages". (Static initramfs, serial console.)
    - targeting right architecture
    - Bootloader accepted packaging format
    - kernel command line console= selected correct output device
    - configured for correct board layout (found memory, serial, timer)

  - Third: static linked hello world.
    - compiler can build a userspace program, with working crt*.o
    - It's doing system calls and packaging right. (a.out, elf, fdpic, pie...)
    - Your libc works. Built for right target, begin/crtend.o code works.
    - Your kernel has the right loader selected. (Configurable!)

  - Fourth: dynamically linked hello world
    - your dynamic linker works and is installed in the right place.
    - your library search path is picking up libc.

  - Fifth: shell prompt (rdinit=/bin/sh)

---

I want to do videos on mkroot and system building, but the above is what my
"hello/skeleton usage" (not implementation!) video script turned into.

It's EASY for me to just blather and produce reams of footage, but in the
absence of an editing strategy... I want the result to have a clear "start here"
and progression through so people know when they're done, but ALSO be usable as
a reference you can easily seek to bits of and cherry pick from. (This might
wind up being multiple playlists indexing the same video in different
orders/contexts?)

Thanks again,

Rob

On 2/28/22 6:56 PM, Rob Landley wrote:
>> Hi Rob,
>> find my suggestion for an initial cut. DaVinci did not read the m4a stream,
>> so I re-encoded it in ffmpeg. In addition DaVinci has no good bitrate
>> control, so I had to re-encode the mp4 once more after cutting.. it seems
>> your screen capture tool does a better job to keep the output small

simplescreenrecorder out of the debian repo, configured for 5x/second frame rate.

>> then I did while downsizing in ffmpeg (if the result is visually not
>> acceptable for you (some minor artefacts due to the re-encoding in small
>> size) then I can render again in DaVinci what ever you want to change).
>>
>>   * I cut all announced things, but did not remove content (i.e. I cutted the
>>     cursing, the church bell, a repetition, the "ToyBooks..äh..ToyBox" and
>>     start&end)
>>   * I also trimmed the video to the edges of the terminal window. Due to the
>>     tab view open, the font view seem to get slighly smaller
>>
>>
> > Let me know what you think.

It's a good edit, but I pointed chrome at it with file:/// and it played audio only?

Hmmm, I've been recording the full screen because I wanted a constant aspect
ratio, and because I may switch between two windows when showing library code or
using the command as an example during a code walkthrough. (In part I was trying
to avoid that darn xfce bug that forgets the window's aspect ratio when it
resizes because it grew a second tab and has to get a line taller because it's
showing tabs now.)

Rob

On 3/1/22 Rob Landley wrote:
>> Hi Rob,
>> I also had a look at blender, but I did not get the workflow yet, but I will
>> give it a chance.

I'm going through trying to learn it myself.

I want to be able to edit my own videos. I need to do a _lot_ of them: approx
300 commands in the 1.0 toybox, each of which is at least 2 videos, plus at
least one video for each file in lib/ and a bunch on scripts/ and the build
plumbing. I might also wind up doing a video walking through each test suite
entry, showing how it exercises all the corner cases and the standard and what
compromises it makes so other implementations can pass... (The whole "never test
for exact error messages" thing.) And I probably need to do some videos on the
cleanup.html stuff... I gave a talk on "shrinking C code" in 2015
(https://elinux.org/ELC_2015_Presentations) but the Linux Foundation actually
deleted that entire year's worth of ELC videos and I didn't have a backup of
that one. (Or the toybox talk I gave that year...) And then there's videos on
system building theory, and natively building under mkroot once I've got that
working...

I've already watched most of
https://www.youtube.com/watch?list=PLjyuVPBuorqIhlqZtoIvnAVQ3x18sNev4
and it's making sense, but "cutting together subsets of a longer video" is
treated as too trivial to give a real example of.

I almost emailed you earlier to confirm that opening truefalse-raw.mp4 had a
different number of audio vs video keyframes for you too? (2461 video, 2463
audio?) I _think_ the tracks stay in sync and it just saved slightly different
amounts of data to the audio and video channels when I stopped
simplescreenrecorder? This was one big problem I had with my first try at video
capture/editing a few years back, the audio and video would gradually go out of
sync as the video played. Possibly 5 frames/second is too few to give blender
breathing room. (I dunno what the mp3 encoding granularity is; what's the audio
idea of a "keyframe"?)

>> I can see your encoding parameter with ffprobe, but I want not able to
>> reproduce the size of simplescreenrecorder with ffmpeg even with lower
>> bitrate and less fps. I guess it is a mixture of detail config, reencoding
>> noise and the croping while keeping the resolution.

What I really want to do (at the moment) is just excise frames from the original
encoding to chop together the subset I want to keep. I'm not even trying to
reorder stuff, just trim it the way they used to literally cut film stock.

Alas, none of the tutorials consider that an interesting use case. I learned how
to do it with VLC from the command line long ago, but there you have to specify
the start/length in seconds and fractions of a second to write separate clips to
individual files and then you can play them back together as one big file, and
it's just so AMAZINGLY tedious to do it that way. (Playing it in VLC to find the
times to then cut...)

>> I will check the chrome issue. This should not happen because afa I know
>> ffmpeg is a Chrome dependency (it is never fun to compile browsers).

What I plan to do is:

1) Have downloadable videos in my directory on the website, with an index file
that's a simple <ul><li>file1</li><li>file2</li></ul> linking to each individual
file in the playlist.

2) Upload each video to patreon (they've partnered with vimeo for that).

3) Sigh, eventually upload them to youtube. (It's like github, it's where people
expect to find this stuff. But every video that gets copyright claimed because
of John Cage's 4'33 or some such is being privated and NOT getting fixed there,
and Google can take darn the PR hit. I am aware of games like
https://www.youtube.com/watch?v=Mz14Ul-r63w and I'm just not interested.)

Anyway, two of those three are going to re-encode the result anyway, so I'm not
THAT worried about the efficiency of the result. And there's also something
called "peertube" that I can theoretically install on my fiber connection...

>> I will remove the crop from the cut so that fullscreen is shown again. This
>> will also result in better encoding size.

I'm on the fence about the crop. The main reason I wanted to see your edit is to
see what your idea of "success" looks like, and you cropped it. The first
exercise I'm trying to do with Blender is reproduce your edit so I know I _can_,
and at the moment that includes the crop.

Thank you very much, your work HAS been very helpful. (And you've been very
encouraging.) I was sick for a large chunk of last week (nonzero chance I caught
Omicron last month but the tests didn't arrive until a week late to know), and
then I got surprisingly distracted by Ukraine. (Putin funded Trump and Brexit,
bad things happening to that man is directly relevant to us here. Heck, the
Mueller report was about Russian interference in our elections and Trump's
impeachment was over him trying to blackmail Zelensky to make up political
attacks about the current president's son or else he wouldn't help them rearm
against Russia. Someone actually directly fighting BACK against Putin is
enormously encouraging and could potentially reshape our domestic political
landscape. The sanctions alone cut off the funding to the domestic terrorists
behind the January 6 capitol insurrection and that stupid canadian trucker
stunt last month. And at the same time it's a giant humanitarian tragedy with
a bully ordering the mass murder of innocent people that SHOULD NOT BE
HAPPENING... Ahem, as I said, I'm spending a lot more attention on it than I
expected to. But I need to get back to work...)

On 3/2/22 Rob Landley wrote:
>> Hi Rob,
>> cropping removed (fullscreen), works (at least) in (my) Chrome, VLC,
>> MediaPlayer and ffplay now, size is down to 6MB with no artefacts (h234 vs
>> libx264 was the issue and the solution to problems mention so far).

Yeah, h234 played for me in chrome too. (VLC can play just about anything, I
haven't got mediaplayer of ffplay here.)

>> I never heard of a "audio keyframe". In audio you normally have sampling
>> rates.

Yeah but it does fourier transforms to extract repeated waveforms out of the mix
and I dunno how long those are? (As with many areas, I know just enough about
the implementation details to have a much bigger canvas for being wrong about it.)

I guess if it extracts the audio to a .wav file and then redoes the fourier
search later it has sample rate granularity it can cut at. I was just kind of
hoping it didn't have to so it could avoid lossily re-encoding. But then I was
hoping the video could do that, and it doesn't seem to have. :(

>> Videos have key frames to render a full picture instead of a diff/delta.
>> Video players are actually audio players with a slide show on top. So,even 5
>> fps does not affect the audio.. I just tells the audio player to show 5
>> slides per second ;-).

Entirely possible I should record at a faster frame rate just so I have better
editing control. Blender is cutting at video frames and the start or end of a
word at 5x/sec gets bit jumpy.

>> Editing in general needs too much time. Even if it is just trimming and
>> cutting parts. And at least for me I need a different part of my brain than
>> for programming. It is less logic and structured and more creative and
>> aesthetics oriented. It helps me unwinding from other stuff. But it is not
>> helpful for me to switch between editing and programming forth and back.

Editing is always time consuming, that's not specific to video. Writing
documentation or blog entries or long emails is just quickly dashing off stream
of consciousness stuff, editing it to sound COHERENT is always the hard part. :)

How Star Wars was saved in the edit: https://www.youtube.com/watch?v=GFMyMxMYDNk

(There was a similar one about Star Trek II. I'm told there was a cut of Star
Trek I that was only ever played on airlines that was an AMAZING movie, but the
theatrical one was just terrible. Similarly, if you ever have the chance to
watch the extended cut of Blues Brothers on the anniversary DVD, make darn sure
you've seen the original movie first because the extended cut is TERRIBLE. The
pacing is entirely destroyed and nothing is funny. Brilliant movie becomes
absolutely boring. The SAD part is the original edit is no longer available
because Lucas went back and screwed it up again. You have to track down the
Despecialized version. I'm also told The Phantom Edit of the first prequel is a
much better movie than the theatrical version, but nobody can legally watch it
of course...)

>> Most efficient thing for 300 videos is an ffmpeg pipeline that does
>> everything over and over again. But ffmpeg does not solve the trimming and
>> cutting problem in advance.

Exactly. I could have scripted the VLC cutting but using VLC to find WHERE to
cut was just too painful. (Enabling "audio scrubbing" and advancing by frames
with the little frame navigator at the bottom's forward/back arrows is just
about tolerable.)

>> I know you dont want to commercialize you stuff,

Eh, if I could make a living off this so I didn't have to do other stuff I
wouldn't mind. I'm just not big into side hustles and don't trust Youtube not to
implode into a legal quagmire. Everybody who depends on it for money turns into
a nervous wreck:

https://www.youtube.com/watch?v=MyTa54dYsEA
https://youtu.be/Hdh4YqcTDTU
https://www.youtube.com/watch?v=Ku1ykhGP764#t=1m33s
https://www.youtube.com/watch?v=BSshu6yCoFo
https://www.youtube.com/watch?v=Z9vW_MpXTfs
https://www.youtube.com/watch?v=r5lMM160etI

>> but you might think about adding 5sec in the end of your video listing
>> references to landley.net, Patreon, github.com/landley/toybox etc.

That's a good idea, and I probably should.

The ones I uploaded I didn't crop to just the window, and I didn't save the
first one's blender file that would let me re-cut the original video without
re-encoding and presumably having a quality loss. (Although it's short and not
that hard to redo.)

I was thinking of putting a patreon graphic on the right side but haven't got
one. Full screen would be easier (whip something up in HTML and screenshot it).
Hmmm... I'm tempted to upload the raw footage to patreon as a bonus. (Hear me
sound MUCH LESS SMART, and also complain at xfce bugs and the UT clock tower,
lose my train of thought and repeat myself...)

(You know where I should upload them to be hosted? Archive.org. Hmmm...)

> > Let me know, if you need further recording cut.

Thank you. I'm slowly to developing the skills to actually do this, I think?

There's somehow less pressure speaking in front of an audience for half an hour
or more, in that context it's just a hobbyist enthusing about their project and
I'm not SUPPOSED to be that together. This is the short story version where
every second is relevant. Much less experience doing that, but finally being
able to edit the result makes it much easier. (I didn't want to record a bunch
of videos I couldn't edit and intimidate myself with a giant pile of backlog,
but... this seems pretty doable. I expect I'll get faster as I go along? Editing
in blender is less awkward than editing text in vi, and ctrl-Z is my friend...)

Rob


More information about the Toybox mailing list