Olive: [Discussion] What I like in Olive

[malnaanah]

Today I downloaded Olives video editor and really loved it. I found it has many features that other video editors (such as Kdenlive) lack, some of these features are:
1- Keyframing any effect parameter.
2- Graph editor to control key easing.
3- Nested sequences with ability to ad effects to them.
4- Good review speed in sequence monitor.

I found Olive editor very promising and I hope more features will be added in the the future.

Excellent job.

[elsandosgrande]

I think you should add "[Discussion]" at the beginning of the title (if I had the permissions, I'd label the issue myself as such).

Lovely that it works great for you, but I still need KDEnlive for my videos. Regarding what it has right now, yeah, it's great, but it's not exactly a drop-in replacement for anything yet unfortunately.

[Brimson]

Olive is _superior_ to Blender's sequence editor, performance and feature-wise. There is GPU acceleration and VST2 support. Also, lots of Olive's video effects are written in real-time GLSL. Therefore, people can contribute to Olive by submitting their own shader effects, like what @oc1024 did with extra keying effects (many thanks for those).

Olive is like a standalone, modern rewrite of the Blender VSE people have been waiting for years. Most of the popular editors like KdenLive have been in development for over a decade. It took Kdenlive developers 2 years to refactor their timeline code. Meanwhile, Olive developers made an NLE in just over a year..

Now, the problems with Olive

The main setback on this project is the vulnerability of technical debt, with the code-base being unmaintainable. Jon in #300 pointed out Olive's lack of a code standard and standard documentation, despite Olive being over a year of development. Even this fan-made game-engine modification lists coding conventions. Jon made a stability-focused Olive fork called Chestnut because the Olive developers were reluctant so some of the proposed changes. Chestnut's goal is to prevent itself from becoming another buggy NLE years in the future. In professional software, there needs to be other contributors besides mattkc to maintain and improve Olive.

Right now, Olive has the opportunity become the Blender/LibreOffice of video editing. Open-source, professional, and could be used as a competent driver for users.

Fun fact

Out of millions of GitHub projects, popular Blender developer Pablo Vazquez starred this project along with 10 other repositories. That should show how much potential this software has and the attention it has gotten.

[DaniSeeh]

Yeah, I absolutely love Olive and think it has the most potential of any FOSS NLE currently being developed, so massive props must be given to @itsmattkc for that, but I also worry about what would happen if we had a Solus situation occur. For the time being I'm sure it's fine to focus on features and swift development, God knows Kdenlive could use a bit more of that, but for the long run there will need to be a time to slow down, refactor, and onboard some more developers to make sure this project doesn't have "the bus factor".

Unfortunately I have literally zero experience coding, and I don't think making my very first project an extremely complicated NLE would work, but I am Patroning the project, and actively using the software to do all I can. I hope others who can code can eventually work with @itsmattkc to do even more amazing things.

[mdmayfield]

I'm a huge fan of Olive so far. I'm kind of bummed out about the place #300 is currently sitting - I really hope that @jonno85uk, @itsmattkc, and others will continue to work toward a mutually beneficial and efficient way to work together on this, with shared focus and teamwork.

It feels like Olive is the best shot at a decent FLOSS video editor with great performance and a streamlined, polished UI, and I really really want it to have great features AND clean code AND stability AND a lot of people contributing effectively as a unified team.

[itsmattkc]

I feel I should apologize as far as #300 goes. Believe it or not, I had always intended to get back to it, but while I was in the middle of several smaller issues and distracted by a rush to address more of them, I hadn't put time towards properly researching the points. The hesitance wasn't towards making changes but more towards having to pause additions/features to address it, and even then I was still intending to address it eventually. By the time the issue was closed it felt like it might be too late.

I've been slowing down on smaller issues to take on larger ones recently anyway and figure I could begin addressing this with more commitment. I've started refactoring code to make it more "immediately" readable as well as started producing a full Doxygen-based documentation. I will continue doing so over the next few weeks along with other code improvements (smart pointers) while trying to address issues probably a little slower than usual. Hopefully this will put Olive in a more solid position for the future and invite more outside developers to help with development.

Thank you all for the support. Let's make Olive the best it can be.

[jonno85uk]

I'm glad to hear it @itsmattkc. The silence I got was rather disheartening. Since then i have noticed some changes i thought were related to what I had written. I understand it's a personal project and I know from experience seeing new-features work is exciting, unlike testing, documentation, etc.

I'm fully willing to drop what I'm doing and restart, mainly because what I've done is very difficult to merge with upstream (I've tried ) and in the end its just code. Hopefully somethings can be git-cherrypicked easily, but I doubt it. However, the pottering about I've done in chestnut has helped me understand the codebase somewhat better, provides me with ideas and I think I can help in a more direct manner.

The 1 thing I'd like to see is unit-tests and, unfortunately, it's a difficult thing to address. Firstly, I think it needs a file-restructure to allow the separation of main and unit-test projects (i.e. subdir project. see in chestnut) which I know will break CI. Secondly, it's going to require a lot of refactoring to get the code testable. This link could be of interest.
What I've found is that classes require a lot of knowledge of another class; 6e3eada highlights a possible way of going forward and demonstrates a method of adding a simple unit-test.

And to nit-pick, there's an odd un-printable character at the start of a lot of files which makes git think most of the file has changed during merging/rebasing. Oh, one more thing. Tab or not to tab?

[elsandosgrande]

Who knows, I might be able to catch up with you all in C++ by the time that will have been resolved and maybe start contributing something more than just a few sentences per day. Speaking of which, I know this is somewhat off-topic, but how did you learn C++ and get this much experience before starting work on this @itsmattkc and @jonno85uk ?

[jonno85uk]

@elsandosgrande

I had a c++ course in my 1st year of my EE degree ~15yrs ago. I didn't understand the concept of programming one bit, let alone c++. That progressed to 6502/68000 hex + vhdl programming, which made more sense to me, somehow. Then I had a matlab course for a digital-signal processing course too and I hated using matlab, so I taught myself python to use numpy. Then I got an arduino and it snowballed from there.
Nowadays I use c++ for my job, unfortunately the older 1998 standard due to MISRA (automotive).

[itsmattkc]

@jonno85uk I'll leave that up to you, a stability-focused port of Olive doesn't sound like a bad thing to me, but I think being able to put more minds together to improve one project will only strengthen it. I look forward to hearing about them and can provide better contact details than the GitHub issue tracker if you wish.

You'll have to forgive my ignorance, but I'm not familiar with unit-testing. From your example, it looks like external code to determine whether setting certain data points/variables on another piece code results in an expected output? I am prepared for some fairly sweeping refactoring, as I mentioned before I think it's time I made the code more approachable to outside developers.

I'm not sure about an unprintable character? All the source files have been generated within Qt Creator so my only guess is that it's added something along those lines without me noticing.

Funnily enough when I started Olive, Qt Creator defaulted to all spaces and I left it as that, but a later update to it changed the setting to all tabs and I unfortunately neglected to change it back or conform Olive to tabs leading to the mix it is at the moment. I personally prefer tabs, but I'm also liking the Google Style Guide (with 120 character limit) you've chosen and may opt for adopting it in Olive too.

@elsandosgrande I started with Delphi a very long time ago, moved onto PHP/Java/C#, and slowly worked my way down to C and later C++. I've also dabbled in some x86 asm but not much. This has been my first major C++ project, which may show as far as compliance issues go.

[elsandosgrande]

So, it seems we have a long road ahead of us.

@jonno85uk , that must burn (I bet it's the same as having to use an older version of Java).

@itsmattkc Wait, does that mean that there are still some areas where you're not rock-solid? I got a book from an American college (sort of a weird story, I'll tell it if you ask) in PDF format from one of it's students. It's C++. Since this ticket has devolved into coding advice and was a discussion to begin with, I'll attach the PDF. Now, to clarify, my intent is not to insult you in any way, but to help (in the unlikely case that this book covers something you might not have come across yet that might be useful). Also, it will probably be a good resource for people that want to join in, but whose C++ skills aren't rock-solid. Now just to start going to bed on time (it's 2:17 here in Sarajevo right now, 24h clock) and I should manage.
Intro to Programming c++.pdf

EDIT: Also, this is on of the reasons why I suggested earlier to have time zones declared of those willing to share theirs somewhere on here.

[DaniSeeh]

Obviously the path forward will be up to @itsmattkc and @jonno85uk when it comes to how to incorporate the refactoring of Chestnut into Olive, but I honestly don't see why we need both in the long run. Ultimately, I would hope that new features and clean, documented code could go hand in hand and not be enemies of each other.

I mean, there's always room for beta builds tested by folks like me to find bugs, but most successful projects don't have two forks trying to accomplish nearly identical goals. Nobody wants an unstable NLE, it's just a side effect of the rapid progress @itsmattkc made while building Olive as an outstanding passion project.

I also think combining this code cleanup and documentation refactoring with the pixel pipeline and rendering engine refactor would be sort of convenient, even if both tasks are quite difficult. I imagine the rendering engine is an extremely large part of Olive as a whole so if that has to be rewritten it might as well be done in a way that will be sustainable, maintainable, and expandable down the line right?

Sorry if I am butting into something where I don't belong since I'm certainly no coder and don't understand the intricacies of these issues by any means, but I just had some thoughts I wanted to share.

[jonno85uk]

@itsmattkc

You'll have to forgive my ignorance, but I'm not familiar with unit-testing. From your example, it looks like external code to determine whether setting certain data points/variables on another piece code results in an expected output?

That's more or less it in a nutshell. But you can expand the data-points simply as shown in this file.

The way its suppsoed be done is to create a test for some (granular) behaviour not yet available and then write code to satisfy the test (TDD). Unfortunately, and I've experienced it happen too often, tests get written much, much later in the development phase, which tests far too much in a single case, to satisfy a checkbox someone has.
100% coverage is typically the aim, but is difficult to achieve. The main upside of the tests are that they can allow new code written for behaviour-changes (new features, bug-fixes) without having to pray something else gets broken/changed at the same time.

@DaniSeeh

I also think combining this code cleanup and documentation refactoring with the pixel pipeline and rendering engine refactor would be sort of convenient, even if both tasks are quite difficult. I imagine the rendering engine is an extremely large part of Olive as a whole so if that has to be rewritten it might as well be done in a way that will be sustainable, maintainable, and expandable down the line right?

I think @itsmattkc has already started some of this in a way I think is useful going forward. Namely making things cleaner/better than when he found it. To drop a coding/development style/standard retroactively on the codebase is an undertaking and using it going forward and applying to "legacy-code" as and when they are touched is a more manageable approach.

@elsandosgrande

that must burn (I bet it's the same as having to use an older version of Java).

Not even allowed to use boost. Which means, if there's a feature from c++11/boost, it has to be manually implemented.

[DaniSeeh]

@jonno85uk

Makes perfect sense. I suppose if all of the code had to be combed through right now and refactored, that alone might take months and it would completely stall all other development.

[alcomposer]

@DaniSeeh The idea is to constantly refactor, and improve the code-base. There are so many variables, and at the end of the day, good code doesn't equal better user experience. Hence why refactoring is a continual process.
Hopefully, at some point, the refactoring pays off and makes adding new features easier.

[jonno85uk]

@itsmattkc

I'll leave that up to you, a stability-focused port of Olive doesn't sound like a bad thing to me

I, personally don't think a fork is a good thing. I've raised a new issue #518 as this issue is really off-topic now.

[itsmattkc]

Indeed, I will close this issue now as I believe the discussion is done

[elsandosgrande]

Yeah, this discussion completely went into left field.