Why I want to switch to DaVinci Resolve 15

There’s one thing–only one thing–that keeps me stuck on Windows 10 on my laptop, and that’s my need to edit video for the Category5 TV Network. It has to be pro, and Linux has traditionally lagged far behind in its available offerings in comparison to Mac or Windows when it comes to video editing.

I’ve used Cyberlink PowerDirector for years. I know, it’s a cheap application and professionals will laugh at me. But fact is, it works very well, and has all the features I need to make a professional looking broadcast.

But it only works on Windows, and so I’ve been stuck on Windows.

I’ve been watching the progress of DaVinci Resolve from BlackMagic since it was first released, and even tried getting it going a few times, but it’s always been unstable on Linux. So I’m still stuck. But seeing video tutorials about it, and watching the changelogs, it really looks like it could be the video editor of Linux.

I installed LMDE 3 to see if it would take DaVinci Resolve, and I see BlackMagic has still not made any strides toward improving Linux support. The installer sucks. The software depends on old libraries, yet doesn’t install them. It’s trash, really. A sad state to be sure.

I’m going to do some tinkering, try moving over to Linux Mint to see if the Ubuntu base helps things (ie., proprietary NVIDIA drivers will probably be a bit newer), convert Resolve’s installer to a deb pack, and try installing it there. I’ll probably go through a few distros just trying to see where I can get Resolve working stable. I have v14 working on our family desktop computer running Ubuntu, but it’s unstable. Hoping for better results with Resolve 15.

So beyond the Windows requirement I’m currently under, there are a few things I absolutely require out of my video editor, and these are things that have prevented me from being able to move to a Linux editor in the past, but DaVinci Resolve appears to meet the requirements.

ProRes 4:2:2 editing. Yeah, I need that now that we’re recording to an Atomos Ninja Flame. Cyberlink PowerDirector handles ProRes files like a boss. I know DaVinci Resolve will do the same.

When I produce shows like New Every Day, I badly need multi-cam editing functionality in my editor. We only have one camera on that set, but because it is 4K we punch in to cut it into 3 different camera shots. In Cyberlink Power Director, I assign each of these “cameras” (punched-in shots) to keyboard keys, and simply press the key to change cameras. It automatically creates the edits on the timeline, and saves me a TON of editing work, while making the show appear like it has 3 cameras. I’ve even thought about getting a second StreamDeck (or even a mini) just for multi-cam editing.

Multi-Cam Editing looks just as good, and possibly better in DaVinci Resolve than it is in Cyberlink PowerDirector. Though this video doesn’t mention anything about keyboard shortcuts, I can’t imagine you actually have to use your mouse to switch shots. If it does not have keyboard-based switching, I’d have to give this one to Cyberlink PowerDirector, but it’s close enough to make the transition to DaVinci Resolve work.

Dynamic Zoom is just as easy in DaVinci Resolve as it is in Cyberlink PowerDirector. I use this heavily to give the punch-in shots some movement as if there’s someone operating the faux camera.

So there are a few reasons I think DaVinci Resolve might be ready, and might be able to help me transition fully to Linux on my laptop. As long as it is stable. Here’s hoping!

[Update]

Linux Mint 19 took DaVinci Resolve like a champ! Just had to install libssl-dev and ocl-icd-opencl-dev with apt, and it loaded up just fine! No other tricks or gimmicks, and no having to create symlinks to libraries!

Obviously I had to active the NVIDIA drivers, and Resolve warns me performance may suffer on my old lappy, but I’m running!

DaVinci Resolve 15 running on Linux Mint 19

[Update 2]

Okay, so it’s running. However, even with gstreamer-plugins, vlc, and Mint’s multimedia codecs installed, Resolve only sees the PCM audio for MP4 files shot on the Sony FDR-AX53, which are XAVC.

XAVC-encoded video from the Sony FDR-AX53 is only showing as PCM Audio in DaVinci Resolve 15 on Linux Mint 19

At the same time, there is no audio coming out of the speakers, though DaVinci Resolve 15 is the first version to include native audio support (using ALSA) in Linux.

So I’ll try converting the video to ProRes using the format settings I see in mediainfo C0001.MP4:

I go to try it to see if it worked, and immediately start to think my old laptop might not be up to the task.

On the plus side, converting the video to ProRes worked (having rebooted, I can load it):

And there is sound now that the video has been converted!

But, it seems a sad fact that my computer is not up to the requirements to do this. Yet it works perfectly in Windows 10 with Cyberlink PowerDirector. So disappointing.

I’m going to continue tinkering with settings to see if I can squeeze some life out of this old girl.

Nerdgasms

I’m going to start posting any little helpful tools I create to make my life easier. I call them Nerdgasms. This list will grow over time, so be sure to check back!

  • Set Linux Time and Date
    NTP won’t help you if your date and time are too far out of whack. This has become even more so of a problem with single board computers that do not have a realtime clock. Power it off too long and you’ll lose your settings. This Nerdgasm is the easiest way to figure out what you need to type into the terminal to set your Linux system’s date and time.

NTP on Debian reporting 95 years in the future – Part 5: Patching the Kernel

If you haven’t read part 1 yet, make sure you start there.

Okay — I can’t wait 24 hours — I’m an eager beaver. But 14 hours later, the system is still showing the correct time. Let’s play.

Okay – so I’m on the absolute most amazingly modern kernel ever. Great! So let’s fix that kernel.

We’ll check again to see if the timer workaround is implemented in our kernel:

So what does this tell us?

CONFIG_FSL_ERRATUM_A008585 shows whether the workaround for Freescale/NXP Erratum A-008585 is active. The workaround’s description is “This option enables a workaround for Freescale/NXP Erratum A-008585 (“ARM generic timer may contain an erroneous value”). The workaround will only be active if the fsl,erratum-a008585 property is found in the timer node.”

For those who are even nerdier than me, check out kernel.org’s log of the patch here: https://patchwork.kernel.org/patch/9487241/

You’re such a nerd!

Now I’m getting into the experimental. I’ve never changed a kernel config before. Funny, that. I guess if you’ve never needed to do something, you never learn to do it.

I have yet to find online instructions for doing this, and here’s what I’ll try.

Note for tl;dr – this didn’t work.

Alright, let’s change my default config as we prepare to re-compile the kernel. I’m unsure if changing this config will make the newly compiled kernel receive the change or not, but it’s worth trying.

Great, my config is now set to include this patch.

Okay, I’m obviously gonna need the kernel headers here…

Looks good, and the default setting is the same as my running kernel config:

Great! I think I’ve made a connection… this file has the same setting as my default kernel config.

So since I’ve already updated my own config, let’s compile with oldconfig – I’m assuming that means “grab the old config”… hmmm…. makes sense to me.

Alright, is it set now?

Weird… the setting is gone! Well, let’s see what happens? Maybe the kernel will default to “yes” if the setting … let’s try.

Oh – If it’s going to ask me to say yes to a crapload of defaults, I’ma abort that!

I’ll trust the kernel devs and my config 😛

Wow, that’s a lot of output.

Now, a quick reboot and re-connect, and then check the running kernel…

Darn.

Strangely, the default config (my config) shows that my setting remains there…

So maybe I just didn’t compile it correctly.

I wish someone in the threads would have posted how to actually add this. I mean, as a teacher, I try not to make assumptions. Saying to someone “set CONFIG_FSL_ERRATUM_A008585=y in your kernel” is a big assumption. Even I, the Bald Nerd, am not quite sure how to do that, yet I’m sure the people who make the statements are. Let’s instead post the actual commands or at least point the person in the right direction.

I’ll try to figure it out in the next couple days, and will post my step-by-step. I’ve posted a cry for help in the forum thread related to the Debian image I’m using. Hopefully they can point me in the right direction.

UPDATE: Ohmigosh, it just hit me… this is using make, yet I didn’t install!

Let’s try it, just for good measure:

Grr….

Yeah, there’s no install.sh there.

I’m sure it’s something simple I’m missing since I’m not experienced at this kind of thing.

More to come!

NTP on Debian reporting 95 years in the future – Part 4: Back To The Past

If you haven’t read part 1 yet, make sure you start there.

I had a great idea after posting part 3 last night… why not try to set the interface as static so DHCP isn’t impacted? That way, I won’t have to re-flash to an earlier image. So I stuck the SD card into my SD reader and low and behold, /etc/network/interfaces is accessible! So I commented out the DHCP line and set it instead to the static IP I have reserved for it, and low and behold, I’m up and running.

And to boot, get this:

That’s right… the date is correct after booting this way.

Strangely though, there are no updates in /var/log/dpkg.log – the last entry was in 2113.

Another interesting anomaly when checking the ntp service:

Hmm, yeah… it has been running for over 95 years. Yet the date is correct on my system now.

Hmm….

So, let’s just try…

And… wait for it….

Sweet.

Okay, so let’s leave the server running for 24 hours and see if this is a DHCP-related issue.

To be sure, I have indeed checked my router to make sure it’s not serving up bogus NTP timestamps, and it’s all good.

What’s Next? Read Part 5:

NTP on Debian reporting 95 years in the future – Part 5: Patching the Kernel

SBC Distros I’m Working On

Those who follow me closely in the SBC world know what I’m up to, generally, but I thought it’d be fun / useful to list some of my main distros I am working on.

NEMS Linux
This one is pretty darned obvious. My most popular distro to date. Learn more at https://nemslinux.com/

PlexPi
Plex Media Server for the Raspberry Pi 3/3B+. I may eventually port this to more powerful SBCs as well. I think it’d do amazingly on a RockPro64. https://plexpi.com/

Retropie-based Retro Gaming Distro for ODROID XU4 + others
Yet to be named build to port Retropie properly to the XU4 and other SBCs where it is either not yet [well] supported or onerous to configure.

Camera System
Yet to be named Raspberry Pi distro to turn any supported IP or USB camera into a sophisticated webcam ideal for weather stations, resorts, hobbyists. Not intended for surveillance, though it could be used for this too. Includes an impressive deduplication system I wrote which reduces the number of stored images by matching their image data: if there is no change in the scene, the image is not saved. Also allows stream relaying from an RTSP compatible IP camera or standard USB webcam to YouTube Live (video only), interval-based snapshots with automatic upload to web, and more. My hope is that I can turn even a Raspberry Pi Zero W into a very impressive webcam system.

Turnkey Servers
I plan to release some turnkey servers for SBC such as WordPress, LAMP, XMPP and so-on. Many of these will be in competition with existing turnkey builds, however I feel my Migrator off site backup system will help my builds stand out from the pack.

Alexa for Raspberry Pi
A fair few tutorials exist that help a user build an Alexa-powered assistant device out of a Raspberry Pi, but I’d like to see a streamlined distro built around the concept… so I’ll build one.

Which project has you most excited?

NTP on Debian reporting 95 years in the future – Part 3: Community

If you haven’t read part 1 yet, make sure you start there.

Hooray! I am not alone, and it does indeed appear to be a Pine64-specific issue. That means I’m not crazy. Or at least, this issue doesn’t prove my craziness.

  1. https://forum.armbian.com/topic/3458-a64-datetime-clock-issue/
  2. https://forum.armbian.com/topic/7423-pine64-massive-datetime-clock-problem/

Looking at martinayotte‘s suggestions, since he seems to have been through what I’m going through right now…

Okay, so just in case they fixed it already, let’s just try…

Hmm, it seems apt doesn’t like time travelers like me. So … [le gasp]…

Wait for it….

Like trying to play my 8-track cassettes in a Blu-Ray player, apparently some services don’t play nicely 95 years in the future. DHCP is showing locally on the TTY splash screen as 127.0.0.1, and the only way to recover will be to re-flash to a point before the NTP issue struck.

What’s next? Read Part 4:

NTP on Debian reporting 95 years in the future – Part 4: Back To The Past

NTP on Debian reporting 95 years in the future – Part 2: The Time Traveler

If you haven’t read part 1 yet, make sure you start there.

This issue has really intrigued me.

Setting the date manually fails:

Invalid argument? Maybe it wants me to set the time too?

Nope, that made no difference.

Well, what does my hardware clock say (since the Pine A64+ has one)?

Oh yay, that looks better! Let’s use that! Obviously the system knows the date and time…

Oh, COME ON!

Maybe I’ll try the long-form command…

Nope. Same result. Ach!

This is looking a lot like an old kernel bug I recall from the late 2000’s. Better check what kernel I’m running…

If I had hair…

Just to be sure, let’s reconfigure my timezone config:

Okay, so let me get this straight… it’s August 28, 2113. But it’s July 5, 2018 according to the RTC.

Think, Robbie, think.

I did a quick grep through the /var/log folder for anything talking about ntp, and interestingly, I find this at the top of dpkg.log:

So on first boot, the system had the date correct: July 4, 2018. The time is off by a couple hours however (it was perhaps 6am when I flashed and fired up the system and then left for work).

What’s interesting here is that the typical ntp startup tasks unpack, install and run, but then after the package is installed (a presumably automated process since I didn’t do it!) the date suddenly changes to August 27, 2113.

Being a Raspberry Pi user all my SBC life, I’m honestly impressed that the Pine A64+ has a built-in RTC… but nowhere in the specs do I see that it also includes a corresponding flux capacitor, so I must presume the jump through time is more likely a glitch in the matrix.

I’m afraid to reboot.

What’s Next? Read Part 3:

NTP on Debian reporting 95 years in the future – Part 3: Community

NTP on Debian reporting 95 years in the future – Part 1

Here’s one for the “I’d pull out my hair if I had some” files…

I have a wee SBC (a Pine A64+) I’m porting NEMS to, and everything was sweet for a day… working fine, all looks good. So I left it running.

Next day, while the system clock shows the correct date and time, the UTC and Local time are off by 95 years!

Now, I admit, it’s nice seeing a NEMS server that’s been up for that long 😛 but it’s very curious.

Logging into NEMS Linux, I find another oddity…Apparently my last login was in 1977.

Here is a picture of how that might have looked:

I’m pretty confident that my little Pine A64+ has more power and capacity than the supercomputer shown. Chances are good it also cost a bit less.

So it’s time to start digging… where did NTP get this ridiculous 1292443255.246538 second offset from, and why? And how to correct it?

What’s next? Read Part 2:

NTP on Debian reporting 95 years in the future – Part 2: The Time Traveler

Aquilo – Sorry

The moment I heard this track on 181.fm, I had to turn it up. I love its simplicity, and how the vocal is so cutting and powerful that you don’t even realize there are basically no instruments during a large portion of the song. I’ve never heard of Aquilo, but he kind of reminds me of when The Eden Project goes falsetto. I just love this track. Beautiful.

It’s turtle time! Turtlecoin, that is.

I’ve been mining TRTL for a little more than a week now, and it’s a blast.

Turtlecoin is fast becoming recognized for its amazing community.

One of the fun ways to obtain TRTL is by participating in a raindance.

A raindance happens when anyone donates 5,000 TRTL or more to the rainbot. At that time, it starts to “rain turtles” and anyone who “catches” them gets an equal portion of the rain. For example, if someone contributes 10,000 TRTL to the raindance and 100 people participate, each participant will receive 100 TRTL.

What makes it intense is that you only have 90 seconds to send the rainbot your wallet address and then click the icon that corresponds to the instructions you get back from rainbot. 90 seconds sounds like a long time, but when the rain is falling in a typhoon, it can get crazy.

Next Friday (a week from today) is going to be the most exciting raindance I’ve ever seen. Rather than donating to rainbot, everyone is meant to set their mining software to mine directly to the rainbot’s wallet. With enough participants (they’re expecting 160 or more) the rain could fall every 90 seconds!

I will be livecasting the Turtle Typhoon on YouTube, so make sure you subscribe to https://youtube.com/category5tv to get the notification when we go live!

Find out more about Turtlecoin at turtlecoin.lol. Make sure you get your wallet address setup in advance (so you can collect rain), and when you’re done, I’d welcome you to consider donating a portion of your TRTL to supporting Category5 TV.

Our wallet address is:

Here is the event announcement. You can check for updates by visiting their Discord and typing !tag typhoon

Turtle Typhoon – Mine the Storm!

You are Invited to the Raindance Party!

**From 8pmEST/1amGMT on Friday 9th March**

**THE RAIN PARTY WILL COMMENCE POWERED BY OUR MINING COMMUNITY**

If you would like to join the raindance here’s how to get started (rain will occur randomly before the set date also): http://github.com/turtlecoin/turtlecoin/wiki/Participating-in-Raindance

If you are mining TRTL and would like to donate to the rainbot during the Turtle Typhoon simply change your wallet_address in your xmr-stak config to the raindance donation address.

The raindance donation address is: