Novacut Wiki Home > Help Needed
Here are some tasks that Novacut needs outside help with.
High priority GStreamer 1.0 bugs
678663: Need equivalent of PyGST Buffer.data from PyGI (required to port thumbnail server to 1.0)
679181: PyGI equivalent of URIHandler subclass (required to start doing playback with gnonlin)
High priority Ubuntu bugs
udisks 1027136 [Quantal]: UDisks.EnumerateDevices() fails with Error.AccessDenied
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.
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.
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:
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.
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:
But we need to do this:
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.