OK, I AM warned - Lives isn't too fond of big files. But in earlier versions
(and an earlier Fedora) I managed to open 2GB mpegts (.mts) files. It took
some time, but it worked.
But now something odd is happening. Lives 1.3.2 starts opening the file at a
fairly decent speed. But after roughly 4000 frames performance drops to
something like one frame every two seconds. I have plenty of room on the
harddrive, RAM and swap are hardly affected at all.
So what's the problem here?
I am not sure what the problem is - nothing much has changed recently in file
opening. I just tried here with a large .flv file (>200000 frames) and I was
seeing consistent rates of about 100 fps.
The main thing which changed - LiVES now uses png as its default image format
rather than jpeg - you can check this in Preferences / Decoding, but it
shouldn't make much difference to speed.
Is it possible something else on your system changed ? Have you updated
mplayer / ffmpeg recently?
I have already tried to change default image format to jpeg - no difference.
Mplayer ... well the version supplied with Fedora 12 doesn't work with Lives
and .mts at all, so I downgraded to a F11-version instead a good while ago.
I tried the .mts-files on my laptop with F11 - but the tendencies are the
same. Which is odd - because I HAD it working on F11 on my main computer 6
I'll try different versions of mplayer to see what happens see. I keep you
A little uppdate. My Lives is not only slow at opening .mts-files. It also
makes a strange "final cut" to every longer clip. For instance: I have a 23
min clip (something like 35000 frames, or jpg's in the tmp directory). Lives
appears to read all these frames, but once it is done opening the clip I still
end up with less than 5 minutes of video.
For now I managed to convert the clip to mpg (in a Win7-application) which I
can open end edit in Lives without greater problems. But when I am done with
this 35 min movie I will go back to playing around with Mplayer.
That is very strange in deed, because LiVES should count the frames when a
clip is opened or reopened. The fact that it is not seeing all the frames +
the slowness suggeest to me that there is something odd going on with your
filesystem. Is there anything non-standard about your setup which could be
causing this ?
I have 10 disks on the system, 6 of them in two raid setups. All disks are
nice, clean and healthy. Apart from the number of disks there is nothing non-
standard with this system at all. It is run by a standard Fedora-12 + the rpm-
fusion pkgs needed for videoediting.
The video operations only involves one disk. This means that both the clips
and livestemp resides on the same physical and logical unit.
Lives have no problem opening the same mts-files when converted to mpg. The
framecount comes out correct. But of course the size of each frame is smaller.
~1 MB each for the 1920x1080 .mts and ~200 K for the 720x576 .mpg
Another note: When opening an .mts only one processor (out of 4) is used at a
time. When opening an mpg all four works simultaneously.
That last point is definately an mplayer issue.
Thnx. With some luck I might get a chance to play around with mplayer tonight.
You can also check the frame counter in LiVES. If you type:
smogrify <handle> <img_ext>
where <handle> is the part of the directory name after the temporary
directory name, e.g.
12345678 or set1/clips/98765432
and <img_ext> is either jpg or png.
It should print out the number of frames found (using a binary search).
Problem partly solved.
The latest mplayer crashes (using vdpau) and probably Lives doesn't notice. So
you get a short clip, odd fps and scrambled sound.
mplayer from a year ago (090329) works fine.
The rest of the problems were caused by a camera setting. My Sony was set up
to use X.v Color (XviD ?). That confused the older mplayer and made it
TS file format detected.
VIDEO H264(pid=4113) AUDIO A52(pid=4352) NO SUBS (yet)! PROGRAM N. 1
Opening video decoder: FFmpeg's libavcodec codec family
Selected video codec: vfm: ffmpeg (FFmpeg H.264)
Opening audio decoder: AC3 decoding with liba52
Using SSE optimized IMDCT transform
Using MMX optimized resampler
AUDIO: 48000 Hz, 2 ch, s16le, 448.0 kbit/29.17% (ratio: 56000->192000)
Selected audio codec: afm: liba52 (AC3-liba52)
AO: 48000Hz 2ch s16le (2 bytes per sample)
FPS forced to be 50.000 (ftime: 0.020).
VDec: vo config request - 1920 x 1080 (preferred colorspace: Planar YV12)
VDec: using Planar YV12 as output csp (no 0)
Movie-Aspect is 1.78:1 - prescaling to correct movie aspect.
VO: 1920x1080 => 1920x1080 Planar YV12 <------this seems to be the problem
Warning: No suitable new res found! <------this seems to be the problem
A: 5.4 V: 2.5 A-V: 2.912 ct: 4.403 76/ 76 2% 0% 0.1% 0 0
MPlayer interrupted by signal 2 in module: sleep_timer <----- me interrupting
A: 5.4 V: 2.5 A-V: 2.912 ct: 4.603 77/ 77 2% 0% 0.1% 0 0
So right now I have a working setup again :) Thanks for your help and patience
Great ! I am happy that you got it working again :-)
Sounds like a nice setup you have there. Almost makes my development machine
look like a toy !
How does LiVES perform with hd editing ?
I usually dowsize the hd-clips to 768x432 before actual editing. But even if I
don't Lives usually works pretty good. Size matters tho, so I keep the HD-
clips short. Once I get around to buy a Blue Ray player i hope I can use the
same method as when I burn DVD:s - unless I want some fancier transitions I
assemble the clips when I build the disk.
I have, and have access, to other video editors too. But I prefer Lives. Even
if opening files is slow the total workflow is faster - and more straight
forward. Yes it crashes at times (particularly when I some site containing
flash open i Firefox for some reason). But the crash recovery is really fast
even with hd-files so it doesn't really matter that much.
Great work, man!
That is good to know. The crashing seems weird - from your description it may
be something to do with the soundcard. There have been a few bugs with pulse
audio, since it was a new addition to LiVES but the latest build (1.3.2
onwards) should have resolved that.
Since you have a quad-core machine, you might find the mjpegtools encoder
gives faster encoding since it should in theory use all 4 cores. Maybe you can
do some benchmarking and let me know how it goes ?
I have suspected the soundcard too. Seems like pulse is a bit more safe than
Yes I can clock different encodings for you this weekend. Do you want the
results here or by mail?
Email to email@example.com would be optimal. The results don't need to be
exact, just a general idea will do.
BTW, I have been wondering....jack should be far more stable than pulseaudio.
What are the contents of your ~/.jackdrc file ?
Currently my .jackdrc says:
/usr/bin/jackd -Z -d alsa -s
Earlier I had:
/usr/bin/jackd -dalsa -dhw:0 -r48000 -p1024 -n4 -P -S -Xseq
The major benefit with pulse instead of jack is that I don't have to shut
LiVES down when I want to edit the soundtrack separately.
Yesterday I had a cpl of crashes that might have had something to do with
pulse. So I am going to switch back to jack and redo it all tonight so see
Before you switch to jack, can you try to log these crashes ?
If you run LiVES with lives -debug, it should drop you into the debugger if it
The you can do:
(gdb) info threads
(gdb) thread 1
(gdb) thread 2
Dropped some infor and outputs in your mail
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.