[MPlayer-users] Linux viceo editor?
gene.heskett at gmail.com
Sat Aug 14 15:02:59 CEST 2010
On Saturday, August 14, 2010 08:10:52 am Van Snyder did opine:
> What video editor do Linux users of mencoder recommend?
I have always used kino. With my Sony TVR-460 camera, it can directly
control it over firewire. I have pulled in a 30 minute wedding, edited out
my shooting wibbles on a frame accurate basis. It can play the import in
real time, or in slow-mo to pick the edit points, can write the finished
product back to the tape drive in the camera, or do the encoding to make a
video cd iso, or a dvd iso. I did find that not everyones dvd players knew
what to do with a video cd, and had to remake a dvd, but that was minor.
I do not know of another, that fully integrated, editing program. The last
time I used Lives, I needed to edit a dvd, and got a great capture file, so
I figured I could give the dvd back, but playing that capture was the last
time it could find the audio and I wasted several hours trying to find if it
made a separate audio track file but not in that workspace/subdir. I
haven't touched Lives since.
kdenlive doesn't seem to have the integrated camera controls, but is what
the author of kino (Dan Denedy) is working on now, so it may grow those
kino's editing is either cuts, or timed fades and/or cross fades. Or it
could insert "commercials" too I think.
I just took another look at the current kdenlive and there are no camera
controls, so I assume you would have to capture with dvgrab or similar. It
also doesn't seem to be able to import any kino files. It does have much
more fully described output formats, exactly matching the 720x480 of my
> I have LIVES. For clips of more than about 1000 frames it is unbearably
The actual rendering and transcoding will be dependent on the hardware's
speed, these are very complex operations when that wedding was a nearly
10Gb src file, but which turned into a 330 meg iso in the end.
> A fast simple editor that can only delete segments, and encode the
> result, would be useful.
> mencoder can already do this, but an interactive front-end that shows
> the first and last frames of the region to be deleted, and allows to
> browse frames as easily as LIVES does, would be helpful.
> For those who don't have LIVES, here is a description of the simple
> functionality described above.
> LIVES has two regions where it displays frames. The left one is the
> first frame of a selection. The right one is the last frame of a
> selection. When a clip is loaded, the left one is the first frame of
> the clip and the right one is the last frame of the clip. Below each
> region is a widget displaying the frame number. One can adjust the
> frame number either by typing a new one into it, by selecting up- or
> down-arrow parts of the widget, or by dragging one or the other end of a
> slider that extends across the LIVES window below both regions.
> After one selects a region, LIVES allows one to do many things with it,
> but the interesting one for this simple job is simply to delete it. At
> that instant, LIVES deletes the selection, which can take an hour on a
> dual-core 3.0 GHz computer with 2GB of memory for a clip of only 20
> minutes duration. It also renumbers the frames, which is unhandy if one
> wants to repeat the editing session with slightly different
> It would be better to batch the "delete" requests and apply them
> together, preferably by invoking "mencoder" with an "edl" file listing
> the frame regions to be deleted, when an "apply" action is specified.
> Perhaps "apply" should be coupled to "encode."
> Ideally, this should be coupled to mencoder by a modification of
> mencoder that allows to specify skip regions in the "edl" file using
> either frame numbers or seconds.
> "undo" and "redo" features would be nice, but the bare-bones
> functionality of deleting unwanted parts of clips doesn't really need
One thing to be aware of, is that the audio and video in most of this stuff
are not locked to each other. The way around this that kino uses is to
break the capture into shorter pieces because the sync is re-established
when playing back. I used a 1Gb size as the capture size of a file segment,
and have never seen a lip sync problem, or heard an artifact at the splice
points. It just works.
> MPlayer-users mailing list
> MPlayer-users at mplayerhq.hu
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
You look like a million dollars. All green and wrinkled.
More information about the MPlayer-users