Profile cover photo
Profile photo
we're telling a new story
we're telling a new story

Novacut's posts

Post has shared content
Step 1: make something
Step 2: rejoice
Happy holidays! Let's create something together this holiday season. Here's some inspiration to get you started and instructions to make your own holiday light project.

#DIY #RaspberryPi #makerspace #creatoremakebuilder

Post has attachment
Dropping support for V0 protocol and schema

The V1 Dmedia hashing protocol, V1 Dmedia document schema, and V1 Novacut document schema were finalized over 29 months ago (on June 1st 2013):

My feeling is that this has given folks ample time to migrate any existing V0 libraries to V1. However, if anyone out there has an existing V0 library and needs help migrating it to V1, please let me know and I'll happily help!

Still, there is a cost in maintaining the V0 to V1 migration path, especially considering some refactoring I'd like to do in the near future. The V0 to V1 migration was unusual in terms of what we expect going forward, and the code for it is rather crufty.

So this migration path has now been dropped in our daily PPA builds for Ubuntu 15.10/Wily and Ubuntu 16.04/Xenial.

Note that support for this migration path is still present in our daily and stable PPA builds for Ubuntu 14.04/Trusty and Ubuntu 15.04/Vivid, and that support is still present in our stable PPA for Ubuntu 15.10/Wily. The current stable release for 15.10/Wily will be archived in a separate PPA prior to releasing a new stable release for 15.10/Wily that drops support for this migration path.

At this time, no further stable releases are planned for Ubuntu 14.04/Trusty or Ubuntu 15.04/Vivid, so Novacut releases that support the V0 to V1 migration path will be available for as long as each respective Ubuntu release is supported (almost 3 years more for Ubuntu 14.04/Trusty, and about 2 months more for Ubuntu 15.04/Vivid).

This is all part of an effort to trim some fat in preparation for a (hopefully) exciting Novacut release for Ubuntu 16.04/Xenial, the next Ubuntu LTS release.

Finally, note the plan is to indefinitely support the V1 hashing protocol, and to indefinitely support migration from the V1 document schema to whatever document schema version Dmedia and Novacut currently use.

Post has attachment
Dropping support for GStreamer 1.2/1.4 (Ubuntu Trusty/Vivid)

In terms of the needs of Novacut, +GStreamer 1.6 is an absolutely stunning release! So a huge thanks to everyone in the GStreamer community whose hard work made it happen!

The new rendering backend introduced with Novacut 15.08 was written to work with GStreamer 1.2 through 1.6:

However, as we refine our new rendering backend and prepare to start adding new features, the burden of continuing to support GStreamer 1.2 and 1.4 has become difficult to justify. GStreamer 1.2 is especially problematic as it requires many work-arounds and even then can't always produce correct results (not even with perfectly conformant input videos).

As these new Novacut features will likely be a bit rough around the edges at first anyway, it seems like a good time to stop making new Novacut releases on Ubuntu 14.04 LTS (Trusty) and Ubuntu 15.04 (Vivid). Instead, we'll set our sights on a great Novacut release for the next +Ubuntu LTS (Ubuntu 16.04 LTS, due out in April 2016).

So as it stands now, the plan is that Novacut 15.08 will be the last Novacut release that supports Ubuntu 14.04 LTS and Ubuntu 15.04. In the meantime, you'll still be able to install Novacut 15.08 on Trusty and Vivid as those builds wont be going anywhere. But during the next 6 months, new Novacut releases will only be made for Ubuntu 15.10 (Wily) and Ubuntu 16.04 LTS (X).

Depending on how things shake out, we might make additional releases that support Ubuntu 14.04 LTS for some of the six components beneath Dmedia in the Novacut stack (UserWebKit, UserCouch, Microfiber, FileStore, Degu, and Dbase32). But as Novacut and Dmedia both directly use GStreamer, their future releases will only target GStreamer 1.6 and newer.

Our long-term goal is to support new Novacut releases on the current Ubuntu LTS till the next Ubuntu LTS is released, and we came pretty close this time around (the closest we have thus far, actually). But change happens and sometimes you need to cut your losses and move forward :)

Apologies to anyone negatively impacted by this plan. I'm confident we can make it up to you with exciting future Novacut releases that will be waiting for you whenever you're ready to upgrade to Ubuntu 16.04 LTS.

+Jason DeRose 

Post has attachment
Been working on bringing the same obsessive frame accuracy to our real-time playback that we now have in our rendering engine (the former is to preview your work in progress as you edit, the later is for rendering the final result out to a file).

The video below is a programmatically generated edit that was used for testing the experimental real-time playback stuffs. But the result was too neat not to render it out and share :D

It's built from slices 5 frames in length such that the next slice starts 10 frames ahead of where the previous slice ended. For example, here are the exact first four slices this very edit starts with:


You can see the full edit description in geekier form here:

The crazy bit of letters before the Python-esque slice syntax is the Dmedia file ID for this particular clip. It's the same on every line because every slice is taken from the same file.

So in fact it's a globally valid and perfectly unambiguous description of this edit. Because that's how we roll :)

Post has shared content
More details coming soon. Big thanks to +David Jordan for all his help on this, and for coming up with the design for the new rendering backend!
Still need to write up a blog post and Kickstarter update on this, but +Novacut 15.08 is out now and in our stable PPA!

Post has attachment
New rendering backend stability and accuracy test

Feature length edits are complex (lots of slices). And, of course, we need to deliver perfect frame accuracy in every render, every time.

In real-word feature length edits, probably around 5k slices is about the most you'd encounter. But to make sure we can really achieve that consistently, +David Jordan and I decided 10k slices would be a good stability benchmark.

So I took a video with 13,054 frames and expressed it as 13,054 one-frame slices in reverse order. This is a nice test because it's quite easy to see visually whether you pretty much got what you expected. And I've done multiple other independent checks on the accuracy to confirm we're getting exactly what we expected, including checking that the output video has the exact expected number of frames and the expected timestamps.

 Even though each slice in this case happens to be from the same file, Novacut treats them the same it would if each slice was from a different file.

For each slice as it goes through the sequence, the rendering backend builds up one of our Input decoder instances (which is just a thin wrapper around a GSstreamer Pipeline with filesrc ! decodebin ! videoconvert ! videoscale ! appsink). It seeks to the first frame in the slice, and then puts a Gst.Buf into the output buffer queue for each frame in the slice (which in this case will always be only one frame).

Post has shared content
A very productive 4 days. We expect this work will land in a new Novacut stable release later this month.
The new rendering backend by me and +Jason DeRose has been exposing the quirky ways gstreamer elements play with timestamps all weekend.  By providing perfect timestamps, we're getting a great look at how each encoder and muxer wrangles and mangles the data. 

First, we noticed that GStreamer's Matroska muxer zeroed out everything after the millisecond.  MKV's official spec has a TimecodeScale property, which indicates the granularity of the actual timecode (defaulted to 1000000...which indicates the timecode is in milliseconds.  Setting TimecodeScale to 1 would give nanosecond precision.)  Sure enough, matroska-mux.c sets the value to GST_MSECOND...1000000. 

Next up, we found weirdness in qtmux when using x264 unless the keyframe interval was set to 1 (all keyframes).  Using mjpeg with qtmux also resulted in well-behaved timestamps.  This is probably partially the result of x264 weirdness, but we think qtmux is doing some odd things of its own.

Theora/Ogg was pretty well-behaved too, but would rarely be off by a single nanosecond.  

Also, qtdemux appears to set the framerate by looking solely at the duration of the first timestamp.

#NovacutHackfest #GStreamer #Timestamps

Post has attachment
+David Jordan working hard at the hackfest. Plus, this silly clip was rendered with the new experimental Novacut rendering backend.

Post has shared content
Let freedom ring
Wait while more posts are being loaded