background-shape

Part 1: Using mk_screencast_label rather than adding screencast urls to blog posts after uploading


In this screencast I am setting up a cleaner and less fiddly system for uploading videos of screencasts and pairing them with blogposts. Instead of generating the names for screencast files after the fact when the screencasts are uploaded. We first generate the file names and then set the names of the uploaded video assets according to the generated names.

To generate a new screencast name, you run:

./gradesta-s.r.o.-commercial-stuff/interal-tooling/mk_screencast_label

To publish a screencast, you then run

./gradesta-s.r.o.-commercial-stuff/interal-tooling/publish_screencasts <name-of-blogpost> <name-of-screencast-file.mkv>

You can have multiple screencasts per blogpost, you just list them as multiple arguments to the publish_screencasts commandand.

./gradesta-s.r.o.-commercial-stuff/interal-tooling/publish_screencasts <name-of-blogpost> <name-of-screencast-file.mkv>  <name-of-screencast-file-2.mkv>

The publish_screencasts command uploads the screencasts to an EC2 spot instance with transcodes them from OBS’s native mkv format to the web’s much smaller and smoother streaming webm format. The ec2 spot instan the screen cast to DO spaces.

diagram showing flow of screecasts during publishing

Part 2: Thinking about how to make this work in a team

So I’ve decided not to transcode the videos on the cloud afterall. I don’t have the time to set it up and its not strictly necessary. Instead, I will simply transcode locally using ffmpeg as I have done in the past. I still need to write a script that extracts the screencast id tags from the blog entries, does the transcoding locally, and uploads them to the CDN.


Part 3: Beginning to write the screencast management software in rust


Part 4: Looking at various ways of parsing the blogpost HTML


Part 5: Parsing out tags with nom


Part 6: Building the upload command dependency DAG and running the upload commands

I use the daggy package to build a dependeny DAG of commands that are run in parallel, in order of dependeny fulfillment, sort of similar to make.