Introduction
Working Draft R&D Documentation for Developers for autoEdit2 .
For a video producer working on a factual/documentary production, editing video interviews is a time-consuming activity.
In the current work-flow, once the producer has the video file, they would have to find the quotes, which often entails manually scrubbing through the video in search of usable sound bites, which can be something like finding a needle in a haystack, particularly if the video is lengthy. Additionally, transcriptions are not a viable option either, as often there is no time to wait for them or no budget, and without time- codes, transcriptions do not help to speed up the process.
In a fast paced newsroom often there is no time for such a time-consuming process.
The aim of the autoEdit project is to produce an application that can maximise not only the depth of content but also the speed in which the content is produced.
The approach was to look at the traditional paper-editing workflow from documentary production, and see how that could translate into a digital world.
One reason why this project is interesting is because it utilises the new possibilities that have opened up with the node ecosystem, that allow for un unprecedented level of code reusability and the introduction of the HTML5 video tag. As well as the opportunities that have arisen in combining this with the increasing quality of speech to text technologies.
Not only node coupled with npm and yarn package management system allows for a modular component based approach but also projects such as NWJS (formerly node-web-kit) and Electron allows to use web technology to build cross platform desktop applications that with minimal code change can be ported to an equivalent web app version.
Combined with a mobile first approach, this allows to develop desktop, web, mobile version of the same app without the traditional overhead that this would involve.
This also lower the barrier of entry for this type of development.
Traditionally video and audio have been like black boxes on the web, often having to recur to flash to provide video capabilities to pages. With the introduction of the HTML5 video tag, Javascript libraries like videos make it easier to manipulate the video, treating it as a Javascript object. However this turns the video into "a ‘black box’ we can do something with", such as triggering events at defined timecodes. It does not allow us to directly obtain the content of the video in a programmatic way and to manipulate the result. An example would be to take from the video the content of the quote and then analyse this to identify keywords and key topics. Another example would be to search what has been said in the video, find the quote and trim the video segment accordingly. For more of a discussion of relevant projects that tackle this problem check out this article
As explored in a previous project, quickQuote, I believe it is by combining video with its corresponding time-coded transcription that we can provide a direct programmatic solution.
One of the challenges around this project is providing a comprehensive work-flow for the journalist and the user that is clear and easy to follow through from beginning to end, without requiring any training.
The fastest way to be able to quickly select a caption from a video, is to search a transcription of that video. Therefore a challenge was to research and identify the most appropriate system to get the transcription of any given video. Human generated transcriptions were not an option because of time and resource constraints. Automated transcriptions needed to meet a certain threshold of acceptance from the user, as well as have accurate timecodes in order to be searchable and in sync with the video for quick feedback.
Paper-editing it's only one stage in the documentary production when editing video interview, it generally corresponds to a rough cut stage, where a video sequence is assembled in a video editing software. This is then followed by a fine cut, where the video sequence is polished, cut-aways/B-roll shots are added to it etc..
It was therefore important for the output to integrate with video editing software.
After some research, it turned out that the best output for the "digital paper-editing"(a selection of text from different transcriptions) in autoEdit export part, as a "data interchange format" that was able to connect to a video editing software is an EDL. Which stands for Edit decision list, a plain text file format, that describes a video sequences and is widely compatible with non linear video editing software.
This proved easier and more widely compatible to work with then an XML.
This documentation is meant to be a higher level overview of the structure, parts and components of the application. Focused more on how problem domain issue have been addressed, which options have been tried and considered and what is the current implementation strength and weaknesses.
The first part is structured a round the 5 higher level parts that make up the app. Each one following this structure:
Component/part description
Related projects. Eg parts that look good, or previous implementations. But have been used for current implementation options.
Implementations Options considered
Current implementation
What needs refactoring
Check out the High level overview of the parts for more on this.
Then it also contains a roadmap section, and a QA section to serve as a checklist before every deployment, as well as a series of appendix with more technical info and implementation details relevant to the project , such as for example the db setup and prerequisite to mention a few.
If you are not familiar with Node, NWJS, backbone or not sure were to start to get an overview to familiarise yourself with this project, check out the prerequisite section to get an overview of the stack and see the minimum you need to know to get up to speed with this project.
Each release has it's own trello baord that gets duplicated/cloned to move on for subsequent releases. For instance this the trello board for v1.0.6 which will be kept for record, and soon there will be the one to keep track for the next release v1.0.13.
Trello board is used for planning and project management (altho at the moment is more notes for feature brainstorming and Roadmap section of these docs is used for next up planning). Github issues are used for bug handling. There is also a waffle dashboard that provides a trello like view of the github issues to help with organisation.
This documentation is written using gitbooks, and synced with a github repo for convenience.