June development update

Good news everyone !

This is the first blog post of a series of updates about our latest development efforts in GStreamer / gst-editing-services / Pitivi.

This post's focus will be on MPEG transport stream, a format now nearly twenty years old, originally developed and still widely used for and by the broadcasting industry. In the mid-2000s, some people decided it would be a great idea to use this format in camcorders, stuffed a rather useless timestamp in there for good measure and started to ship AVCHD camcorders like it was the greatest thing since sliced bread.

It was not. See, most modern video codecs such as h264 rely on the notion of keyframes: to compress video streams as much as possible, most frames are encoded as their difference with the previous frame, we call these frames delta units. Sparsely distributed in the encoded stream are keyframes. These frames can be decoded without any reference to past frames, and when trying to seek in such a stream, decoding has to start from a keyframe and progress through all the delta units up to the requested frame.

Video editing implies accurate seeking, for example if you only want to include the 10 last frames of a 2-hour clip, decoding the whole file to obtain these few frames would be a pointless waste of time.

Failing to start decoding from a keyframe when seeking creates artefacts, garbled frames : the decoder is missing information to decode the delta unit, tries to provide a frame nevertheless and fails in doing so, until the next keyframe has been reached. Containers that are readily usable for editing contain information about the location of keyframes, in one form or another. This is not the case of MPEG TS, of which AVCHD is a subset. Locating the keyframes thus becomes a rather involved process, as one needs to parse the video streams in order to do so.

Backtracking to the introduction of this post, good news everyone ! We just did that, and here is a before / after video to demonstrate our changes. We can now ensure full support of AVCHD, enjoy :D

The next two posts will be respectively focused on our refactoring of our video / audio mixing stack, and our ongoing work on gnonlin, our non-linear editing engine.

  1. Theseus Theseus on 06/24/2014 11:57 p.m. #

    This is great news! Thank you!

  2. Felix Schwarz Felix Schwarz on 06/27/2014 1:56 a.m. #

    Great - I really like pitivi's idea about improvimg the common base (such as gstreamer, ges, ...) and build a nice video editing tool on top.

  3. Kernel_Havok Kernel_Havok on 06/27/2014 2:32 a.m. #

    Thank you all.

  4. Niklas Rosenqvist Niklas Rosenqvist on 07/09/2014 7:50 a.m. #

    Any plans on making the timeline and timing of videoclips easier to edit? I tried the latest build for a small project and it was really hard to shorten a clip a second or a couple of frames. I would like a feature for stepping frame by frame and also keep the rest of the timeline adjusted so that it doesn't leave a gap. Maybe a toggle for auto adjustments (never checked if there is one already, in that case I apologize).

    I had a lot of issues with the preview and the timeline not staying in sync. If an effect or transition/keyframe occurred then it was impossible to see how it resulted since it just skipped that part. Even when just playing it never really stayed in sync. I was editing it on Intel® Core™ i7 Processor 3517U (1.9GHz, 4.0MB L3 Cache) with Intel HD Graphics 4000 and you can't possibly have higher minimum requirements than that, right? If it doesn't meet the requirements, shouldn't at least audio+video+timeline stay in sync and just be slower?

    Also after render, fades done with keyframes were choppy and sometimes when I had an audio track with a song it got muted when a video clip also had an audio track. That's what I encountered during my testing :) hope that it can be of some help.

  5. Mathieu Duponchelle Mathieu Duponchelle on 07/09/2014 8:20 p.m. #

    Hello Niklas.

    Regarding "keeping the rest of the timeline adjusted" there already are modes for that, you might want to look in the manual for "roll" and "ripple" edit.

    Regarding frame by frame editing, you can not do that for now indeed, best option is to just zoom in to allow for precise editing, the viewer gets updated with the frame at the edit point to help you be specific.

    Regarding your other points, it would be great if you could open bugs on our bugzilla at https://bugzilla.gnome.org/enter_bug.cgi?product=pitivi, and even come discuss on our irc!

    We're still working on backend issues, pitivi's refinement will come in a second part, we are aware of some of its issues and shortcomings, your feedback is key in helping us improve the software.

Pingbacks are closed.

Post your comment