HelpNeeded

Novacut Wiki Home > Help Needed

Here are some tasks that Novacut needs outside help with.

Contents

  1. High priority GStreamer 1.0 bugs
  2. High priority Ubuntu bugs
  3. PySkein in Debian/Ubuntu
  4. Crypto review of Dmedia hashing protocol
  5. GstUriHandler with PyGI
  6. UDisks2
    1. Greedy Import Scenario
    2. Control over some auto-mount options
    3. Re-mount after formatting

High priority GStreamer 1.0 bugs

High priority Ubuntu bugs

PySkein in Debian/Ubuntu

Jason has PySkein on mentors.debian.net but it needs a sponsor.

Crypto review of Dmedia hashing protocol

We'd deeply appreciate further review and critique of the Dmedia Hashing Protocol. The hashing protocol needs to have a long useful life, so we need to have high confidence in it before declaring it final.

GstUriHandler with PyGI

Novacut will have 3 types of "render servers": the playback server, the thumbnail server, and the render server.

Currently our playback is done entirely from JavaScript using a playback trick that James Raymond developed, which uses 2 <video> elements and pre-seeks to the starting frame of the next slice while the current slice is playing. While not what we'll use going forward, this was an excellent experiment that proved there's no reason a multi-core system can't deliver perfectly smooth playback at the transition point from one slice to the next when playing H.264 video from Canon HDSLR or similar cameras.

As this transition point is editing, so to speak, the playback must be flawless. gnonlin currently delivers results that are unacceptable for professional editing, and so we need to fix this.

But we do want to move the playback server to gnonlin ASAP. We can't do multicam and our first round of audio functionality with our current JavaScript tricks. We want all 3 type of render servers to use the same gnonlin composition, assembled in (basically) the same way. Eventually we want the playback server to be in a separate process, but that's going to take some work in WebKitGtk first.

The logical next step is for us to use a custom URI handler that we register in-process, and use this as a way to make WebKitGtk pass control to Python so we can build (and update) our gnonlin composition, but still use the normal <video> element from the JavaScript side of things.

For example, we'd set the video.src to something like this: 

  • video.src = 'novacut://WZWWEGEUSKEGWW5YSTNADIHV/SRRZIZQIZHJ3KDVH3LED2OXA';

Where the URI convention specifies the project ID and node ID like this: 

  • novacut://PROJECT_ID/NODE_ID

Although custom URI handlers are possible with python-gst, they currently don't seem possible with PyGI (see GStreamer bug 679181). So getting this bug fixed is the first place we need help.

We'll also have to provide a WebKitGtk package built against GStreamer 1.0. We really try to avoid overriding existing packages in the Ubuntu archive, but there just isn't any way to avoid it in this case. From talking with Philippe Normand, it sounds like this should be a fairly safe thing to do. Normal apps using WebKitGtk shouldn't have any expectations when it comes to the version of GStreamer, they just need <video> and <audio> to work. And as far as I know, no apps in the default install use HTML5 video or audio.

However, we need to be very cautious providing our own WebKitGtk package as critical apps like the Ubuntu Software Center use it.

UDisks2

See this discussion with David Zeuthen

The Dmedia import workflow is rather class leading. It's possible in large part because we can reach deeper into the platform than we could on OSX or Windows. But we can't yet do everything we want, and we're relying on some hacks, things that the platform upstreams could unknowingly break.

We want to work with the upstream platform folks to make the Dmedia import scenario a first class citizen, something that is explicitly supported, something that we can count on release after release.

It would also be nice if we had a solution that worked across multiple desktop environments, from Unity to Gnome Shell to KDE, and it seems like UDisks2 is probably the place to focus our efforts.

Although our use case is rather usual, it's also something that can set Desktop Linux apart, can make it a clearly better solution for pro video, photo, and audio. So we think our use case is worth supporting. We'd love to see Linux apps beside just Dmedia take a similar approach, to help raise the bar ever further.

This is roughly what we want to do, noting what currently isn't possible:

  • (fragile hack) API for an app like the Dmedia importer to acquire/release control over the handling of media insert events. When an app has this lock, default actions like Shotwell don't run. When the app releases this lock, default actions again work normally.

  • (not possible) Auto-mount media read-only, and also have other control over mount options, like mounting FAT32 with tz=UTC when we're assuming the timestamps are in UTC

  • After the import completes, unmount and format the media... this is a critical part of how we prevent user error that can easily cause data loss.

  • (not possible) Sometimes we need to re-mount the newly formatted media to restore special files like Magic Lantern or the special Tascam files (so initialization isn't required)

  • Eject the media

More details follow on the things that are currently fragile or not possible:

Greedy Import Scenario

The Dmedia import UX is designed for high-volume, extremely repetitive use, particularly for how a DIT (Digital Image Technician) would use it on-set. Because we need to make very narrow assumptions about the user's intent, we only respond to media insert events after the user has explicitly started the Dmedia importer.

The Dmedia importer shouldn't be the default action that, say, Nautilus uses when you insert a card with a DCIM folder on it. The default action should be Shotwell or whatever. But after the user has explicitly started the importer, we don't want any of the default actions to run... we want Dmedia to be a "greedy importer" that handles all media insert events. We import photos and videos, but we also import audio files from recorders like the H4n.

We currently prevent the default actions through a hack like this: 

  • # When importer starts:
settings = Gio.Settings('org.gnome.desktop.media-handling')
autorun_never = settings.get_boolean('autorun-never')
if not autorun_never:
    settings.set_boolean('autorun-never', True)

# Then when importer quits:
if not autorun_never:
    settings.set_boolean('autorun-never', False)

Although this (roughly) accomplishes what we want, this is fragile because upstream might unknowingly make a change that breaks our hack. We'd be much better off if we work the UDisks2 and Nautilus folks to add this "greedy import scenario" as something specifically supported by the platform.

BTW, we monitor UDisks events ourselves to figure out when media insert events occur. We don't think it's worth adding mime-type hooks in Nautilus for every type of media file layout (audio recorders vary widely in their file layouts). Instead, it's better to just import all files from all inserted media.

The one exception is when there is a .dmedia/ directory in the file system root. Then we add this drive into the Dmedia storage pool.

It would be rather nice if the greedy-import API first passed events to the app with the lock, but provided a mechanism for this app to tell UDisks2 (or whatever) that this particular media isn't of interest, that the default action should be taken instead.

Control over some auto-mount options

Hopefully it's not controversial that it's best for Dmedia if media is mounted read-only during imports. We're doing everything we can to ensure Dmedia provides outstanding data-safety, and mounting the media read-only as you import just makes sense (to us anyway).

Possibly more controversial is that we want to mount FAT32 media with the tz=UTC mount option so timestamps are assumed to be in UTC. Getting correct timestamps that we can easily relate between devices is somewhat tricky. But timestamps help drive important aspects of our audio sync and multicam automation, and so to make this easier, we're advising our users to set their device clocks to UTC (at least for devices that don't understand timezones, don't use a sane system time).

There's no reason for Dmedia to be what does the auto-mounting in /run/media, we just need a bit more control over how the auto-mounter behaves. This API should probably be closely coupled to the API for acquiring/releasing the greedy import lock. It seems pretty reasonable for Dmedia to pass special mounting options when it acquires the lock, something like: 

  • # Acquire
token = UDisks2.AquireGreedyMediaInsertLock(['ro', 'tz=UTC'])

# Release:
UDisks2.ReleaseGreedyMediaInsertLock(token)

Re-mount after formatting

With UDisks, an app like Dmedia doesn't have permission to re-mount media after we format it. We need to do this so we can, for example, restore Magic Lantern files after formatting.

We can do this just fine:

  1. Unmount
  2. Format
  3. Eject

But we need to do this:

  1. Unmount
  2. Format
  3. Re-mount
  4. Unmount
  5. Eject

Note that in this scenario, the user hasn't touched the media. So the security implications are no different than how the original insert event was handled, or at least it seems that way.

Novacut/HelpNeeded (last edited 2012-09-01 00:12:57 by 173-14-15-225-Colorado)