Would hugely appreciate some guidance on how to do this. E.g. I have two mpegs at 832x604 10fps which I simply want to join together. No editing/effects/transitions, just a join. I have tried creating custom profiles matching the source resolution and custom rendering templates of various formats with various options, and nothing gives me a decent output video. The closest I can get is a wobbly looking video which looks like the really old-fashioned interlaced TVs look like. Most of the time I end up with a 0 byte file, or a 4k file with no video channel (according to mplayer).

Without this I am afraid kdenlive is useless to me, and I will have to reluctantly leave its community :-( Thanks for any help you can offer.

I have tried things like

f=mpeg s=832x604

and

f=mpeg s=832x604 progress=1 deinterlace=1 r=10

but whatever I do the quality remains terrible:

http://adamspiers.org/video/

joined.mpeg is the join of the two test mpegs...

Pasting info found as I go along in case it helps other people.

madsdyd on #kdenlive pointed this out:

http://www.mail-archive.com/kdenlive-de ... 00459.html

deinterlace=0 helps get rid of the terrible flicker. vcodec=mpeg2video removes some other artefacts. Still can't avoid it squashing the width of the originals and putting black gaps either side though :-(

Here are some more suggestions

r=10 vcodec=mpeg4 s=832x604 b=500k acodec=mp2

f=avi minrate=0 b=8000k ab=384000 ar=48000 s=832x604 vcodec=mpeg4 mbd=2 trell=1 mv4=1 progressive=1

This is after creating a project profile that reflects the progressive, 10 fps and size settings.

However, it appears there are still interlace problems, and possibly also other problems.

This is from fresh svn copies of ffmpeg, mlt, mlt++ and kdenlive.

So, some help from the ffmpeg gurus would be great :-)

It seems that vcodec=mpeg4 breaks with f=mpeg but works with f=avi

The solution is to create a custom profile in Kdenlive 0.7 svn.

Enter 10fps and the exact PAR (pixel aspect ratio)

and DAR (display aspect ratio: 832x604) and this should work.

Then export to any size or create a custom export size (-s in ffmpeg).

Beware is a strange bug in Kdenlive. Enable "Open the project in tabs" in settings.

Kind regards,

Jean-Michel

This gets perfect results for me:

f=avi s=832x604 vcodec=mpeg4 b=800k progressive=1 mbd=2 trell=1 mv4=1

without too much increase in file size.

The black bars issue was to do with incorrect geometry in the project settings. I'm not sure if this was pilot error (e.g. defining a custom profile but then forgetting to select it) or a bug (project profile settings getting lost) but either way it is critical to get it right to avoid scaling.

Thanks Jean-Michel for your input! What is the effect of this bug?

Works perfectly I tested with your files.

1. The bug has major effects, it will probably be fixed today. If you do not allow tabs, you wron't be able to choose a profile on creation of a new project. :shock: See: http://www.kdenlive.org/mantis/view.php?id=239

2. Create a custome profile with 10 fps, 1:1 PAR, 1:1 DAR, 832x604 size, full image.

3. Create a custom export profile. Clic on mpeg4 and customize. Rename your export to whatever and enter s=832x604.

4. Create a new project with profile and export with custom export.

This is it.

I could not upload the resulting file, too large.

Thanks for jumping in here Jean-Michel, most of your advice was spot and very helpful.

However, technically, this is incorrect. Even though the MLT profiles requires all these values, perhaps kdenlive's UI should hide one of PAR or DAR. If the PAR is 1:1, then mathematically, given this resolution, DAR must equal 832:604. That DAR is roughly 1.38, which is close to 4:3. This is an uncommon resolution, so I hesitate to assume the DAR is 4:3; however, it very well could be the intent. If you think the DAR should be 4:3, then you need to compute the PAR: (4/3)*(604/832) = 2416:2496. As long as the project profile and the render settings match, then you will eliminate the padding. However, if the aspect info is not set correctly in the rendered output's metadata, then a player might show it wrong.

This has been fixed in r2525 :mrgreen: (not by me!)

Jus' thought I'd share the love. :roll: