Also if the transform effect is changed from default, the split clip will not inherit the transformation. In addition, the split clip's position is offset with all effects removed and no way to add effects to it.

Presumably an issue with the video header and/or trailer written by Olive, Windows 10's default video player (including its thumbnail generator in Explorer) appears to be unable to read videos exported from Olive. VLC reads them without any issues.

maaaaybe related to #48 ?

When splitting a clip (either with razor or edit tool), the newly spawned clips will continue to reference the old clips as linked.

The razor/edit tool in general need to be aware of linked clips which currently they aren't.

Even if audio clips are in the timeline, Olive makes no sound.

Placing a clip over two or more clips causes many issues. This was actually an issue before and had been addressed, but has clearly regressed in a more recent commit.

After exporting a video from Olive, the audio will inexplicably end early, before the video does. This does not seem to be a consistent offset from the start or end of the video, it simply cuts off at some point for the rest of the video.

Minor enhancement for the compilation process

All videos are blown up full screen with no transform functions for position, scale, rotation, etc.

Anything imported cannot be deleted

I can edit but I can't actually post anything???

This appears to be due to an underlying flaw in the FFmpeg API and leads to the symptoms described in #11 and #15 . When Olive tries to seek to a specific frame, it attempts to seek to the closest keyframe before the target frame and then play all frames up until that point to retrieve the target frame accurately. Unfortunately after seeking an H.264 video, FFmpeg appears to stay in the old location for 1-3 frames before actually performing the seek. This may affect other codecs too, but so far H.264 is the only codec that appears with the bug. This does not affect codecs with All-I frames (e.g. ProRes) and also does not appear to affect msvideo1.

Snap playhead to clip in/outs
Snap razor to playhead

This appears to be related to SDL. By default, Olive's main window is a SDL hardware renderer with vsync enabled. It appears that minimizing it disables the vsync, causing the frame rate to uncap, and Olive to update infinitely, only capped to the limit of the CPU. Possible solutions are: disable vsync and run on an internal timer at all times for updates, research SDL documentation for built-in solutions to this, or include a listener that disables updates when the window is in a minimized state.

Ripple edit functionality similar to Premiere, and its keyboard shorcut variants Q and W

Video and audio clips are imported together, but from then on treated as completely separate.

do it

As of 481060b, Olive's composition pipeline (the way it decodes and displays frames during playback) has been almost completely rewritten. This was to address various problems in Olive's playback, primarily caused by the fact that up until this point Olive was completely single-threaded. This meant that every single action Olive performed - from UI drawing to input handling to video decoding - could not be done simultaneously, each had to occur one after the other.

These issues caused the following:

• When a new clip started in the timeline, playback (and the whole app) would pause as FFmpeg loaded the file from disk
• Playback and audio decoding regularly desynced, leading to occasional sound glitches during playback.
• If a video was too slow to decode in real time, the entire app would become less responsive. This obviously has the potential to hang the entire app if a frame gets caught in an infinite loop.
• If you have more than one video layer playing at a time, obviously it is far from ideal to have to render each layer in sequence when you could render them all at the same time.
• Each frame had to be rendered in real time. If hypothetically a video could playback mostly fine, but every 10th frame or so took a little longer, there was no way to use the time saved from the previous hypothetical 9 frames to help render the 10th.

Olive's playback engine is now multithreaded and also keeps a memory cache. This is bleeding edge code and as such is full of bugs and missing features. This thread is to keep track of issues as they arise - and also to assure anyone trying the buggy mess that is Olive now - that everything is okay and being taken care of.

The following is a starting list of issues with the new composition pipeline:

• Crashes a lot - currently segfaults at the drop of a hat
• Memory leaks - despite my best efforts, Olive seems to not be handling memory correctly
• No seeking - Olive functionality has regressed to only being able to play frames in order (but can still play media with frame rates lower then the sequence frame rate)
• No sound or still image support - these have once again been lost as video has taken priority during the rewrite. This should be fixed soon.
• Playback still tries to access a clip even after it's deleted in the timeline

Any other standout issues, as well as announcements for these issues being fixed, will be posted here

My impression from writing this app is that UI rendering is pretty efficient. Once we reach v1.0, I think the entire UI needs an overhaul.

Very occasionally, Olive will segfault when clicking "Cancel" on the import file dialog. This behaviour has only been observed in Linux so far (Windows suffers from its own file dialog bug #9 but so far the two issues appear to be exclusive to each platform).

Not an app usability fault as much as a "makes code harder to maintain" fault. It would be nice to have a better codebase looking toward the future.

Functionality to split clips at the start and end of a selection, in addition to simply at the playhead

Dragging in a second copy of your imported footage into the timeline and having them play over each other (on separate video layers) results in at least 50% performance loss to playback. This can be repeated, further decreasing performance.

Workaround: Importing the same footage twice (having 2 references to the same footage in the import panel) and dragging each reference into the timeline allows for intended playback performance.

Without reporting so (no warning about a frame taking longer than expected, i.e. as far as the app is concerned it's realtime), Olive appears to play all video slightly slower than it should.

This is likely either a vsync issue (similar to #20) or a result of Olive's single-threaded nature. Either way this will become increasingly problematic as #4 is finally implemented.

Can't edit if I can't trim me clips tbh

This functionality was actually working in a previous version of Olive, but regressed during a rewrite of the timeline code. Olive no longer offsets clips meaning all audio clips are placed over the top of each other, and obviously then overwriting each other.

I make many mistakes in life.

While playback performance is generally acceptable now, starting a new clip causes a "seek" which generally causes a noticeably pause in playback. Olive could theoretically detect upcoming clip changes and seek them before they need to be displayed. The built-in frame caching would handle the rest, so that starting the new clip would be essentially seamless. This kind of optimization should come at the same time as addressing #21 (which will likely require detecting multiple clips of the same source and duplicating the format context).

Olive should also dealloc frame caches on clips after they are finished to save memory on particularly large sequences.

When videos are moved offscreen with transform effect, they loop back around the other side like Pacman

open>add clip>delete audio>razor a bunch of the the clip>box select a good few of them>switch back to P mode > move them on top of others> crash

With some containers (notably Matroska), FFmpeg reports a 0 frame length causing Olive to incorrectly detect it as a still image.

Sliced audio clips always play the audio from the beginning of the source video, regardless of where you cut it from.

maybe this is a feature

MICHAEL CAINE MICHAEL CAINE MICHAEL CAINE MICHAEL CAINE MICHAEL CAINE

*EDIT: video meta data, if h264 is part of the issue

Double Jump\Arkham City LP\Ep 1\Ep1.mp4':
Metadata:
major_brand : mp42
minor_version : 0
compatible_brands: mp42mp41
creation_time : 2013-03-23T11:22:27.000000Z
Duration: 00:05:23.31, start: 0.000000, bitrate: 3156 kb/s
Stream #0:0(eng): Video: h264 (Main) (avc1 / 0x31637661), yuv420p(tv), 1280x 720 [SAR 1:1 DAR 16:9], 2993 kb/s, 30 fps, 30 tbr, 30k tbn, 60 tbc (default)
Metadata:
creation_time : 2013-03-23T11:22:27.000000Z
handler_name : Mainconcept MP4 Video Media Handler
encoder : AVC Coding
Stream #0:1(eng): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo, flt p, 157 kb/s (default)
Metadata:
creation_time : 2013-03-23T11:22:27.000000Z
handler_name : Mainconcept MP4 Sound Media Handler
[INFO] Clip opened on track 1
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'E:\Users\David\My Documents\Film Stuff\ Double Jump\Arkham City LP\Ep 1\Ep1.mp4':
Metadata:
major_brand : mp42
minor_version : 0
compatible_brands: mp42mp41
creation_time : 2013-03-23T11:22:27.000000Z
Duration: 00:05:23.31, start: 0.000000, bitrate: 3156 kb/s
Stream #0:0(eng): Video: h264 (Main) (avc1 / 0x31637661), yuv420p(tv), 1280x 720 [SAR 1:1 DAR 16:9], 2993 kb/s, 30 fps, 30 tbr, 30k tbn, 60 tbc (default)
Metadata:
creation_time : 2013-03-23T11:22:27.000000Z
handler_name : Mainconcept MP4 Video Media Handler
encoder : AVC Coding
Stream #0:1(eng): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo, flt p, 157 kb/s (default)

As of ed38544 with the inclusion of SDL_INIT_AUDIO in the SDL_Init() flags, Olive will occasionally (seemingly randomly) crash on launch, but launch without issue the following time.

But preserve current functionality of storing in the application folder if a portable.txt is present

Some (not all) AVCHD/H.264 videos appear to hang the decoder on the last frame. Likely an issue of Olive expecting another frame that doesn't actually exist.

When compiled on Windows, Olive encounters this error fairly frequently:

Olive is not compiled with Visual C++, so this must be caused by a dependency. Perhaps an assert() is failing. It's hard to tell since no stderr is printed.

Every rendered frame increases Olive's memory usage and it never decreases afterwards.