Slashdot Mirror
OpenShot Video Editor Reaches Version 1.0
An anonymous reader writes "After only one year of development Jonathan Thomas has released version 1.0 of his impressive NLE for Linux. Based on the MLT Framework, OpenShot Video Editor has taken less time to reach this stage of development than any other Linux NLE. Dan Dennedy of Kino fame has also lent a helping hand ensuring that OpenShot has the stability and proven back-end that is needed in such a project."
I make porn videos. There's something about using "Openshot" to edit them that just adds some credibility to my artistic vision.
ZOMG, it's linux.
You're supposed to submit improvements, or fork it, or cobble together your own from GPL code.
Epic n00bertry
Finally an open source project that reaches 1.0 !
TLA overload. Since the summary is so short, couldn't the submitter or editor expand them?
This space for rent.
This is pretty neat, they also provide a .deb and ppa for installing. The demo video looks cool, I've never heard of this software before but it's good to see something new come out of the woodwork and do something halfway decent.
From my limited experience, the biggest problem with video editors on Linux is lack of stability. Cinelarra, LiVES, and Kdenlive crash so much they're not even usable. To make it worse, most of the crashes are random and unreproducible, so it's hard to submit helpful bug reports.
The way I see it, all OpenShot has to do is not crash every 10 minutes and it'll be light years ahead of the competition.
Maybe not
It looks like the author of this program spent(wasted?) a lot of time trying to use Gstreamer as the back-end for his project but basically ran into a brick wall.
If I remember correctly the developers of another Linux NLE called diva finally gave up on Gstreamer after years of struggling with it and subsequently abandoned their project altogether. Didn't the Diva developers also clash with the Gstreamer developers?
So it appears that the above developers put a lot of effort in writing Linux NLE's using Gstreamer but still ultimately failed at their attempts. Is there something inherently flawed with Gstreamer/Gnonlin? If Video software using Gnonlin as its back-end(Pitivi) can only be written by its author(Edward Hervey), Gstreamer must be too cryptic for mere mortal programmers. I wonder if anything formidable will ever come of Pitivi.
My question, has anybody on the commercial side actually solved the problem of mixing and matching any audio codec, video codec, and container format out there? Or do they usually just target a few codecs? Kino, for example, was reasonably stable on Linux if you just wanted to edit dv video.
"Is this one usable, unlike the other ones for linux?"
IMO, it already features everything that most people will ever need and it seems quite stable, too, but I prefer Kdenlive.
Allow me to suggest Sourceforge for the truly retro experience.
throw that question at Wikipedia for the full details but in a NLE program you can do stuff like grab a clip from 2:45 to 5:32 in a 3 hour clip without actually making a copy until you are done (and this can be down to the frame level) sort of like they used to do with the film reels but without the nasty cutting the film problem.
Any person using FTFY or editing my postings agrees to a US$50.00 charge
Does this thing support negative matchback, 3-perf or RED camera workflows? Or is it just another prosumer tinkertoy, like every other Linux media package?
Trust me when I say there is a LOT of interest in OSS alternatives (or any alternatives at all) to Avid, Final Cut Pro or Pro Tools, and a lot of money in support contracts if you were able to build the solution. But alas, Linux devs are constantly reinventing iMovie.
Don't blame me, I voted for Baltar.
I must be doing something wrong, I can't get Kdenlive to crash. Cinelarra did crash on me a couple of times.
People were used to film and analog video tape editing systems. The simplest editing system for video in e.g. VHS was to have two video decks, one for playing, the other for recording. You had to wind/rewind the source tape, press play on the source deck, wait for the right time to press the recording button on the destination deck, etc. It was a pain.
There were more sophisticated editing systems. But it was difficult to have frame accurate editing even then. You needed an embedded timecode in the video signal. Some camcorders came with this built in. You needed special video decks that ensured frame accuracy as well. Some video decks came with a jog/shuttle for easier editing control.
Initial software video editing systems did not store the video on the computer. Computers were too slow and had limited storage to do that. I mean, can you remember 20MB hard disks being standard? Imagine storing and playing back video using a system like that. Or worse. Just not feasible. Especially when a VHS tape could store like four hours of video.
So software for video editing just controlled the tape decks. The tape still needed to wind/rewind so this was not a non-linear video editing system. NLE only started being used once you could actually store the video in the computer or whatever.
I just installed it on my Ubuntu 9.10 system and through together some short clips I had laying around and not only did it work exactly the way I expected, but when I exported them in a couple of different formats it was very fast (I tried Kino a while back and not only did it take a long time to import clips, the export was also very slow.) I'm really glad I read this story today.
Fortunately, your view of modern Linux is a Lemming fantasy that really doesn't have much in common with reality.
A Pirate and a Puritan look the same on a balance sheet.
> As usual, it's only adequate for home or Youtube videos/etc.
You mean for MOST NORMAL PEOPLE that aren't interested in shelling out $1000 for a video editor?
You mean all those people that those silly "I'm a Mac" ads are targeted at?
Was that supposed to be an insult or criticism of some kind?
A Pirate and a Puritan look the same on a balance sheet.
All these replies miss the mark.
Before video there was film. Editing film means finding the strip of film with shot you want, cutting it out, and splicing with tape or cement to some other footage. That's what's meant by "cutting film" and is where the editing term "cut" comes from. A cut is the simplest form of edit. Clip by clip you splice together the story. You can start anywhere you want but when it's done, the beginning of the movie is at one end, the head, and the end of the movie is at the other, the tail. Shot by shot your story plays out from beginning to end on your edited reel of celluloid. If you decide you want a shot between two others, you cut the splice between the two shots and splice the new strip of film between them. It's easy to understand and very flexible.
When video came along editing changed and things got very inflexible. It is not practical to splice video tape because the image is not human readable and the video signal is too complex to make a simple noise free edit. The only way to edit video tape is to copy shots from a source tape to your master tape, assembling the video from the first shot to last, in order. If you make a mistake, you back up to the mistake and begin again. In video tape editing you can overwrite but you can never insert. Once a shot is down it can't shifted around in time. You can't insert a shot in the middle of an edited program without overwriting something. This is what is meant by linear editing.
You've edited your 30 minute masterpiece. Every cut is perfect. It just needs one thing: 7 seconds of sunrise before the scene starting at the 10 minute mark. Inserting the shot means having to re-assemble the entire remaining 20 minutes. More than likely you'll decide to give up 7 seconds in a nearby shot to limit the amount of re-editing you'll have to do, or live without the shot.
When computers came along it became possible to control video tape decks and video switchers. Such a computer can be programmed with an edit decision list (EDL), which is your entire program described shot by shot referencing source tapes and in and out times for each shot. With that information the computer can automatically assemble a video from source tapes in multiple decks. If you later decide you want to insert a shot between two others, you can change your EDL as easily as you would edit something in a word processor and tell the computer to assemble the entire video again, shot by shot, from start to finish. It's automated but it's still linear.
Today, with digital video, we can easily and inexpensively import video into our computer editing systems. We can cut it up and arrange it and rearrange it as much as we want, and in realtime. It's at lot more like working with film but much faster and more powerful. These editing system have completely removed the linear editing aspect of traditional video editing and this the reason we call them non-linear editors.
+0 Meh
> Is this one usable, unlike the other ones for linux?
Ah, if I answer "Yes", you want me to imply the (unspecified) "other ones" aren't usable? And if I answer "No", what does that mean? Your question appears to be obvious flamebait, if you didn't mean it to be, you should work harder in the future to enable real discourse. A good start would be to actually list the names of the programs in question and for each one explain why you didn't think they were usable.
> That's one thing I never liked about linux, the tools are all either extremely dumbed down and
> featureless or incredibly hard to start using. I like power, but I like being able to jump right in.
Is this your standard "I am fishing for mod points" commentary on Linux? You didn't find even one tool which was both powerful and easy enough to use that you could just "jump in"? People here are posting that their grandmothers practically don't notice when they switch them over to Firefox from IE. I guess that means that you don't believe it's "a tool", or you don't think it is "powerful"?
A pity, since I would have classified "video editing" as really one niche where Linux, up until recently, was quite deficient compared to (what I've heard about) proprietary solutions on Windows and OS X. It happened by chance that LiVES reached 1.0 exactly when I needed a video editor to edit a short home video clip (less than 10 minutes long) and it was exactly what I needed (in terms of functionality).
> Additionally, is this 1.0 as good as the competition's 1.0?
No, ours goes to 1.1!
This question is even more idiotic. First of all, what program or programs are "the competition's"? Secondly, version numbers are arbitrary in that each vendor/OSS project defines totally different criteria as to what reaching the v. 1.0 goal means. One project might define it as "we have a rock-stable program which is useful for editing 98% of all home video" and another project might define it as "we feel our program is useful for simple editing tasks for production cinema".
appearance over content: the downfall of modern society.
There are really only two codecs to speak of IMO, MPEG2 (MiniDV, HDV) and H.264 (AVCHD) in and MPEG2 (DVD) and H.264 (online or BluRay) out. However, neither of these codecs are trivial to edit in their most effective form and there's a lot of optional encoding methods to cover it all.
For example MiniDV is quite easy because it got rather "dumb" frames, but both HDV and AVCHD use IPB encoding which is really nasty to edit. You can't just cut the video stream at random points, you may need frames both before and after the cut point to decode it. You can't jump to a random frame, you must find the nearest I-frame and work your way from there. That creates a lot of complexity where you must keep a whole different set of indexes than the one the user sees to get frame-accurate editing and a lot of decode logic to get only the intended frames while discarding the extras and so on.
Pro editing tools DO have this mostly sorted out, if you're trying for the "no tool is perfect, therefore the OSS tools are as good as the commercial tools" argument then it's failing. It's not that many combinations that are really useful, it's that the few most important ones are really, really hard to do right. The decoding libs have this straight, I never have a problem playing back MPEG2 or H.264. But there sure is a problem editing them.
Live today, because you never know what tomorrow brings
Yes, there is tons of free "atmospheric" music available with copy left licenses. Google "creative commons music". For example look at: www.jamendo.com. There are also some rather large collections of European trance/ambient music around. The quality is there, but in a diamonds in the rough kind of way, you may have to search a bit. Or are you asking for a site where someone has prequalified the music for you, if so well, I haven't found it yet. None the less there are some great collections out there, and if you rank by popularity some of the cream will rise. If you are looking for one of the titles in particular, try Google?
Recently I tried Pitivi to make a cheesy Christmas Christmas video. Otherwise all my experience has been with my copy of Adobe premiere Elements 4.0. I looked hard at the advantages of paying for a more recent copy of Adobe Premiere too, but it offered no advantages that I could see. (And it is sloooooooow, at least on my Vista hardware).
The workflow I developed was to edit using pitivi on Ubuntu, because the speed of Linux on my Quad-core helped make the labor go quickest. Then I exported video in a humungous .avi container, with motion jpegs and MU-law audio, and let Premiere sloooowly render it to FLV adding motion-stabilization and auto-color-levels/balance. Newer versions of Premiere Elements are identical for these aspects as far as I could tell.
I have read Ubuntu dropped Gimp while opting for Pitivi, and the devs for OpenShot were in a competitive mood, trying to become the Ubuntu video editor-of-choice, (at least the one distributed on the CD). I cannot pull up a reference now, but it looks like this is the result of timely competition; and someone working their ass off, possibly to make an impression prior to Ubuntu Lucid Lynx.
I will certainly try OpenShot next. While it seems Pitivi support for gstreamer export would work really well, in practice I only found 1 maybe 2 useful export formats that Premiere would work with. Also Pitivi transitions & titles are still being worked on. These are the things that appear compelling, and are now being offered by OpenShot.
Adobe Premiere Elements, and TechSmith Camtasia are 2 of the 3 critical Windows apps I still use regularly, and their days are looking numbered. Adobe FrameMaker is the other one.
FWIW, I find video screenshot documentation useful for some projects & online help. Also, I have found that recording screencasts of software engineers explaining there complex app/logic to me, saves time & frustration for everyone, while allowing for better final documentation to be created from using this captured info (i.e. this is efficient knowledge transfer, and a great way to make docs).
Even mplayer/mencoder, the best of the bunch imho, has many, many options that won't work together, and can produce output that itself cannot read. How the developers even manage to keep that massive jumble of libraries from bursting into flames I can't imagine.
Just because you *can* do something, it doesn't mean you *should*. Mencoder won't complain (much) if you give it mutually-incompatible options but it might produce something weird and unusable. Equally, it might produce something weird and awesome.
It reminds me of the drinks machines we used to have at a place I used to work in - you selected a drink by typing in a number, where the bit pattern of the number enabled or disabled various things in the machine. So, black coffee no sugar might be 11, fizzy orange juice might be 22, chicken soup might be 41 and so on. So logically warm fizzy orange juice (nice) would be 23, hot orange juice (awesome) would be 21 and warm fizzy black coffee (nicer than it sounds) would be 13. Of course this means that 42 gives you fizzy chicken soup, which isn't very nice at all.
Yeah MJPEG was the codec most people used in the early days of prosumer NLE. Then we all switched to DV25 which is still like this.DV formats are still pretty much like MJPEG in that they do no compression between frames. A lot of camcorders still use the format. Other early editing systems enforced that when you were using MPEG-2 you could not use compression between frames. Do not know how they work internally, but IIRC this is no longer required. Linux editing software could follow this path as well. But probably better to start with the DV family of codecs first.
``This thread made me read up on video compression, and I can now articulate more precisely why my favorite video codec is Motion-JPEG - It uses 100% I-frames, which makes editing easy, and which makes fast motion scenes look better than codecs which use P and B frames. The only downside is that Motion JPEG doesn't offer the best compression, but it's still reasonably sized.''
For some value of "reasonably sized", I'm sure. But you are including a lot of redundant information in your stream if you represent each frame independently (which is what I frames do). By storing only the differences between frames (which is what B and P frames do), you can reduce the amount of data without losing any information. To achieve the same reduction using MJPEG, you would have to reduce the quality of your frames a lot. In short: if you use only I frames, you get larger files, reduced quality, or both.
The reason you observe that fast motion scenes look better using MJPEG than using other codecs you have tried is not that the other codecs use B and/or P frames, but that they are throwing away too much information. What is likely happening is that they have a limited bit budget per frame, which is enough to encode scenes with few changes between frames, but not enough to encode scenes with many changes between frames. The solution, then, isn't to use only I frames (that would probably make the problem even worse!), but to allow more bits per frame for frames that require it.
A little thought experiment to make it all a little easier to understand: suppose you have two frames that are very similar. Given the choice between storing each frame independently (I frames) or storing one frame completely (I frame) and the other as a diff against it (B or P frame), I think it should be clear that the latter will allow for a better bits:quality ratio. If you are only allowed to store full frames, you will have to sacrifice quality, increase the number of bits, or both. So allowing frames to be encoded as B or P frames is always a good idea. In those cases where it isn't beneficial, you can always still use I frames.
Please correct me if I got my facts wrong.
If only suitable for the "common man" is the thing, the goal...then I hardly see what's the point of TFS. There is such software already. Worse, this one seems to be basically a one-man effort which was rushed towards the magical 1.0 number.
One that hath name thou can not otter