I compiled and installed kdenlive (0.7.8), ffmpeg (r25120), mlt (0.5.10), and x264 (current from git as of 2010-09-14) all from source. I am running on an intel i7, and was hoping to be able to take advantage of multiple cores. However, attempting to render with multiple threads causes significantly reduced video quality. In two pass mode, no video comes out at all.

Here are the rendering profiles I used on a 5 second 1080p clip:

25000K, 2 pass, no threading option specified:
f=mp4 hq=1 acodec=aac ab=384k ar=48000 pix_fmt=yuv420p vcodec=libx264 minrate=0 b=25000k b_strategy=1 subcmp=2 cmp=2 coder=1 flags=+loop flags2=dct8x8 qmax=51 subq=7 qmin=10 qcomp=0.6 qdiff=4 trellis=1 aspect=%dar pass=2

Result: Output file size 17.3 MB, quality is very good.


25000K, 2 pass, threads=2:
f=mp4 hq=1 acodec=aac ab=384k ar=48000 pix_fmt=yuv420p vcodec=libx264 minrate=0 b=25000k b_strategy=1 subcmp=2 cmp=2 coder=1 flags=+loop flags2=dct8x8 qmax=51 subq=7 qmin=10 qcomp=0.6 qdiff=4 trellis=1 aspect=%dar pass=2 threads=2

Result: Output file size 120 KB, no video in output file, only audio.


25000K, 1 pass, no threading option specified:
f=mp4 hq=1 acodec=aac ab=384k ar=48000 pix_fmt=yuv420p vcodec=libx264 minrate=0 b=25000k b_strategy=1 subcmp=2 cmp=2 coder=1 flags=+loop flags2=dct8x8 qmax=51 subq=7 qmin=10 qcomp=0.6 qdiff=4 trellis=1 aspect=%dar

Result: Output file size 17.3 MB, quality is very good.


25000K, 1 pass, threads=2:
f=mp4 hq=1 acodec=aac ab=384k ar=48000 pix_fmt=yuv420p vcodec=libx264 minrate=0 b=25000k b_strategy=1 subcmp=2 cmp=2 coder=1 flags=+loop flags2=dct8x8 qmax=51 subq=7 qmin=10 qcomp=0.6 qdiff=4 trellis=1 aspect=%dar threads=2

Result: Output file size 1.6 MB, quality is very poor

25000K, 1 pass, threads=4:
f=mp4 hq=1 acodec=aac ab=384k ar=48000 pix_fmt=yuv420p vcodec=libx264 minrate=0 b=25000k b_strategy=1 subcmp=2 cmp=2 coder=1 flags=+loop flags2=dct8x8 qmax=51 subq=7 qmin=10 qcomp=0.6 qdiff=4 trellis=1 aspect=%dar threads=4

Result: Output file size 1.9 MB, quality is very poor

25000K, 1 pass, threads=8:
f=mp4 hq=1 acodec=aac ab=384k ar=48000 pix_fmt=yuv420p vcodec=libx264 minrate=0 b=25000k b_strategy=1 subcmp=2 cmp=2 coder=1 flags=+loop flags2=dct8x8 qmax=51 subq=7 qmin=10 qcomp=0.6 qdiff=4 trellis=1 aspect=%dar threads=8

Result: Output file size 2.7 MB, quality is very poor


Why does threads effect file size?


Here are the configure options I was using:

Operating system: Ubuntu 10.04 (64 bit)

x264:
--prefix=/usr/local
--enable-shared

ffmpeg:
--enable-shared
--enable-gpl
--enable-version3
--enable-nonfree
--enable-postproc
--enable-libfaac
--enable-libmp3lame
--enable-libopencore-amrnb
--enable-libopencore-amrwb
--enable-libtheora
--enable-libvorbis
--enable-libx264
--enable-libxvid
--enable-x11grab

mlt:
--prefox=/usr/local
--enable-gpl
--qimage-libdir=/usr/lib
--qimage-includedir=/usr/include/qt4
--avformat-swscale

After playing around for a while, I found that using single pass, setting threads to 0, and setting the crf (between 15 and 25) results in all cores being used, and no degradation of video quality (like I was seeing before).

However, two pass rendering still produces a file with only audio, no video at all.

For reference, here is the profile I am using:

f=mp4 hq=1 acodec=aac ab=384k ar=48000 pix_fmt=yuv420p vcodec=libx264 minrate=0 b=25000k b_strategy=1 subcmp=2 cmp=2 coder=1 flags=+loop flags2=dct8x8 qmax=51 subq=7 qmin=10 qcomp=0.6 qdiff=4 trellis=1 aspect=%dar threads=0 crf=20

And I'm resizing the video from 1080 to 720 (in order to have two versions) with the following command (not a rendering profile):

ffmpeg -i input.mp4 -s 1280x720 -acodec copy -sameq -sws_flags lanczos -f mp4 -vcodec libx264 -vpre slow -crf 25 -threads 0 out.mp4

If anyone knows how to get two pass rendering to work, I'd love to know.

x264 rendering options reference: http://rob.opendot.cl/index.php/useful-stuff/ffmpeg-x264-encoding-guide/

It works for me. My i7 Linux workstation only has ffmpeg 0.6 with x264 build 85 at the moment, so I tested on OS X with x264 build 98 and a very recent ffmpeg:

ddennedy-macbook:Movies ddennedy$ ffmpeg -version
FFmpeg version SVN-r25102, Copyright (c) 2000-2010 the FFmpeg developers
built on Sep 11 2010 19:08:59 with gcc 4.2.1 (Apple Inc. build 5659)
configuration: --prefix=/opt/local --enable-gpl --enable-postproc --enable-swscale --enable-avfilter --enable-libmp3lame --enable-libvorbis --enable-libtheora --enable-libdirac --enable-libschroedinger --enable-libxvid --enable-libx264 --enable-libvpx --enable-libspeex --mandir=/opt/local/share/man --enable-shared --enable-pthreads --disable-indevs --cc=/usr/bin/gcc-4.2 --arch=x86_64
libavutil 50.26. 0 / 50.26. 0
libavcore 0. 9. 0 / 0. 9. 0
libavcodec 52.88. 0 / 52.88. 0
libavformat 52.78. 4 / 52.78. 4
libavdevice 52. 2. 2 / 52. 2. 2
libavfilter 1.38. 3 / 1.38. 3
libswscale 0.11. 0 / 0.11. 0
libpostproc 51. 2. 0 / 51. 2. 0

ddennedy-macbook:Movies ddennedy$ ls -l test
total 843744
-rw-r--r-- 1 ddennedy ddennedy 215980768 Sep 14 21:17 2threads-dualpass.mp4
-rw-r--r-- 1 ddennedy ddennedy 216013579 Sep 14 20:59 nothreads-dualpass.mp4

Using Serenity "HD DVD" 720p23.98 trailer as input. I played test/2threads-dualpass.mp4, and it is beautiful. I suppose a very recent x264 could have broken something. That is known to happen; it is generally a good idea to have an x264 slightly trailing the ffmpeg version, but not by too much. I do not know exactly by how much - a few months seems reasonable. I will try to soon test heads of everything on my i7 workstation.

You wrote "like I was seeing before." Before what?

I have the same problem. This post I have created 2 days before.
http://www.kdenlive.org/forum/rendering-threads2-option-didnt-work
Current my ffmpeg is even 0.6 and x264 is build 98. I'am trying to keep the dependency chain from my used Packman repository alive.

Because of this ffmpeg Bug, I have to patch ffmpeg out of source rpm to keep the chain alive.
http://kdenlive.org/forum/problem-interlaced-files

It seems the best will be to follow Dan's tip "slightly trailing". Next I'll try to build x264, ffmpeg, mlt, kdenlive all from sources and give up with the Packman repo. I also think about to change from OpenSuse to KXStudio which looks very suitable as producer environment.
Let us keep posted.

@ddennedy
You wrote "like I was seeing before." Before what?

When I attempted to specify the thread count in a single pass, the video rendered, but had terrible quality (compared to not specifying the threads option). Using the crf option made the poor quality issue go away for single pass.

@ddennedy

I recompiled everything from source (x264, ffmpeg, mlt, kdenlive) taking a careful look at the ./configure options, but I still get no video on a 2 pass with the threads option. It works fine without the threads option...but sort of defeats the purpose of the i7.

If you have a link to the video source, I'd like to try rendering the exact same video with the exact same settings as you used, and see what happens.

Here is my ffmpeg -version:

FFmpeg version SVN-r25124, Copyright (c) 2000-2010 the FFmpeg developers
built on Sep 15 2010 09:00:25 with gcc 4.4.3
configuration: --prefix=/usr/local --enable-shared --enable-pic --enable-pthreads --enable-gpl --enable-version3 --enable-nonfree --enable-postproc --enable-swscale --enable-avfilter --enable-libfaac --enable-libmp3lame --enable-libvorbis --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libtheora --enable-libvpx --enable-libx264 --enable-libxvid --enable-x11grab
libavutil 50.27. 0 / 50.27. 0
libavcore 0. 9. 0 / 0. 9. 0
libavcodec 52.89. 0 / 52.89. 0
libavformat 52.78. 5 / 52.78. 5
libavdevice 52. 2. 2 / 52. 2. 2
libavfilter 1.39. 0 / 1.39. 0
libswscale 0.11. 0 / 0.11. 0
libpostproc 51. 2. 0 / 51. 2. 0
FFmpeg SVN-r25124
libavutil 50.27. 0 / 50.27. 0
libavcore 0. 9. 0 / 0. 9. 0
libavcodec 52.89. 0 / 52.89. 0
libavformat 52.78. 5 / 52.78. 5
libavdevice 52. 2. 2 / 52. 2. 2
libavfilter 1.39. 0 / 1.39. 0
libswscale 0.11. 0 / 0.11. 0
libpostproc 51. 2. 0 / 51. 2. 0

I updated my i7 machine to the head revisions of x264 and ffmpeg, and now I reproduce the problem. Manually running 'melt -verbose ... pass=2' I get the message:
[libx264 @ 0x206c410] requested bitrate is too low. estimated minimum is 37 kbps

Without pass=2, I do not get that message, but this displays:

[libx264 @ 0x1fb13b0] 264 - core 104 r1713 c276662 - H.264/MPEG-4 AVC codec -
...
bitrate=200
(AV_CODEC_DEFAULT_BITRATE) - sigh

vcodec=mpeg4 b=5000k works, ffprobe shows 5402 kb/s (~5M plus audio)

Therefore, the basic parsing of bitrate via AVoptions works. To be continued.

This works:
melt -verbose -profile atsc_720p_2398 /home/ddennedy/net/media/videos/trailers/deathrace-clip_h720p.mov out=500 -consumer avformat:test/test.mp4 acodec=aac ab=384k ar=48000 pix_fmt=yuv420p vcodec=libx264 b=5000k aspect=@16/9 vpre=/home/ddennedy/opt/share/ffmpeg/libx264-medium.ffpreset threads=4

So, there is something in Kdenlive's presets that is upsetting x264 and not letting it accept perhaps any of the options. I will have to figure out a combination that works with the new and the older (circa ffmpeg v0.6) stuff.

P.S. You can manually render your project by having Kdenlive generate a render script and then editing the script to remove all the advanced video options and add vpre instead.

The problem is related to B frames. Whether you want B frames or not, please add g=250. If you want B frames, add bf=3. If you do not want B frames, change flags2 to flags2=+dct8x8-wpred. It seems x264 now needs you to disable weighted bi-prediction if you do not want B frames.

The Kdenlive presets are not requesting B frames, and frankly they are in need of some improvement and variety. The variety is being used up by things like bitrate and number of passes, which should not be a part of the preset but rather fields in the dialog. I will see what I can do about that but not making any promises.

I have checked into Subversion this fix for the H.264 profiles that were affected: g=250 bf=3 (same as what the ffmpeg presets call for).