Opening *.MTS

layman
2010-04-18
2012-09-15
  • layman

    layman - 2010-04-18

    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?

     
  • Salsaman

    Salsaman - 2010-04-19

    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?

     
  • layman

    layman - 2010-04-19

    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
    months ago.

    I'll try different versions of mplayer to see what happens see. I keep you
    posted.

     
  • layman

    layman - 2010-04-21

    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.

     
  • Salsaman

    Salsaman - 2010-04-22

    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 ?

     
  • layman

    layman - 2010-04-22

    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

     
  • layman

    layman - 2010-04-22

    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.

     
  • Salsaman

    Salsaman - 2010-04-22

    That last point is definately an mplayer issue.

     
  • layman

    layman - 2010-04-22

    Thnx. With some luck I might get a chance to play around with mplayer tonight.

     
  • Salsaman

    Salsaman - 2010-04-22

    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).

     
  • layman

    layman - 2010-04-22

    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
    sluggish.

    mplayer output:

    Playing 00005.MTS.

    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).

    Starting playback...

    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

    Exiting... (Quit)

    So right now I have a working setup again :) Thanks for your help and patience

     
  • Salsaman

    Salsaman - 2010-04-22

    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 ?

     
  • layman

    layman - 2010-04-22

    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!

     
  • Salsaman

    Salsaman - 2010-04-22

    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 ?

    Cheers,

    Gabriel.

     
  • layman

    layman - 2010-04-22

    I have suspected the soundcard too. Seems like pulse is a bit more safe than
    jack tho.

    Yes I can clock different encodings for you this weekend. Do you want the
    results here or by mail?

    Thomas

     
  • Salsaman

    Salsaman - 2010-04-22

    Email to salsaman@gmail.com would be optimal. The results don't need to be
    exact, just a general idea will do.

    Thanks,

    Gabriel

     
  • Salsaman

    Salsaman - 2010-04-24

    BTW, I have been wondering....jack should be far more stable than pulseaudio.
    What are the contents of your ~/.jackdrc file ?

     
  • layman

    layman - 2010-04-24

    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
    what happens.

     
  • Salsaman

    Salsaman - 2010-04-24

    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
    crashes.

    The you can do:

    (gdb) info threads

    (gdb) thread 1

    (gdb) bt

    ...

    ...

    ...

    (gdb) thread 2

    (gbd) bt

    ....

    ..

     
  • layman

    layman - 2010-04-24

    Dropped some infor and outputs in your mail

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks