On built-up Linux computers, we have two important nonlinear video editing applications available from the package manager: “Kdenlive” and “OpenShot”. As the naming would suggest, Kdenlive is centered on the K-Desktop-Manager, while OpenShot is not. Both use the Melt video processing library as their back-end.
(Edit: I goofed, first when I attempted to transcode the video using Kdenlive, and then again, when I wrote this posting about it.
What I had expected to find in the Project Settings of Kdenlive, was that the two “NTSC” formats be grouped together somehow, similarly to they are with OpenShot, starting with “NTSC”. Instead, Kdenlive has a long drop-down list, which is alphabetized by the software itself – not the programmers.
It has the setting simply named “NTSC”, which refers to the older, 4:3 version. But then, when the user wants to find the 16:9 version, he must scroll way up along the drop-down list, until he gets past the “HD” entries, all the way to the entry “DV/DVD Widescreen NTSC”. And then that setting will perform as expected.
Kdenlive therefore does not have this weakness, but my mistaken choice of output formats, was in fact the true reason for the malformed video file that resulted. )
There is a specific feature in Kdenlive,
which does not work properly. To understand what is expected of this feature, the reader must first of all understand something about the background of analog video.
Back in those days, the NTSC, PAL or SECAM signal format assumed a 4:3 aspect ratio, which was later translated into a digital equivalent, which in turn simplified the resemblance to analog, by assuming a pixel aspect of 1:1. This first resulted in the VGA format. In other words, in order for a rectangle of square pixels to have a ratio of 4:3, it would have needed to be a 640×480 resolution image. Because of the way analog signals were processed in practice however, an analog video signal could never really distinguish anywhere near 640 lines of horizontal resolution. 483 vertical scan-lines were smeared horizontally by the filters, to result in maximally 480 horizontal points in the case of NTSC, and that would have been, assuming a comb-filter was used, which was also not available in the early days of TV. In reality, when the signal-format was adapted to DVDs, a strict NTSC format was defined, that consisted of 486 vertical scan-lines, but which had 720 points horizontally, a pixel-aspect of 8:9, and the frame-rate was kept consistent with the 29.97 Hz the analog signal had. This latter deal may in fact be important in video editing, because if an incorrect frame-rate is combined with correct sound-compression from today, an eventual loss of synchronization may result, after longer intervals of play.
At some point in time, picture-aspects of 16:9 started to become popular with DVDs, and their format was adapted to this, by making the pixel-aspect 32:27, and maintaining 720 horizontal points. The question follows, how this change in aspect-ratios was sent along to an analog TV, and the answer would lie in the fact that analog TVs had several modes with which to display a 4:3 signal on their 16:9 physical screens, one of which was to letter-box, another of which was to oversize, and another was just ‘to stretch to make it fit’. Viewers would simply observe that this last option sometimes produced distorted results and sometimes not.
I.e., Nothing was done to communicate the meta-data; the picture was simply stretched to 16:9 on-demand, by the viewer settings.
The sad fact about Kdenlive, is that somehow,
it does not work with this notion correctly. As many video-editing applications may do, Kdenlive has a set of presets which the project is formatted to, as possible output-formats, and one of them is the Strict NTSC. This setting assigns some number of pixels, but still assumes an aspect ratio of 4:3, even when the user wants 16:9.
OTOH, OpenShot has a clear setting for NTSC, but in 16:9 instead of in 4:3. I have not tried them with PAL.
This failure of Kdenlive to process its meta-data correctly, has already slowed down one of my projects recently. I had a number of arbitrarily-formatted MP4 videos, and felt at first that the easiest way to transcode those into NTSC – 16:9, would have been just to open each in Kdenlive, but to set the output format to Strict NTSC. And the results were MPEG-2 -compressed streams which other, external player-applications could not play back.
Under the circumstances this was not a major setback, because I found an appropriate set of ‘ffmpeg’ command-line-recipes, which transcoded everything as I needed it. But a full-featured video-editing application needs to be able to make this format one of its targets.
OpenShot also has a preset, ‘Strict NTSC’, but then within this preset a 16:9 screen-aspect can be selected. In a later, follow-up experiment, I transcoded the same video that had failed before, this time using OpenShot, and the resulting video played correctly, in externally-determined player-applications.
The fact that a DVD-player appliance is being fed 480 scan lines instead of 483 or 486, does not even produce a problem.
But the fact that it is being given a 720×480 pixel-format, and told to play it back at 4:3, produces a fatal error, and ejects the DVD.
The fact that the content is to be played back at 16:9 instead of at 4:3, needs to be encoded into the individual files, and is important to the DVD-player, because this is a digital device, unlike how certain TVs used to be.
( … )
I suppose that one might decide, the best way to handle this in Kdenlive would be just to select a generic 720×480 format. But then one problem with that will be, an assumed frame-rate of 30 FPS, not 29.97 . And so after several minutes of playback at the correct frequency, ignoring the embedded frame-rate, the audio, at the correct playback-rate, would also fall out of sync. Maybe, some playback-devices today can play back the video at 30Hz, instead of 29.97, who knows. But the corresponding Strict Format
needs to be supplied.
The disappointment this brings, is that many of the complex effects which Kdenlive has to offer,
are not available to users, when they need to target this format, because then they cannot use Kdenlive. One of those effects is a ‘Typewriter Effect’, in which statically-defined text becomes visible one character at a time, as if being typed onto the screen while the video from another layer is playing.
Using OpenShot, such an effect is not even defined, because technically, this is not a pure video effect. According to more-linear processing, what would be needed is that another image-processing application such as GIMP be invoked, to transform the text into images of some sort, which could then be imported into OpenShot as a separate media-object.
With Kdenlive, it is particularly nice to have such complex, built-up effects available as a single, defined element of the project.
The ffmpeg-command-line that worked repeatedly, assuming that the input screen-aspect is already 16:9, was:
ffmpeg -i input.mp4 -target ntsc-dvd -aspect 16:9 -ac 2 output.mpg
(Addendum : )
I have now performed an additional test with Kdenlive, in which I set the project format to “DV/DVD NTSC” instead of the simple “NTSC” entry I had first used. The result was that my arbitrarily-sized video clip appeared letter-boxed, but played correctly in my external player-applications.
So for my purposes, the “NTSC” format choice does not work properly and should not be present.
(Edit 01/27/2017 : ) I think that an important consideration when using GUI-based applications under Linux is, that we should always set the output-format, before we begin work on our project, and that we should never import a clip into the project first, and later change the Project Settings, let us say, from a 16:9 to a 4:3 aspect. Doing so may interfere with the ability of the application to realign the individual clips to the new format.
When I had set Kdenlive to a suitable 4:3 format, before inserting my 16:9 clip, when I inserted the clip, this application adapted it to 4:3 correctly, in this case by letter-boxing it.
I may have run into a similar problem before, when using another Linux application named ‘ManDVD’, which is commonly used to create Movie-DVDs, which offers complex menus, and which re-samples all the video files, to adapt them to the chosen output format.
It may simply have been a mistake I made in 2013, to change that output format again, after having inserted the clip.
Also, just to make sure, When we choose an output format such as 16:9 with ManDVD, in spite of everything this application has to offer, we should first make sure that each inserted clip already has been shot in 16:9…
This is counter to what users expect, in GUI-based applications. If a feature is no longer available at a certain stage in the development of the project, it should either not be visible in the GUI, or ghosted.
IIRC, The lead programmer behind OpenShot, Jonathan Thomas, went to great lengths, and even allowed his project timeline to suffer from major delays in the past, just to make his GUI as foolproof as he could.
Here, I can import my 16:9 first, and then switch the Project Format to 4:3, and output a correct file.
IIRC, When using Kdenlive to insert a ‘Typewriter Effect’, we must also operate the GUI-buttons in a fixed, one-dimensional sequence, in order for the project file not to become corrupted.
(Additional Screen-Shots, 01/28/2017 : )
How to set up a Chroma-Key, using Kdenlive or OpenShot.
This is how to do it using Kdenlive:
This is how to do it using OpenShot:
(Update 2/27/2019, 6h35 : )
Version 4.x of Kdenlive still had this ‘Typewriter Effect’ in the editing window of its Title Animations. But version 6.y no longer has it. If one wants to achieve this effect now, one must apply an Alpha Manipulation Effect named ‘Rotoscoping’.
The following is a YouTube video, that is a screen-cast, but recorded by another person, which shows users how to achieve the Typewriter / Self-Writing Text effect, with an up-to-date Kdenlive version: