10 Jul 2017, 5:12pm
linux:

leave a comment




  • Anzeige
  • Rendering problem with Kdenlive

    I really enjoy using the Kden­live video edi­tor. I think it’s a sim­ple, straight for­ward, and yet pow­er­ful tool.

    But just dur­ing the last few days, I had trou­bles for the first time and could not find a solu­tion. When ren­der­ing my project, it kept fail­ing with max_analyze_duration 5000000 reached at 5000000. I searched online, the error might be related to the size of the audio (>1h) Still, the project ren­dered at first, but after the final cut — with lots and lots of cuts — I started get­ting this error, thus, out of a sud­den, I was not able to get my final video file out any­more. Was I threat­ened to hav­ing to do the entire work again or what??

    Finally, today I found a solu­tion! Bet­ter, a workaround.

    I split up the file by adding guides — in my case three, but the num­ber might depend on the project size — and then used the ren­der fea­ture “Guide zone” (at the bot­tom of the ren­der dia­log). So, I ren­dered three parts and used melt to put them together like this:

    melt input*.mp4 -consumer avformat:result.mp4 acodec=aac ab=160k vcodec=libx264 vb=3000k
    

    I’m using x.264 and AAC here — but you can also drop all those para­me­ters and let melt fig­ure every­thing out — it’s pretty capa­ble, give it a try.

    melt input*.mp4 -consumer avformat:result.mp4
    

    If you have ffmpeg on your sys­tem, you can merge the files using the copy mode, so no qual­ity gets lost — see details here. But even when using melt and thus re-encoding the video, you will not notice that it has been ren­dered in three parts and “melted” later. So I’m happy! Still a bit sur­pris­ing that I could not find a solu­tion online. So hey, hope this approach works for you too! :)

    7 Feb 2010, 10:52pm
    linux:

    leave a comment




  • Anzeige
  • KDE vs. Gnome

    Now, my deci­sion is final: KDE rules (though I actu­ally pre­fer the look of Gnome :( ).

    Sim­ple rea­son: Gnome does not sup­port drag-and-drop in com­bi­na­tion with alt+tab (see bug tracker), but there might be hope with the upcom­ing Gnome 3.

    [Edit 2011-06-14: Indeed, drag-and-drop + alt-tab works since since Ubuntu 11.04 (did not try with 10.10). One major dif­fer­ence remains: Do you need a lot of con­fig­u­ra­tion and cus­tomiza­tion options? And are you will to accept com­plex, maybe not that self-explaining menu struc­tures for that? If yes, KDE is your choice, oth­er­wise Gnome might make your life eas­ier. See also this page for more details and screenshots.]

    In more detail: using drag-and-drop together with alt+tab key com­bi­na­tion allows to work very effi­ciently. For exam­ple, while order­ing my pho­tos, I want to work on one of them — as I do this reg­u­larly, Gimp is opened already, but in the back­ground — so what I do using KDE or MS Win­dows is, I grab the pic­ture, switch to Gimp by using alt+tab and imme­di­ately drop the pic­ture with­out mov­ing the mouse at all — I am quite con­fi­dent that this is the fastest way of open­ing a pic­ture for edit­ing. Some peo­ple advice to set Gimp as default appli­ca­tion to open JPEGs, but I am not always edit­ing pic­tures, most of the times I just want to view them.

    Using “Open With” on a JPEG file for sure is the com­mon approach — but let’s com­pare it:

    • Drag-and-drop & alt+tab
      • Actions to be per­formed: mouse down + key down + key up + mouse up
      • In total: four fast steps
    • Open With” solu­tion (hold­ing mouse down as improvement)
      • Actions to be performed:mouse down + mov­ing to “Open With” + wait for sub-menu to open + move to sub-menu + mouse up
      • In total: two fast, three slow steps