Launching Video
by Bob Bloom
category: "video production"
The heart of my new projects is sharing what I learn about serverless as I progress with my own project.
How to I share what I learn about PHP serverless? I thought streaming was the way to go.
See what I go through in real-time. Join in the journey. Interacting with my peers enhances the experience for you and me. We learn together.
Wrong ☺
I did a dry-run of this idea. I have one word to describe it: boring.
Watching my own "proof of concept" stream was boring. I found myself waiting for "the good stuff". The journey was not that interesting to watch. The nuggets of learning is the interesting stuff. An hour of streaming may yield a couple of minutes of nuggets. It is those nuggets that interest me.
My initial notion was to share in my journey. But I nixed that idea early, understanding that sharing what I learned is the important thing.
Why not publish excerpts of my stream? Stream as usual, but instead of publishing the recording of the stream as-is, excerpt the interesting parts, and just publish those excerpts.
Testing this idea of publishing direct excerpts of my stream did not quite work out. Cutting from one snippet to another snippet to another snippet made for a disjointed production. It was hard to follow.
Next idea: instead of excerpting a stream, summarize a stream with a separate screencast. Just assemble the essential stuff, and present it in a seamless screencast.
Testing out screencasts went very well. Very well. So well that I put together a real screencast.
I used OBS to do my screencast. OBS converts the screencast into a video file. My intention was to upload this video file directly to YouTube.
But in what proved to be a fateful decision, I decided that I would bookend my screencast with an intro and an outro.
One common intro for all my screencasts. And one common outro for all my screencasts. Which means that I need to put together an intro and an outro. And then I need to fuse the three videos together into one video to upload.
Which means that I need to fire up a video editor. What video editor did I use? DaVinci Resolve.
DaVinci Resolve is awesome. I cannot believe that it is free. It is also intimidating ☺ It took a bit of time to get a sense of it, to even get a comfort level traversing it. In the effort to learn the basics came a new-found appreciation for the potential of video. What I conceived as a tool to append one video file to another turned into something completely different: producing videos as the primary means of conveying what I learn about PHP serverless.
And so it came to be that I got into video production. The potential of video opened up before me, and I have not looked back since.
Producing my first video for my new open source PHP serverless projects turned into quite the journey. Learning DaVinci Resolve just enough to produce a watch-able video was a significant effort. Very thankful to have podcasting experience, and to have dabbled with various video editing software over the years. ,
Of all things, watching a video about using PostgresSQL helped me under DaVinci Resolve. How handy it is to be a dev ☺ A light went off. I realized that DaVinci Resolve does not have a native file format ☺
GIMP has a native file format. Audacity has a native file format. Both use an export feature to save to well known image and audio formats.
DaVinci Resolve does not have a native file format. There is "Save Project" menu item, but this action does not create a native DaVinci Resolve file. Oh no, it is doing something else. What is DaVinci Resolve doing when it saves a project?
It is saving to a database ☺
Its save feature inserts/updates to a database ☺
And this database is very involved. It is not one single database. Rather, it is a bunch of XML and SQLite files (I have not tried PostgresSQL).
Interestingly, none of the videos that I watched about the DaVinci Resolve database actually show these database files. It would be very helpful ☺ Probably because they assume that their audience's eyes glaze over when they hear the word "database". they are reticent about digging into the innards of DaVinci Resolve's database, even though this database is a key aspect of the software. The problem is that they are dancing around it, which makes it more confusing.
I am watching these videos to learn about the video editing software. But I am also watching with an eye of producing how-to videos. I took note that after watching a lot of very well made videos by people who are very skilled at making videos, and very skilled with Da Vinci Resolve, I still did not understand this basic aspect of this software. There are multiple types of export, and I was completely lost what they actually did. So I did something that is so common: despite reading articles, despite watching videos, despite poking around the UI, I decided that I was going to just figure it out on my own. And in so doing, I asked myself what value I really got out of the videos? And this means for my own upcoming how-to videos.
I did something on my own that the videos refused to do: I looked at my computer's folders and files. What I found became a monumental "aha" moment. DaVinci stored info in a series of XML and SQLite "db" files.
And what was my tip to look for database-ish files? The word "Postgres" shows up in the DaVinci Resolve UI. So I was looking for actual database files.
The XML files have user-ish, project metadata-ish info. The "db" files have key-values, where the keys are specific software parameters. Well, the software has a lot of parameters. So, I am asking why would they use a real database? Well, I suppose that they have so many parameters to store, that they need a real database to efficiently retrieve them.
So, there is a database at the back, and a beautiful video editing UI in the front. In a sense, the purpose of the UI is to create the database. The database is the video ☺
I thought to myself, looking back at the videos that danced around the word "database", what is the real risk-reward of diving straight into the database? On the one hand, database word that makes peoples' eyes glaze over. On the other hand, the concept is so elemental to understanding DaVinci Resolve, why not take the risk?
It is a case where the payoff in understanding is huge. The way I see it, it is a pain point worth going through, because it makes the software much easier to understand.
I was thinking to myself, is there an incentive for people to dance around this technical topic? And the answer is, maybe. If the goal is to have the widest possible audience, in order to boost views, then maybe the idea of "lowest common denominator" comes into play. I think what is really coming into play is that there is a big worry about abandonment. That people will abandon the video at the word "database". Abandon the video just at the point where the video's monetization potential optimizes.
Whatever the reason, it made a big impression on me that for all the wonderful videos out there, it was left to me to traverse my folders and files to hunt for the database. And what a treasure trove I found ☺ They use a common open source database, not a native homemade database. They use XML files. Which means that I can see the files ☺ I can see values that appear in my software's UI.
So now I understand where the folders are, and that I can put my database in any folder that I want. Which is pretty important ☺
Now I understand that individual videos are stored in database "projects".
But, now I understand that I made a huge assumption about DaVinci Resolve that is wrong. It does not store the audio and video files it uses in its "native" file format. There is no "native" DaVinci Resolve video format. And this non-format is not comprised of all the source files used to create the final video. The database points to the source files. The source audio and video files exist external to the video editing software (which is why there are multiple export functions). This was a huge lightbulb moment for me ☺
I thought: if I were producing videos about this software, I would communicate these insights strongly. Communicate them emphatically. So much so that I would dispense of the usual style I see in how-to videos. Instead of dancing around the word "database", I would pound away in my video that "the database is the video".
Which is how I ended up with my first video being "What is Bref?". Not only will you know that answer after watching my video, but more importantly, you will remember that answer after watching my video. An answer that is relevant, as you ask yourself why you are typing CLI commands for a node framework, for PHP software.
I want to point out something else. Have you seen people play music who look bored while playing their music? If they are bored playing it, then I'm going to be bored listening to it. If I am watching a video, and the person says, this topic is complicated, this topic is technical, this topic is hard to understand, then I am thinking that a topic is complicated, technical, and hard to understand. No matter what other words they use to soften up the topic, I am already putting up mental barriers to protect myself from all the brain-hurt that is coming my way. Invariably, their tone and body language are communicating their aversion, which I am absorbing profoundly. If you are bored playing the music, I am bored listening to you playing your music.
Once I understood how databases work, I started to understand the video editing software a lot better. Enough to put together videos. And then, finally, to start getting a deeper sense of the software. I still have a long way to go ☺
As my understanding deepened, so did my appreciation for the potential of video. Screencasts are linear in nature. Screencasts are done in one take. Video is not confined. I do not have to "work up" to my main point. I can just start with my main point. I can add in things. I can jump around. I can distill things down, and then pound away at it. Which is no small thing, given how frustrating I am finding using Lambda. It's not just Lambda when using Lambda. There is this thing. There is that thing. It's endless all the things, just to get a little "Hello World" PHP Lambda function going.
So it's not the journey getting to "Hello World" that is interesting. What is interesting are the real world lessons I've learned, to convey to you, that will save you tons of time and grief.
In the pursuit of saving you time and grief, I need to focus on the essential pain points. Which means the opposite of dancing around. Which means getting to the point, and doing it fast. Which means video ☺
Which is how it came to be that I am launching videos.
And how it came to be that I added video to my custom podcasting platform. See https://lasallesoftware.ca/video-admin-back-end-and-front-end-ui-done.
How to I share what I learn about PHP serverless? I thought streaming was the way to go.
See what I go through in real-time. Join in the journey. Interacting with my peers enhances the experience for you and me. We learn together.
Wrong ☺
I did a dry-run of this idea. I have one word to describe it: boring.
Watching my own "proof of concept" stream was boring. I found myself waiting for "the good stuff". The journey was not that interesting to watch. The nuggets of learning is the interesting stuff. An hour of streaming may yield a couple of minutes of nuggets. It is those nuggets that interest me.
My initial notion was to share in my journey. But I nixed that idea early, understanding that sharing what I learned is the important thing.
Why not publish excerpts of my stream? Stream as usual, but instead of publishing the recording of the stream as-is, excerpt the interesting parts, and just publish those excerpts.
Testing this idea of publishing direct excerpts of my stream did not quite work out. Cutting from one snippet to another snippet to another snippet made for a disjointed production. It was hard to follow.
Next idea: instead of excerpting a stream, summarize a stream with a separate screencast. Just assemble the essential stuff, and present it in a seamless screencast.
Testing out screencasts went very well. Very well. So well that I put together a real screencast.
I used OBS to do my screencast. OBS converts the screencast into a video file. My intention was to upload this video file directly to YouTube.
But in what proved to be a fateful decision, I decided that I would bookend my screencast with an intro and an outro.
One common intro for all my screencasts. And one common outro for all my screencasts. Which means that I need to put together an intro and an outro. And then I need to fuse the three videos together into one video to upload.
Which means that I need to fire up a video editor. What video editor did I use? DaVinci Resolve.
DaVinci Resolve is awesome. I cannot believe that it is free. It is also intimidating ☺ It took a bit of time to get a sense of it, to even get a comfort level traversing it. In the effort to learn the basics came a new-found appreciation for the potential of video. What I conceived as a tool to append one video file to another turned into something completely different: producing videos as the primary means of conveying what I learn about PHP serverless.
And so it came to be that I got into video production. The potential of video opened up before me, and I have not looked back since.
Producing my first video for my new open source PHP serverless projects turned into quite the journey. Learning DaVinci Resolve just enough to produce a watch-able video was a significant effort. Very thankful to have podcasting experience, and to have dabbled with various video editing software over the years. ,
Of all things, watching a video about using PostgresSQL helped me under DaVinci Resolve. How handy it is to be a dev ☺ A light went off. I realized that DaVinci Resolve does not have a native file format ☺
GIMP has a native file format. Audacity has a native file format. Both use an export feature to save to well known image and audio formats.
DaVinci Resolve does not have a native file format. There is "Save Project" menu item, but this action does not create a native DaVinci Resolve file. Oh no, it is doing something else. What is DaVinci Resolve doing when it saves a project?
It is saving to a database ☺
Its save feature inserts/updates to a database ☺
And this database is very involved. It is not one single database. Rather, it is a bunch of XML and SQLite files (I have not tried PostgresSQL).
Interestingly, none of the videos that I watched about the DaVinci Resolve database actually show these database files. It would be very helpful ☺ Probably because they assume that their audience's eyes glaze over when they hear the word "database". they are reticent about digging into the innards of DaVinci Resolve's database, even though this database is a key aspect of the software. The problem is that they are dancing around it, which makes it more confusing.
I am watching these videos to learn about the video editing software. But I am also watching with an eye of producing how-to videos. I took note that after watching a lot of very well made videos by people who are very skilled at making videos, and very skilled with Da Vinci Resolve, I still did not understand this basic aspect of this software. There are multiple types of export, and I was completely lost what they actually did. So I did something that is so common: despite reading articles, despite watching videos, despite poking around the UI, I decided that I was going to just figure it out on my own. And in so doing, I asked myself what value I really got out of the videos? And this means for my own upcoming how-to videos.
I did something on my own that the videos refused to do: I looked at my computer's folders and files. What I found became a monumental "aha" moment. DaVinci stored info in a series of XML and SQLite "db" files.
And what was my tip to look for database-ish files? The word "Postgres" shows up in the DaVinci Resolve UI. So I was looking for actual database files.
The XML files have user-ish, project metadata-ish info. The "db" files have key-values, where the keys are specific software parameters. Well, the software has a lot of parameters. So, I am asking why would they use a real database? Well, I suppose that they have so many parameters to store, that they need a real database to efficiently retrieve them.
So, there is a database at the back, and a beautiful video editing UI in the front. In a sense, the purpose of the UI is to create the database. The database is the video ☺
I thought to myself, looking back at the videos that danced around the word "database", what is the real risk-reward of diving straight into the database? On the one hand, database word that makes peoples' eyes glaze over. On the other hand, the concept is so elemental to understanding DaVinci Resolve, why not take the risk?
It is a case where the payoff in understanding is huge. The way I see it, it is a pain point worth going through, because it makes the software much easier to understand.
I was thinking to myself, is there an incentive for people to dance around this technical topic? And the answer is, maybe. If the goal is to have the widest possible audience, in order to boost views, then maybe the idea of "lowest common denominator" comes into play. I think what is really coming into play is that there is a big worry about abandonment. That people will abandon the video at the word "database". Abandon the video just at the point where the video's monetization potential optimizes.
Whatever the reason, it made a big impression on me that for all the wonderful videos out there, it was left to me to traverse my folders and files to hunt for the database. And what a treasure trove I found ☺ They use a common open source database, not a native homemade database. They use XML files. Which means that I can see the files ☺ I can see values that appear in my software's UI.
So now I understand where the folders are, and that I can put my database in any folder that I want. Which is pretty important ☺
Now I understand that individual videos are stored in database "projects".
But, now I understand that I made a huge assumption about DaVinci Resolve that is wrong. It does not store the audio and video files it uses in its "native" file format. There is no "native" DaVinci Resolve video format. And this non-format is not comprised of all the source files used to create the final video. The database points to the source files. The source audio and video files exist external to the video editing software (which is why there are multiple export functions). This was a huge lightbulb moment for me ☺
I thought: if I were producing videos about this software, I would communicate these insights strongly. Communicate them emphatically. So much so that I would dispense of the usual style I see in how-to videos. Instead of dancing around the word "database", I would pound away in my video that "the database is the video".
Which is how I ended up with my first video being "What is Bref?". Not only will you know that answer after watching my video, but more importantly, you will remember that answer after watching my video. An answer that is relevant, as you ask yourself why you are typing CLI commands for a node framework, for PHP software.
I want to point out something else. Have you seen people play music who look bored while playing their music? If they are bored playing it, then I'm going to be bored listening to it. If I am watching a video, and the person says, this topic is complicated, this topic is technical, this topic is hard to understand, then I am thinking that a topic is complicated, technical, and hard to understand. No matter what other words they use to soften up the topic, I am already putting up mental barriers to protect myself from all the brain-hurt that is coming my way. Invariably, their tone and body language are communicating their aversion, which I am absorbing profoundly. If you are bored playing the music, I am bored listening to you playing your music.
Once I understood how databases work, I started to understand the video editing software a lot better. Enough to put together videos. And then, finally, to start getting a deeper sense of the software. I still have a long way to go ☺
As my understanding deepened, so did my appreciation for the potential of video. Screencasts are linear in nature. Screencasts are done in one take. Video is not confined. I do not have to "work up" to my main point. I can just start with my main point. I can add in things. I can jump around. I can distill things down, and then pound away at it. Which is no small thing, given how frustrating I am finding using Lambda. It's not just Lambda when using Lambda. There is this thing. There is that thing. It's endless all the things, just to get a little "Hello World" PHP Lambda function going.
So it's not the journey getting to "Hello World" that is interesting. What is interesting are the real world lessons I've learned, to convey to you, that will save you tons of time and grief.
In the pursuit of saving you time and grief, I need to focus on the essential pain points. Which means the opposite of dancing around. Which means getting to the point, and doing it fast. Which means video ☺
Which is how it came to be that I am launching videos.
And how it came to be that I added video to my custom podcasting platform. See https://lasallesoftware.ca/video-admin-back-end-and-front-end-ui-done.