Dear JB,
I am trying to export a 35 minutes interview, using the mpeg4 high quality option.
Export fails immediately. Can ayone reproduce this bug ?
This is today Kdenlive/mlt SVN versions as usual.
For me, this is a sound problem.
Probably since MLT was modified.
Kind regards,
Jean-Michel
i 've the same bug too with pal dv, dv raw ....the movie fall down between 4% proceed.........each times
I have no problem at all using current svn versions of FFMPEG, MLT and Kdenlive. I would recommend that you make sure you don't have several versions of libmlt* in /usr/local/lib and also only one version of libavformat, libavcodec, libpostproc, libavutil.
Then, make distclean in MLT and Kdenlive then recompile... sorry no other idea. Unless you are using a buggy ffmpeg version.
What do you mean by "Only one version of libavformat, libavcodec, libpostproc, libavutil" ?
in Debian, there are several version of theses libraries, used by different programs.
Kind regards,
Jean-Michel
How can I be sure that MLT selects the right libavcodec?
My MLT ./configure option is:
make clean ./configure --prefix=/usr --enable-gpl --enable-shared --enable-theora \ --enable-vorbis --enable-libogg --enable-quicktime --enable-pp --enable-shared-pp \ --enable-motion-est --enable-sox --disable-mmx --avformat-swscale
Ok, then you will need to debug a little:
in a console, type:
gdb kdenlive_renderer
Then type:
run your_project_file.kdenlive real_time=0 resize=hyper -consumer libavformat:test.mpg qscale=0
At the end of the above line, type the parameters that are specific to the format that crashes (for high quality mpeg4 that would be :
format=avi video_rc_min_rate=0 video_bit_rate=8000000 audio_bit_rate=384000 frequency=48000 size=720x576 vcodec=mpeg4 mbd=2 trell=1 v4mv=1 progressive=1 )
The export should begin and crash. When it crashes, type:
bt
It will print a backtrace on screen, send it to me...
Dear JB,
The video displays fine on screen.
It does not seem to crash:
run projet.kdenlive real_time=0 resize=hyper -consumer libavformat:test.avi qscale=0 format=avi video_rc_min_rate=0 video_bit_rate=300000 size=720x576 vcodec=xvid acodec=mp3 audio_bit_rate=128000 frequency=44100
Do I miss something?
Hi.
Sorry, my fault. It should be:
-consumer avformat:test.avi
not -consumer libavformat:test.avi
run projet.kdenlive real_time=0 resize=hyper -consumer avformat:test.avi qscale=0 format=avi video_rc_min_rate=0 video_bit_rate=300000 size=720x576 vcodec=xvid acodec=mp3 audio_bit_rate=128000 frequency=44100
gdb kdenlive_renderer GNU gdb 6.6-debian Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "x86_64-linux-gnu"... Using host libthread_db library "/lib/libthread_db.so.1". (gdb) run projet.kdenlive real_time=0 resize=hyper -consumer avformat:test.avi qscale=0 format=avi video_rc_min_rate=0 video_bit_rate=300000 size=720x576 vcodec=xvid acodec=mp3 audio_bit_rate=128000 frequency=44100 Starting program: /usr/bin/kdenlive_renderer projet.kdenlive real_time=0 resize=hyper -consumer avformat:test.avi qscale=0 format=avi video_rc_min_rate=0 video_bit_rate=300000 size=720x576 vcodec=xvid acodec=mp3 audio_bit_rate=128000 frequency=44100 [Thread debugging using libthread_db enabled] [New Thread 47045726803696 (LWP 21928)] [New Thread 1082132800 (LWP 21931)] consumer_avcodec: video codec xvid unrecognised - ignoring Unable to encode audio - disabling audio output. [New Thread 1090525504 (LWP 21932)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1082132800 (LWP 21931)] 0x00002ac9b0cb2cfb in avcodec_encode_audio () from /usr/lib/libavcodec.so.1d (gdb) bt #0 0x00002ac9b0cb2cfb in avcodec_encode_audio () from /usr/lib/libavcodec.so.1d #1 0x00002ac9b07e5642 in consumer_thread (arg=) at consumer_avformat.c:888 #2 0x00002ac9afb44225 in start_thread () from /lib/libpthread.so.0 #3 0x00002ac9af43617d in clone () from /lib/libc.so.6 #4 0x0000000000000000 in ?? ()
Dear JB,
In reply to your message:
dpkg -S /usr/lib/libavcodec.so.1d libavcodec1d: /usr/lib/libavcodec.so.1d
and:
jmpoure@debian:~/logiciels/kdenlive/kdenlive$ ls -l /usr/lib/libav* -rw-r--r-- 1 root root 21728 2006-09-20 14:58 /usr/lib/libavc1394.a -rw-r--r-- 1 root root 830 2006-09-20 14:58 /usr/lib/libavc1394.la lrwxrwxrwx 1 root root 19 2006-10-02 11:18 /usr/lib/libavc1394.so -> libavc1394.so.0.3.0 lrwxrwxrwx 1 root root 19 2006-09-22 00:22 /usr/lib/libavc1394.so.0 -> libavc1394.so.0.3.0 -rw-r--r-- 1 root root 16368 2006-09-20 14:58 /usr/lib/libavc1394.so.0.3.0 -rw-r--r-- 1 root root 5213634 2007-05-30 16:16 /usr/lib/libavcodec.a lrwxrwxrwx 1 root root 16 2007-06-04 11:00 /usr/lib/libavcodec.so -> libavcodec.so.1d lrwxrwxrwx 1 root root 24 2007-03-28 20:24 /usr/lib/libavcodec.so.0d -> libavcodec.so.0d.51.11.0 -rw-r--r-- 1 root root 4116360 2007-03-26 16:28 /usr/lib/libavcodec.so.0d.51.11.0 lrwxrwxrwx 1 root root 24 2007-06-04 11:00 /usr/lib/libavcodec.so.1d -> libavcodec.so.1d.51.38.0 -rw-r--r-- 1 root root 4088976 2007-05-30 16:16 /usr/lib/libavcodec.so.1d.51.38.0 lrwxrwxrwx 1 root root 21 2007-06-04 11:00 /usr/lib/libavcodec.so.51 -> libavcodec.so.51.40.4 -rw-r--r-- 1 root root 3993840 2007-06-02 09:22 /usr/lib/libavcodec.so.51.40.4 -rw-r--r-- 1 root root 1016816 2007-06-02 09:23 /usr/lib/libavformat.a lrwxrwxrwx 1 root root 22 2007-06-04 11:00 /usr/lib/libavformat.so -> libavformat.so.51.12.1 lrwxrwxrwx 1 root root 24 2007-03-28 20:24 /usr/lib/libavformat.so.0d -> libavformat.so.0d.50.5.0 -rw-r--r-- 1 root root 533200 2007-03-26 16:28 /usr/lib/libavformat.so.0d.50.5.0 lrwxrwxrwx 1 root root 25 2007-06-08 10:00 /usr/lib/libavformat.so.1d -> libavformat.so.1d.51.10.0 -rw-r--r-- 1 root root 546464 2007-05-30 16:16 /usr/lib/libavformat.so.1d.51.10.0 lrwxrwxrwx 1 root root 22 2007-06-04 11:00 /usr/lib/libavformat.so.51 -> libavformat.so.51.12.1 -rw-r--r-- 1 root root 557672 2007-06-02 09:23 /usr/lib/libavformat.so.51.12.1 lrwxrwxrwx 1 root root 24 2007-01-22 10:34 /usr/lib/libaviplay-0.7.so.0 -> libaviplay-0.7.so.0.0.44 -rw-r--r-- 1 root root 673216 2006-11-08 11:05 /usr/lib/libaviplay-0.7.so.0.0.44 lrwxrwxrwx 1 root root 31 2007-01-22 10:34 /usr/lib/libaviplayavcodec-0.7.so.0 -> libaviplayavcodec-0.7.so.0.0.44 -rw-r--r-- 1 root root 2534496 2006-11-08 11:05 /usr/lib/libaviplayavcodec-0.7.so.0.0.44 lrwxrwxrwx 1 root root 32 2007-01-22 10:34 /usr/lib/libaviplayavformat-0.7.so.0 -> libaviplayavformat-0.7.so.0.0.44 -rw-r--r-- 1 root root 417344 2006-11-08 11:05 /usr/lib/libaviplayavformat-0.7.so.0.0.44 lrwxrwxrwx 1 root root 30 2007-01-22 10:34 /usr/lib/libaviplayavutil-0.7.so.0 -> libaviplayavutil-0.7.so.0.0.44 -rw-r--r-- 1 root root 17096 2006-11-08 11:05 /usr/lib/libaviplayavutil-0.7.so.0.0.44 -rw-r--r-- 1 root root 51238 2007-05-30 16:16 /usr/lib/libavutil.a lrwxrwxrwx 1 root root 15 2007-06-04 11:00 /usr/lib/libavutil.so -> libavutil.so.1d lrwxrwxrwx 1 root root 22 2007-03-28 20:24 /usr/lib/libavutil.so.0d -> libavutil.so.0d.49.0.0 -rw-r--r-- 1 root root 16832 2007-03-26 16:28 /usr/lib/libavutil.so.0d.49.0.0 lrwxrwxrwx 1 root root 22 2007-06-04 11:00 /usr/lib/libavutil.so.1d -> libavutil.so.1d.49.3.0 -rw-r--r-- 1 root root 27544 2007-05-30 16:16 /usr/lib/libavutil.so.1d.49.3.0 lrwxrwxrwx 1 root root 19 2007-06-04 10:14 /usr/lib/libavutil.so.49 -> libavutil.so.49.4.0 -rw-r--r-- 1 root root 27256 2007-06-02 09:23 /usr/lib/libavutil.so.49.4.0
One more information. This command line results in a very large export file, of very high quality :
vcodec=mpeg4 size=720x576 video_rc_min_rate=0 video_bit_rate=300000 acodec=mp2 audio_bit_rate=128000 frequency=44100
I still have the same problem with inigo:
inigo projet.kdenlive -consumer avformat:rendered_file.avi real_time=0 qscale=0 format=avi video_rc_min_rate=0 video_bit_rate=300000 size=720x576 vcodec=mpeg4 acodec=mp2 audio_bit_rate=128000 frequency=44100
Inigo will not take into account video bitrate.
jmpoure, do the temporary westley files generated for export jobs look like they were chopped at the end?
They are files named /tmp/kde-USERNAME/kdenliveRANDOMSTRING.tmp.
In my case their ends look like this:
....
or:
I've tried some of the ideas from this thread to track down the problem. Here are my observations:
1) I've had multiple versions of libavformat and libavcodec on Ubuntu Feisty. I've uninstalled the older ones (from the official Ubuntu repositories) and left out only the latest from
http://ubuntu.tonio.homelinux.org/
.
Then I've rebuilt mlt, mlt++ and kdenlive. It didn't solve the problem.
2) I've launched kdenlive_renderer from gdb:
gdb kdenlive_renderer ... (gdb) run KDEnlive_project_2.kdenlive real_time=0 resize=hyper in=0 out=17057 -consumer avformat /home/olo/Movies_temp/output/from_KDEnlive_4.vob aspect_ratio=1.06667 display_ratio=1.33333 format=dvd aspect=4:3 vcodec=mpeg2video acodec=ac3 video_bit_rate=6500000 video_rc_max_rate=8000000 video_rc_min_rate=0 video_rc_buffer_size=1835008 mux_packet_size=2048 mux_rate=10080000 audio_bit_rate=192000 audio_sample_rate=48000 frame_size=720x576 frame_rate=25 gop_size=15 me_range=63 real_time=0 stats_on=1 qscale=0 > /home/olo/Movies_temp/output/from_KDEnlive_4_STDOUT.vob Starting program: /usr/bin/kdenlive_renderer KDEnlive_project_2.kdenlive real_time=0 resize=hyper in=0 out=17057 -consumer avformat /home/olo/Movies_temp/output/from_KDEnlive_4.vob aspect_ratio=1.06667 display_ratio=1.33333 format=dvd aspect=4:3 vcodec=mpeg2video acodec=ac3 video_bit_rate=6500000 video_rc_max_rate=8000000 video_rc_min_rate=0 video_rc_buffer_size=1835008 mux_packet_size=2048 mux_rate=10080000 audio_bit_rate=192000 audio_sample_rate=48000 frame_size=720x576 frame_rate=25 gop_size=15 me_range=63 real_time=0 stats_on=1 qscale=0 > /home/olo/Movies_temp/output/from_KDEnlive_4_STDOUT.vob [Thread debugging using libthread_db enabled] [New Thread -1208846656 (LWP 16086)] [New Thread -1216861296 (LWP 16089)] [New Thread -1227760752 (LWP 16090)] [Thread -1216861296 (LWP 16089) exited] [Thread -1227760752 (LWP 16090) exited] Program exited normally. (gdb)
It didn't crash, exited normally but it has interrupted the the job in the middle (the output VOB has a length of 00:03:53, while the project has 00:11:22).
3) The project files saved by KDEnlive (both tempporary and File->Save As) seem corrupted - it looks like some portion of XML is chopped off at the end. Maybe the renderer exits when an internal inconsistency occurs because of incomplete project data?
4) kdenlive_renderer sends its output to STDOUT - is this behaviour correct?
One more observation:
5) Looking at kdenlive_renderer commandline:
kdenlive_renderer KDEnlive_project_2.kdenlive real_time=0 resize=hyper in=0 out=17057 -consumer avformat /home/olo/Movies_temp/output/from_KDEnlive_4.vob aspect_ratio=1.06667 display_ratio=1.33333 format=dvd aspect=4:3 vcodec=mpeg2video acodec=ac3 video_bit_rate=6500000 video_rc_max_rate=8000000 video_rc_min_rate=0 video_rc_buffer_size=1835008 mux_packet_size=2048 mux_rate=10080000 audio_bit_rate=192000 audio_sample_rate=48000 frame_size=720x576 frame_rate=25 gop_size=15 me_range=63 real_time=0 stats_on=1 qscale=0
I can see that there's a file argument after "-consumer avformat". kdenlive_renderer won't start if this file doesn't exist or isn't a valid VOB file (it outputs the "Usage: kdenlive_renderer ..." help message), but if the VOB file exists, it starts the job but doesn't write to that file (maybe it reads from it?).
Now that's interesting. kdenlive_renderer, when called from kdenlive, crashes with SIGSEGV in fact.
It dumps core, and I've extracted some backtraces from the core (unfortunately, stack seems corrupt in those):
$ gdb /usr/bin/kdenlive_renderer ~/core.30028 ... Loaded symbols for /usr/lib/gtk-2.0/2.10.0/loaders/libpixbufloader-png.so Core was generated by `kdenlive_renderer /tmp/kde-olo/kdenliveKZzlac.westley real_time=0 resize=hyper'. Program terminated with signal 6, Aborted. #0 0xffffe410 in __kernel_vsyscall () (gdb) info threads 2 process 30028 0xb7effefd in mlt_property_get_position (this=0x8079310) at mlt_property.c:206 * 1 process 30029 0xffffe410 in __kernel_vsyscall () (gdb) thread apply all bt Thread 2 (process 30028): #0 0xb7effefd in mlt_property_get_position (this=0x8079310) at mlt_property.c:206 #1 0xb7f00ee1 in mlt_properties_get_position (this=0x8078018, name=0xb7f10720 "_position") at mlt_properties.c:663 #2 0xb7f055e5 in mlt_producer_position (this=0x8078018) at mlt_producer.c:274 #3 0x08048bbc in transport (producer=0x8078018, consumer=0x8083010) at /home/opt/soft/Graphics/KDEnlive/SVN/build/2007-06-10.2/kdenlive/renderer/kdenlive_renderer.c:43 #4 0x08048fa4 in main (argc=29, argv=0xbfe2cd94) at /home/opt/soft/Graphics/KDEnlive/SVN/build/2007-06-10.2/kdenlive/renderer/kdenlive_renderer.c:147 Thread 1 (process 30029): #0 0xffffe410 in __kernel_vsyscall () #1 0x45a72df0 in raise () from /lib/tls/i686/cmov/libc.so.6 #2 0x45a74641 in abort () from /lib/tls/i686/cmov/libc.so.6 #3 0x45a6c43b in __assert_fail () from /lib/tls/i686/cmov/libc.so.6 #4 0x4dd4e95a in ff_rate_estimate_qscale () from /usr/lib/libavcodec.so.1d #5 0x08613b08 in ?? () #6 0x08613788 in ?? () #7 0xb7f107de in ?? () from /usr/lib/libmlt.so.0.2.3 #8 0x45aacb54 in _IO_setb_internal () from /lib/tls/i686/cmov/libc.so.6 Backtrace stopped: previous frame inner to this frame (corrupt stack?) (gdb)
BTW, the above was reproduced using a clean build, with this afternoon's SVN version of mlt, mlt++ and kdenlive.
I've also removed all older versions of libavformat, libavcodec, libpostproc, libavutil before compiling to make sure the build is absolutelty clean.
Currently I have only FFMPEG libraries from
http://ubuntu.tonio.homelinux.org/
, their version is from CVS from 2007-03-07:
# dpkg -l | grep ffmpeg ii ffmpeg 0.cvs20070307-4ubuntu1 multimedia player, server and encoder rc libavcodec0d 0.cvs20060823-3.1ubuntu4 ffmpeg codec library ii libavcodec1d 0.cvs20070307-4ubuntu1 ffmpeg codec library rc libavformat0d 0.cvs20060823-3.1ubuntu4 ffmpeg file format library ii libavformat1d 0.cvs20070307-4ubuntu1 ffmpeg file format library ii libavutil1d 0.cvs20070307-4ubuntu1 ffmpeg utility library rc libpostproc0d 0.cvs20060823-3.1ubuntu4 ffmpeg video postprocessing library ii libpostproc1d 0.cvs20070307-4ubuntu1 ffmpeg video postprocessing library ii libswscale1d 0.cvs20070307-4ubuntu1 ffmpeg video scaling library ii libxine1-ffmpeg 1.1.6-1 mpeg related plugins for libxine1
You can see the old libraries in the rc state.
According to
http://www.infodrom.org/Debian/doc/main ... ml#s3.10.3
, it means "rc - The package is removed, won't get reinstalled but still has its configuration files installed." - so those libraries aren't present in the system anymore.
The previous backtrace was from exporting the timeline to DVD format.
Here's a backtrace from exporting the timeline to XviD 720x576 in medum quality:
Core was generated by `kdenlive_renderer /tmp/kde-olo/kdenliveLx47nb.westley real_time=0 resize=hyper'. Program terminated with signal 6, Aborted. #0 0xffffe410 in __kernel_vsyscall () (gdb) info threads 2 process 30877 0xb7fbe2ef in mlt_properties_get_int (this=0x8078018, name=0x804913b "done") at mlt_properties.c:290 * 1 process 30878 0xffffe410 in __kernel_vsyscall () (gdb) thread apply all bt Thread 2 (process 30877): #0 0xb7fbe2ef in mlt_properties_get_int (this=0x8078018, name=0x804913b "done") at mlt_properties.c:290 #1 0x08048bfc in transport (producer=0x8078018, consumer=0x8082d20) at /home/opt/soft/Graphics/KDEnlive/SVN/build/2007-06-10.2/kdenlive/renderer/kdenlive_renderer.c:40 #2 0x08048fa4 in main (argc=21, argv=0xbfb2bb54) at /home/opt/soft/Graphics/KDEnlive/SVN/build/2007-06-10.2/kdenlive/renderer/kdenlive_renderer.c:147 Thread 1 (process 30878): #0 0xffffe410 in __kernel_vsyscall () #1 0x45a72df0 in raise () from /lib/tls/i686/cmov/libc.so.6 #2 0x45a74641 in abort () from /lib/tls/i686/cmov/libc.so.6 #3 0x45a6c43b in __assert_fail () from /lib/tls/i686/cmov/libc.so.6 #4 0x4dd4e95a in ff_rate_estimate_qscale () from /usr/lib/libavcodec.so.1d #5 0x00000010 in ?? () #6 0x00000000 in ?? () (gdb)
From exporting to XviD 320x200 in medium quality:
Core was generated by `kdenlive_renderer /tmp/kde-olo/kdenlive3I6cVa.westley real_time=0 resize=hyper'. Program terminated with signal 6, Aborted. #0 0xffffe410 in __kernel_vsyscall () (gdb) info threads 2 process 30901 0xb7fc95e0 in mlt_producer_position (this=0x8078018) at mlt_producer.c:274 * 1 process 30902 0xffffe410 in __kernel_vsyscall () (gdb) thread apply all bt Thread 2 (process 30901): #0 0xb7fc95e0 in mlt_producer_position (this=0x8078018) at mlt_producer.c:274 #1 0x08048bbc in transport (producer=0x8078018, consumer=0x8082d20) at /home/opt/soft/Graphics/KDEnlive/SVN/build/2007-06-10.2/kdenlive/renderer/kdenlive_renderer.c:43 #2 0x08048fa4 in main (argc=21, argv=0xbfe5e684) at /home/opt/soft/Graphics/KDEnlive/SVN/build/2007-06-10.2/kdenlive/renderer/kdenlive_renderer.c:147 Thread 1 (process 30902): #0 0xffffe410 in __kernel_vsyscall () #1 0x45a72df0 in raise () from /lib/tls/i686/cmov/libc.so.6 #2 0x45a74641 in abort () from /lib/tls/i686/cmov/libc.so.6 #3 0x45a6c43b in __assert_fail () from /lib/tls/i686/cmov/libc.so.6 #4 0x4dd4e95a in ff_rate_estimate_qscale () from /usr/lib/libavcodec.so.1d #5 0x00000010 in ?? () #6 0x00000000 in ?? () (gdb)
What's interesting - export to Theora (320x240, medium quality) and Quicktime (720x480, medium quality) doesn't crash!
Also earlier attempts to export to small XviD (320x200, high quality) have succeeded - but now they crash.
MPEG4 320x200, Flash 320x240 crash, but ordinary MPEG exports fine in 320x200 while it crashes in 640x480 and 720x576.
So this problem largely depends on output format.
Ok, I think I may know what your problem is. Both of you have a debian version of FFMPEG. There was a bug in FFMPEG some time ago that required the qscale parameter to be set to 1 or that would cause crashes on export. 3 weeks ago I realised that this setting caused the avformat producer to ignore video bitrate setting, and also that the crash in FFMPEG had disappeared.
So I reverted the qscale default value to 0 ( see my commit:
http://svn.sourceforge.net/viewvc/kdenl ... 16&r2=1517
)
But I left it by default at 1 in MLT's inigo player. That seems to explain everything, haha!
I just comited a fix to Kdenlive that will allow you to override the default qscale value. So please both of you, update your Kdenlive svn, and try adding qscale=1 to your avformat parameters. This should fix your crash, but the video bitrate will not work anymore.
Then, the real solution will be to find an updated FFMPEG version that does not crash on qscale=0...
Waiting for your feedback.
jb
Do we have to create custom encoding options, or did I miss UI to set only this?
BTW, the corrupted XML in saved projects seems a different unrelated problem?
Dear JB,
Some time ago, you informed me that my MLT was linked against an old version of ffmeg.
How can I sure to compile MLT against a recent version of ffmeg?
Read this thread :
Marrilat compiled libavformat and mlt in a chroot, which is not my case.
How can I choose the version of libavformat I am compiling against?
Kind regards,
Jean-Michel
OK, I've created 2 custom export settings based on DVD export template, and appended qscale=1 to the first and qscale=0.
The qscale=1 job proceeds successfully, the qscale=0 crashes after exporting a couple of seconds.
So you were totally right.
BTW, I like the new default GUI layout with the latest SVN version, especially the fact that project tree is on by default :)
How can I be sure that MLT selects the right libavcodec?
try
ldd ./kdenlive
or more detailed
LD_DEBUG=libs ./kdenlive
in directory where your make install your kdenlive
In my case it's:
28168: find library=libavcodec.so.1d [0]; searching
28168: trying file=/usr/lib/i686/cmov/libavcodec.so.1d
28168: trying file=/usr/lib/i686/libavcodec.so.1d
28168: trying file=/usr/lib/libavcodec.so.1d
28168: calling init: /usr/lib/libavcodec.so.1d
28168: calling fini: /usr/lib/libavcodec.so.1d [0]
...
$ dpkg -S /usr/lib/libavcodec.so.1d
libavcodec1d: /usr/lib/libavcodec.so.1d
$ dpkg -l libavcodec1d
ii libavcodec1d 0.cvs20070307-4ubuntu1 ffmpeg codec library
Seems quite recent (2007-03-07). What versions of ffmpeg have that bug fixed? I've googled out a discussion about qscale-related crash in FFmpeg from September 2005, but this one must be a different one?
So the /usr/lib/libavcodec.so.1d was used, the distribution version. Is that what you wanted?
I wrote a more detailed HOWTO:
Try my build script from this post (I need some tester's ;-)
It's an easy to use way how to build latest ffmpeg + mlt + Kdenlive from the latest vanilla sources with suggested config parameters.
And try it again and share the results with us.
So the /usr/lib/libavcodec.so.1d was used, the distribution version. Is that what you wanted?
I wrote a more detailed HOWTO:
Well, it's not the distribution version, but a newer version from a cutting edge repository located here:
http://ubuntu.tonio.homelinux.org/
The distribution version was "libavformat0d 0.cvs20060823-3.1ubuntu4".
The version from Tonio, which I have installed, is "libavformat1d 0.cvs20070307-4ubuntu1".
Try my build script from this post (I need some tester's ;-)
It's an easy to use way how to build latest ffmpeg + mlt + Kdenlive from the latest vanilla sources with suggested config parameters.
And try it again and share the results with us.
I'm afraid of breaking my FFmpeg installation this way, since your scripts installs the latest version in /usr.
But what about the "--avformat-svn" configure option for MLT?
It seems that with this option, the latest SVN version of FFmpeg is checked out and built in the build directory, then MLT is linked statically with it. It would guarantee running with the latest FFmpeg version.
I've used it to build MLT today:
./configure --prefix=/usr --enable-debug --enable-gpl --enable-shared --enable-theora --enable-vorbis --enable-libogg --enable-pp --enable-shared-pp --enable-motion-est --avformat-swscale --avformat-svn
I could see the FFmpeg being checked out and built during MLT build, it has definitely happened. I can provide build logs as a proof.
Then I've build and installed MLT++ and KDEnlive (today's SVN versions, too) and run kdenlive with LD_DEBUG=libs.
As expected, no libavformat (nor libavcodec) has shown up this time (because it was statically linked into MLT - as I understand it).
So, currently, I should be using the latest, today's version of FFmpeg when running KDEnlive/MLT.
But still, when I do the timeframe export to DVD format, kdenlive_renderer crashes.
A new fact: I've observed that renderer crashes only when it reaches a transition between two tracks (a crosfade in of a text clip and a DV video clip in my case). And it has to be a transition between text clip and video clip - a crossfade transition between two video clips doesn't cause a crash!
When I've created a timeline consisting of a single clip, or two video clips crossfading at one point, the export went fine.
So the crash is very dependent on project contents.
I'm afraid of breaking my FFmpeg installation this way, since your scripts installs the latest version in /usr.
Noooooo! The exact opposite is true! The reason why I created and published this script was to easy and SAFE way how compile it all not breaking anything in your system. All libs, including kdenlive binary, is encapsulated in selected directory. Please read carefully the description.
I cannot help you with the Ubuntu packages, I don't use Ubuntu but SUSE or PCLinux. I can only recommend to compile ffmpeg + mtl + Kdenlive from latest sources, these are the version developers use, this only can exclude buggy (nonstandard) distribution components.
OK, you're right.
So I've used your script with minor modifications needed to get it working on my system:
--- espinosa_script.sh 2007-06-19 23:00:47.000000000 +0200 +++ espinosa_script-olo.sh 2007-06-20 03:05:25.000000000 +0200 @@ -21,18 +21,18 @@ # Modify the destination directory if you want # Or you can copy it afterwars to /opt/kdenlive-or wherever you want. # Caution: if you pick /usr here, you system kdenlive, ffmpeg and mlt will be overwritten! -export DEST_DIR=~/build/kdenlive +export DEST_DIR=~/misc/soft/Graphics/KDEnlive/SVN/espinosa/build case "$1" in "getsources") -cd ffmpeg +#cd ffmpeg svn checkout svn://svn.mplayerhq.hu/ffmpeg/trunk ffmpeg -cd ../mlt +#cd ../mlt svn co https://mlt.svn.sourceforge.net/svnroot/mlt/trunk/mlt mlt -cd ../mlt++ +#cd ../mlt++ svn co https://mlt.svn.sourceforge.net/svnroot/mlt/trunk/mlt++ mlt++ -cd ../kdenlive +#cd ../kdenlive svn co https://svn.sourceforge.net/svnroot/kdenlive/trunk/kdenlive ;; @@ -58,8 +58,8 @@ ./configure --prefix=$DEST_DIR --enable-gpl --enable-shared --enable-swscaler \ --enable-libogg --enable-pp --enable-libtheora --enable-libmp3lame \ ---enable-libfaac --enable-libfaad --enable-libvorbis --enable-liba52 \ ---enable-vhook --enable-x11grab --enable-libx264 && +--enable-libvorbis --enable-liba52 \ +--enable-vhook --enable-x11grab && make && make install &&
As you can see I've commented some "cd" commands that didn't make sense and removed some configure options because those libs in my system aren't accepted by configure (wrong versions, probably).
It has built successfully and I've run it with LD_DEBUG=libs.
KDEnlive uses FFmpeg that was checked out from SVN by your script:
$ egrep '(av|swscale)' screenlog.3 | grep calling
5092: calling init: /home/olo/misc/soft/Graphics/KDEnlive/SVN/espinosa/build/lib/libavutil.so.49
5092: calling init: /home/olo/misc/soft/Graphics/KDEnlive/SVN/espinosa/build/lib/libswscale.so.0
5092: calling init: /home/olo/misc/soft/Graphics/KDEnlive/SVN/espinosa/build/lib/libavcodec.so.51
5092: calling init: /home/olo/misc/soft/Graphics/KDEnlive/SVN/espinosa/build/lib/libavformat.so.51
5092: calling init: /home/olo/misc/soft/Graphics/KDEnlive/SVN/espinosa/build/share/mlt/modules/libmltavformat.so
5092: calling fini: /home/olo/misc/soft/Graphics/KDEnlive/SVN/espinosa/build/share/mlt/modules/libmltavformat.so [0]
5092: calling fini: /home/olo/misc/soft/Graphics/KDEnlive/SVN/espinosa/build/lib/libavformat.so.51 [0]
5092: calling fini: /home/olo/misc/soft/Graphics/KDEnlive/SVN/espinosa/build/lib/libavcodec.so.51 [0]
5092: calling fini: /home/olo/misc/soft/Graphics/KDEnlive/SVN/espinosa/build/lib/libswscale.so.0 [0]
5092: calling fini: /home/olo/misc/soft/Graphics/KDEnlive/SVN/espinosa/build/lib/libavutil.so.49 [0]
So I'm using the today's SVN version of FFmpeg.
The crash still occurs when the render process reaches the timeline point where crossfade transition between a text clip and video clip begins.
This is related to export options (qscale=1 results in no crash), but also depends on project content. I suspect a bug in kdenlive_renderer or a not yet known bug in FFmpeg (or both).
The most bizarre thing in all this is that kdenlive_renderer doesn't crash if I run it from shell.
I use "ps xuwa" to extract the full command line of kdenlive_renderer immediately after beginning export from KDEnlive before renderer crashes.
I also make a copy of the temporary kdenliveXXXXXX.westley file that's placed in /tmp during export.
Then I run:
kdenlive_renderer kdenliveI9D3ha.westley real_time=0 resize=hyper in=0 out=1036 -consumer avformat test1.vob real_time=0 stats_on=1 qscale=0 aspect_ratio=1.06667 display_ratio=1.33333 format=dvd aspect=4:3 vcodec=mpeg2video acodec=ac3 video_bit_rate=6500000 video_rc_max_rate=8000000 video_rc_min_rate=0 video_rc_buffer_size=1835008 mux_packet_size=2048 mux_rate=10080000 audio_bit_rate=192000 audio_sample_rate=48000 frame_size=720x576 frame_rate=25 gop_size=15 me_range=63 ildct=1 ilme=1 profile=dv > test1_out.vob
The result is a rendered DVD-quality VOB in test1_out.vob. The crossfade is rendered successfully and there's no crash.
Maybe something in the environment confuses kdenlive_renderer when it's run from KDEnlive?
Are you sure that you know which kdenlive_renderer is called by kdenlive you have just tested?
Check my bugreport about kdenlive_renderer search path.
Have you set PATH=.:$PATH enabling Kdenlive to preferably pick kdenlive_renderer from the same directory as is kdenlive itself?
As you can see I've commented some "cd" commands that didn't make sense ...
??
What is you directory structure of kdenlive and its subproject? They are in separate directories aren't they?
kdenlive_builder suppose this structure:
/kdenlive /ffmpeg /mlt /mlt++
... and removed some configure options because those libs in my system aren't accepted by configure (wrong versions, probably).
OK, but you will miss some Kdenlive capacities. You will not be able to edit movies with mp3 audio codec for example and many more.
Please, post any problems, alterations, recommendations, etc to this separate thread:
Thank you
Are you sure that you know which kdenlive_renderer is called by kdenlive you have just tested?
Check my bugreport about kdenlive_renderer search path.
Have you setPATH=.:$PATHenabling Kdenlive to preferably pick kdenlive_renderer from the same directory as is kdenlive itself?
The system-wide installed in /usr, build from SVN - there's currently no other, since in this case the point was to make it crash. And it didn't.
I had a problem exporting to Mpeg2. On the first transition, the export stops. I added qscale=1 and it succeeded.
I've tried building MLT and KDEnlive with all the debug symbols, and linked with Electric Fence (http://en.wikipedia.org/wiki/Electric_Fence) in order to catch where exactly does it crash.
The build is performed using a modified version of espinosa_cz's build script (see attachment).
I have aproblem, however. Electric Fence detects a zero-size malloc when KDEnlive displays its splash screen on startup. The cause seems to be in QT libraries:
$ gdb bin/kdenlive
GNU gdb 6.6-debian
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...
Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
(gdb) run
Starting program: /home/opt/soft/Graphics/KDEnlive/SVN/espinosa/build/bin/kdenlive
[Thread debugging using libthread_db enabled]
[New Thread -1209444656 (LWP 597)]
Electric Fence 2.1 Copyright (C) 1987-1998 Bruce Perens.
Qt: gdb: -nograb added to command-line options.
Use the -dograb option to enforce grabbing.
X Error: BadDevice, invalid or uninitialized input device 169
Major opcode: 145
Minor opcode: 3
Resource id: 0x0
Failed to open device
X Error: BadDevice, invalid or uninitialized input device 169
Major opcode: 145
Minor opcode: 3
Resource id: 0x0
Failed to open device
ElectricFence Aborting: Allocating 0 bytes, probably a bug.
Program received signal SIGILL, Illegal instruction.
[Switching to Thread -1209444656 (LWP 597)]
0xffffe410 in __kernel_vsyscall ()
(gdb) bt
#0 0xffffe410 in __kernel_vsyscall ()
#1 0x45a73226 in kill () from /lib/tls/i686/cmov/libc.so.6
#2 0xb7f12c54 in EF_Abort () from /usr/lib/libefence.so.0
#3 0xb7f1271b in memalign () from /usr/lib/libefence.so.0
#4 0xb7f1288b in malloc () from /usr/lib/libefence.so.0
#5 0x4c4e5b59 in QRegion::clipRectangles (this=0xbf8e1c44, num=@0xbf8e1c0c) at kernel/qregion_x11.cpp:2882
#6 0x4c4e493a in qt_getClipRects (r=@0xbf8e1c44, num=@0xbf8e1c0c) at kernel/qpainter_x11.cpp:140
#7 0x4c4dad9d in x11SetClipRegion (dpy=0xb6f27ac4, gc=0xabebcf90, gc2=0xabed2f90, draw=2883231692, r=@0xbf8e1c44) at kernel/qpainter_x11.cpp:146
#8 0x4c4e227a in QPainter::setClipping (this=0xbf8e1f6c, enable=true) at kernel/qpainter_x11.cpp:1474
#9 0x4c4e2430 in QPainter::setClipRegion (this=0xbf8e1f6c, rgn=@0xbf8e1dc8, m=QPainter::CoordDevice) at kernel/qpainter_x11.cpp:1531
#10 0x4c594712 in qt_format_text (font=@0xbf8e1f8c, _r=@0xbf8e1f2c, tf=134217729, str=@0xabd41ff0, len=14, brect=0x0, tabstops=0, tabarray=0x0, tabarraylen=0,
painter=0xbf8e1f6c) at kernel/qpainter.cpp:3057
#11 0x4c594988 in QPainter::drawText (this=0xbf8e1f6c, r=@0xbf8e1f2c, tf=1, str=@0xabd41ff0, len=14, brect=0x0, internal=0x0) at kernel/qpainter.cpp:2807
#12 0x4c6c7f86 in QSplashScreen::drawContents (this=0xb2abff88, painter=0xbf8e1f6c) at widgets/qsplashscreen.cpp:265
#13 0x4c6c7ffa in QSplashScreen::drawContents (this=0xb2abff88) at widgets/qsplashscreen.cpp:250
#14 0x4c6c8087 in QSplashScreen::repaint (this=0xb2abff88) at widgets/qsplashscreen.cpp:161
#15 0x4c6c82eb in QSplashScreen::message (this=0xb2abff88, message=@0xbf8e2110, alignment=1, color=@0x4ca631b8) at widgets/qsplashscreen.cpp:191
#16 0x0814b510 in KdenliveSplash (this=0xb2abff88, pixmap=@0xbf8e21e8) at /home/opt/soft/Graphics/KDEnlive/SVN/espinosa/kdenlive/kdenlive/kdenlivesplash.cpp:23
#17 0x0813986c in KdenliveApp (this=0xb441bc54, newDoc=false, parent=0x0, name=0x0) at /home/opt/soft/Graphics/KDEnlive/SVN/espinosa/kdenlive/kdenlive/kdenlive.cpp:199
#18 0x08183c55 in main (argc=136472076, argv=0xbf8e2514) at /home/opt/soft/Graphics/KDEnlive/SVN/espinosa/kdenlive/kdenlive/main.cpp:94
(gdb)
Anyone tried debugging KDE apps with Electric Fence? Do they always bomb out prematurely because of some non harmful allocation error in QT? What to try instead of Electric Fence, then?
Are you sure that you know which kdenlive_renderer is called by kdenlive you have just tested?
Check my bugreport about kdenlive_renderer search path.
Have you setPATH=.:$PATHenabling Kdenlive to preferably pick kdenlive_renderer from the same directory as is kdenlive itself?
After trying to debug using Valgrind (too slow for me and lots of unrelated errors I didn't have time to sift through :( ), I've got back to fiddling with paths and linking.
I've discovered that indeed kdenlive renderer was using the system-wide version of mlt, and as a result the system-wide libavformat.
It was also posssible that kdenlive_renderer was called from /usr/bin, not your script's build directory.
So I've written a shell script that initialies environment accordingly before it launches kdenlive:
#!/bin/sh export PATH="/home/olo/misc/soft/Graphics/KDEnlive/SVN/espinosa/build/bin:$PATH" export LD_LIBRARY_PATH=/home/olo/misc/soft/Graphics/KDEnlive/SVN/espinosa/build/lib /home/olo/misc/soft/Graphics/KDEnlive/SVN/espinosa/build/bin/kdenlive
Now I've verified that it launches proper kdenlive_renderer and that renderer loads the proper libraries:
$ export PATH="/home/olo/misc/soft/Graphics/KDEnlive/SVN/espinosa/build/bin:$PATH"
$ export LD_LIBRARY_PATH=/home/olo/misc/soft/Graphics/KDEnlive/SVN/espinosa/build/lib
$ cd /home/olo/misc/soft/Graphics/KDEnlive/SVN/espinosa
$ ldd build/share/mlt/modules/libmltavformat.so
linux-gate.so.1 => (0xffffe000)
libavformat.so.51 => /home/olo/misc/soft/Graphics/KDEnlive/SVN/espinosa/build/lib/libavformat.so.51 (0xb7eaf000)
libavcodec.so.51 => /home/olo/misc/soft/Graphics/KDEnlive/SVN/espinosa/build/lib/libavcodec.so.51 (0xb7a8c000)
libavutil.so.49 => /home/olo/misc/soft/Graphics/KDEnlive/SVN/espinosa/build/lib/libavutil.so.49 (0xb7a82000)
libmlt.so.0.2.3 => /home/olo/misc/soft/Graphics/KDEnlive/SVN/espinosa/build/lib/libmlt.so.0.2.3 (0xb7a5f000)
libswscale.so.0 => /home/olo/misc/soft/Graphics/KDEnlive/SVN/espinosa/build/lib/libswscale.so.0 (0xb7a38000)
libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb78d7000)
libz.so.1 => /usr/lib/libz.so.1 (0xb78c3000)
libogg.so.0 => /usr/lib/libogg.so.0 (0xb78be000)
libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb78ba000)
libX11.so.6 => /usr/lib/libX11.so.6 (0xb77c9000)
libXext.so.6 => /usr/lib/libXext.so.6 (0xb77bb000)
libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7793000)
liba52-0.7.4.so => /usr/lib/liba52-0.7.4.so (0xb7788000)
libmp3lame.so.0 => /usr/lib/libmp3lame.so.0 (0xb76ce000)
libtheora.so.0 => /usr/lib/libtheora.so.0 (0xb7695000)
libvorbis.so.0 => /usr/lib/libvorbis.so.0 (0xb766d000)
libvorbisenc.so.2 => /usr/lib/libvorbisenc.so.2 (0xb7571000)
libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb7559000)
/lib/ld-linux.so.2 (0x80000000)
libXau.so.6 => /usr/lib/libXau.so.6 (0xb7556000)
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb7551000)
$ ldd build/bin/kdenlive_renderer
linux-gate.so.1 => (0xffffe000)
libmlt.so.0.2.3 => /home/olo/misc/soft/Graphics/KDEnlive/SVN/espinosa/build/lib/libmlt.so.0.2.3 (0xb7f8a000)
libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0x45a49000)
libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0x45b92000)
libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0x45b8c000)
libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0x45bbb000)
/lib/ld-linux.so.2 (0x4507a000)
After running kdenlive and launching timeline export to DVD format, I quickly check that it launches the proper kdenlive_renderer binary:
$ ps xuwa | grep kdenlive olo 13883 0.0 0.0 1716 464 pts/4 S+ 10:14 0:00 /bin/sh ./kdenlive.sh olo 13884 16.2 4.3 106128 44756 pts/4 Sl+ 10:14 0:18 /home/olo/misc/soft/Graphics/KDEnlive/SVN/espinosa/build/bin/kdenlive olo 14009 136 1.7 40880 18640 pts/4 Rl+ 10:16 0:01 kdenlive_renderer /tmp/kde-olo/kdenlivesqyfYa.westley real_time=0 resize=hyper in=0 out=234 -consumer avformat /home/olo/Test5.vob real_time=0 stats_on=1 qscale=0 aspect_ratio=1.06667 display_ratio=1.33333 format=dvd aspect=4:3 vcodec=mpeg2video acodec=ac3 video_bit_rate=6500000 video_rc_max_rate=8000000 video_rc_min_rate=0 video_rc_buffer_size=1835008 mux_packet_size=2048 mux_rate=10080000 audio_bit_rate=192000 audio_sample_rate=48000 frame_size=720x576 frame_rate=25 gop_size=15 me_range=63 ildct=1 ilme=1 olo 14012 0.0 0.0 2888 748 pts/7 R+ 10:16 0:00 grep kdenlive olo@stacja:~$ ls -l /proc/14009/exe lrwxrwxrwx 1 olo olo 0 2007-06-29 10:16 /proc/14009/exe -> /home/opt/soft/Graphics/KDEnlive/SVN/espinosa/build/bin/kdenlive_renderer
So now everything should be fine, right? But it still crashes when reaches the transition.
Here's the gdb backtrace, as can be seen, the version of libavcodec that was built from SVN by your script is involved (/home/olo/misc/soft/Graphics/KDEnlive/SVN/espinosa/build/lib/libavcodec.so.51):
Core was generated by `kdenlive_renderer /tmp/kde-olo/kdenlive53d5Fb.westley real_time=0 resize=hyper'. Program terminated with signal 6, Aborted. #0 0xffffe410 in __kernel_vsyscall () (gdb) thread apply all bt Thread 2 (process 14909): #0 0xb7f2b768 in generate_hash (name=0xb7f3d834 "ition") at mlt_properties.c:162 #1 0xb7f2b812 in mlt_properties_find (this=0x80790d8, name=0xb7f3d830 "_position") at mlt_properties.c:277 #2 0xb7f2c3f1 in mlt_properties_get_position (this=0x80790d8, name=0xb7f3d830 "_position") at mlt_properties.c:662 #3 0xb7f2fe34 in mlt_producer_position (this=0x80790d8) at mlt_producer.c:274 #4 0x08048bcc in transport (producer=0x80790d8, consumer=0x80839a0) at /home/opt/soft/Graphics/KDEnlive/SVN/espinosa/kdenlive/renderer/kdenlive_renderer.c:43 #5 0x08048fb4 in main (argc=31, argv=0xbfb0e3b4) at /home/opt/soft/Graphics/KDEnlive/SVN/espinosa/kdenlive/renderer/kdenlive_renderer.c:147 Thread 1 (process 14910): #0 0xffffe410 in __kernel_vsyscall () #1 0x45a72df0 in raise () from /lib/tls/i686/cmov/libc.so.6 #2 0x45a74641 in abort () from /lib/tls/i686/cmov/libc.so.6 #3 0x45a6c43b in __assert_fail () from /lib/tls/i686/cmov/libc.so.6 #4 0xb7b55b13 in ff_rate_estimate_qscale () from /home/olo/misc/soft/Graphics/KDEnlive/SVN/espinosa/build/lib/libavcodec.so.51 #5 0x08249e40 in ?? () #6 0x0824d0d0 in ?? () #7 0x45b85ff4 in ?? () from /lib/tls/i686/cmov/libc.so.6 #8 0x00000000 in ?? () (gdb)
But when I run the same kdenlive_renderer job with the same arguments (extracted from /proc/PID/) from command line, it finishes its job successfully!
The environments of the kdenlive-launched job and manually-launched job are nearly identical - here's the diff between them:
--- 2007-06-29_10_53_19.environ.txt 2007-06-29 11:03:46.000000000 +0200
+++ 2007-06-29_11_03_09.environ.txt 2007-06-29 11:03:53.000000000 +0200
@@ -15,20 +15,21 @@
LC_MONETARY=pl_PL.UTF-8
DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-fAUHgn0pLo,guid=fcc33edf9f66cd436b0806004684b240
LOGNAME=olo
-_=./kdenlive.sh
+_=/bin/sh
WINDOWID=50331676
XTERM_SHELL=/bin/bash
TERM=screen
LC_COLLATE=pl_PL.UTF-8
GTK2_RC_FILES=/home/olo/.gtkrc-2.0-kde
SESSION_MANAGER=local/stacja.amarczuk:/tmp/.ICE-unix/11372
-PATH=/home/olo/misc/soft/Graphics/KDEnlive/SVN/espinosa/build/bin:/home/olo/misc/soft/Graphics/KDEnlive/SVN/espinosa/build/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11:/usr/games:/usr/NX/bin:~/bin
+PATH=/home/olo/misc/soft/Graphics/KDEnlive/SVN/espinosa/build/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11:/usr/games:/usr/NX/bin:~/bin
XCURSOR_THEME=kubuntu
LC_ADDRESS=pl_PL.UTF-8
DISPLAY=:0.0
LANG=en_US.UTF-8
STY=13247.pts-3.stacja
LC_TELEPHONE=pl_PL.UTF-8
+DESKTOP_STARTUP_ID=stacja.amarczuk;1183102586;143712;11375_TIME1233040
LC_MESSAGES=pl_PL.UTF-8
SSH_AUTH_SOCK=/tmp/ssh-ifXHT11239/agent.11239
LC_NAME=pl_PL.UTF-8
@@ -67,6 +68,3 @@
:ku=\EOA:kd=\EOB:kr=\EOC:kl=\EOD:km:
LC_NUMERIC=pl_PL.UTF-8
LC_PAPER=pl_PL.UTF-8
-MLT_NORMALISATION=PAL
-SDL_WINDOWID=67111583
-AUDIODEV=default
I've also tried setting the missing environment options manually then run the manual job:
$ export MLT_NORMALISATION=PAL $ export AUDIODEV=default $ export SDL_WINDOWID=67111583 $ export 'DESKTOP_STARTUP_ID=stacja.amarczuk;1183102586;143712;11375_TIME1233040' $ sh /home/olo/Documents/rsync/repo/QA/KDEnlive/2007-06-29_Export_crash/test_run.sh > ~/Test7_out.vob
BTW, espinosa_cz, would it be possible to link all the libs built by your script statically into the binaries? In order to make sure that no wrong version of FFMPEG or MLT gets linked dynamically by kdenlive or kdenlive_renderer.
jmpoure, could you try the attached scripts to capture a testcase?
First, you have to build KDEnlive using the modified espinosa_script-olo.sh script attached here. Change the DEST_DIR variable in the script to your preferred directory.
Then, modify the the second script, kdenlive-espinosa.sh, (set the build_dir variable to the same value as DEST_DIR in espinosa's script) to launch KDEnlive.
Then take the third script, catch_testcase.sh, set build_dir variable in that script too, then make yourself ready.
In KDEnlive, launch an export of your project, then immediately launch catch_testcase.sh - it will collect some data for a test case (make a copy of your temporary .westley file, all used temporary .PNG files and process the .westley file to use those copies, capture some data about kdenlive_renderer's running environment and generate a script that lets you launch kdenlive_renderer manually).
Then take a look at the generated testcase script - e.g. 2007-06-29_12_38_29_test_run.sh.
If its contents look OK, run it. It should output a .VOB file containing the exported video.
Note if it finishes its work or will it crash. Analyse the other files generated by catch_testcase.sh.
In my case, despite nearly identical environments, kdenlive_renderer doesn't crash and finishes export successfully when run manually, but it crashes when launched by kdenlive.
All scripts are gzipped, otherwise the forum won't let me attach them.
I will try, probably tonight.
I just wanted to add a "me too" to the "export/rendering fails strangely" thread.
Plus a possible fix.
As an example, I create a simple project consisting of two Image clips, one
after the other. Rendering this always crashes before the second clip. (This
is renderig to mpeg or mpeg4, highest resolution and quality).
I did some exploring and found that the rendering is crashing in libavcodec
in ff_rate_estimate_qscale at line 756
assert(q>0.0);
If I comment out that assert and the next one (line 768) but not the last one (line 774).
And then recompile and make sure the new library gets used,
then the rendering works perfectly, at least for that project...
neilbrown, do you mean such changes?
Index: libavcodec/ratecontrol.c
===================================================================
--- libavcodec/ratecontrol.c (revision 9460)
+++ libavcodec/ratecontrol.c (working copy)
@@ -749,7 +749,7 @@
if (q < 0)
return -1;
- assert(q>0.0);
+// assert(q>0.0);
//printf("%f ", q);
q= get_diff_limited_q(s, rce, q);
//printf("%f ", q);
@@ -765,7 +765,7 @@
q= short_term_q= rcc->short_term_qsum/rcc->short_term_qcount;
//printf("%f ", q);
}
- assert(q>0.0);
+// assert(q>0.0);
q= modify_qscale(s, rce, q, picture_number);
I've rebuilt using this modified FFMPEG, but kdenlive_renderer still crashes (and still in ff_rate_estimate_qscale (), too):
... #3 0x45a6c43b in __assert_fail () from /lib/tls/i686/cmov/libc.so.6 #4 0xb7babb9e in ff_rate_estimate_qscale () from /home/olo/misc/soft/Graphics/KDEnlive/SVN/espinosa/build/lib/libavcodec.so.51 ...
Maybe I should eliminate all the assertions from this function not only those two?
But they were probably placed there for a purpose.
Could anybody with a deeper knowledge of FFMPEG comment on the role of those assertions?
There are a lot of asserts there, aren't there!
I think the first one that I commented out is different from the first
one in your patch. I suggest if it is still crashing, comment them all out.
I doubt this is really the "right" solution, but for me it works until something
better comes along. I too would like to know what really is going on here...
You were right, now my diff between FFMPEG SVN and working copy looks like this and I don't experience crashes of kdenlive_renderer in this situation:
Index: libavcodec/ratecontrol.c
===================================================================
--- libavcodec/ratecontrol.c (revision 9460)
+++ libavcodec/ratecontrol.c (working copy)
@@ -749,11 +749,11 @@
if (q < 0)
return -1;
- assert(q>0.0);
+// assert(q>0.0);
//printf("%f ", q);
q= get_diff_limited_q(s, rce, q);
//printf("%f ", q);
- assert(q>0.0);
+// assert(q>0.0);
if(pict_type==P_TYPE || s->intra_only){ //FIXME type dependent blur like in 2-pass
rcc->short_term_qsum*=a->qblur;
@@ -765,7 +765,7 @@
q= short_term_q= rcc->short_term_qsum/rcc->short_term_qcount;
//printf("%f ", q);
}
- assert(q>0.0);
+// assert(q>0.0);
q= modify_qscale(s, rce, q, picture_number);
But it's still intriguing, if those asserts weren't satisfied, then something goes against FFMPEG developers' expectations here. Possibly the rate estimation may work incorrectly. Any ideas how to test that?
I'll also try reducing the number of commented out asserts to determine the minimum count that "fixes" our problem.
Here's the minimal changes that eliminate crashing (2 asserts need to be disabled):
Index: libavcodec/ratecontrol.c
===================================================================
--- libavcodec/ratecontrol.c (revision 9460)
+++ libavcodec/ratecontrol.c (working copy)
@@ -753,7 +753,7 @@
//printf("%f ", q);
q= get_diff_limited_q(s, rce, q);
//printf("%f ", q);
- assert(q>0.0);
+// assert(q>0.0);
if(pict_type==P_TYPE || s->intra_only){ //FIXME type dependent blur like in 2-pass
rcc->short_term_qsum*=a->qblur;
@@ -765,7 +765,7 @@
q= short_term_q= rcc->short_term_qsum/rcc->short_term_qcount;
//printf("%f ", q);
}
- assert(q>0.0);
+// assert(q>0.0);
q= modify_qscale(s, rce, q, picture_number);
Seems to be fixed with the latest FFmpeg Revision: 9505.
Hooray!
Not for me, still crashes like before, FFMPEG revision 9509:
olo@stacja:~/misc/soft/Graphics/KDEnlive/SVN/espinosa$ cd ffmpeg/ olo@stacja:~/misc/soft/Graphics/KDEnlive/SVN/espinosa/ffmpeg$ svn info Path: . URL: svn://svn.mplayerhq.hu/ffmpeg/trunk Repository Root: svn://svn.mplayerhq.hu/ffmpeg Repository UUID: 9553f0bf-9b14-0410-a0b8-cfaf0461ba5b Revision: 9509 Node Kind: directory Schedule: normal Last Changed Author: mru Last Changed Rev: 9509 Last Changed Date: 2007-07-06 20:41:59 +0200 (pią, 06 lip 2007)
And gdb debugging:
gdb build/bin/kdenlive_renderer core.12994 GNU gdb 6.6-debian Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i486-linux-gnu"... Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". warning: core file may not match specified executable file. warning: Can't read pathname for load map: Input/output error. Reading symbols from /home/opt/soft/Graphics/KDEnlive/SVN/espinosa/build/lib/libmlt.so.0.2.3...done. Loaded symbols for /home/olo/misc/soft/Graphics/KDEnlive/SVN/espinosa/build/lib/libmlt.so.0.2.3 Reading symbols from /lib/tls/i686/cmov/libc.so.6...Reading symbols from /usr/lib/debug/lib/tls/i686/cmov/libc-2.5.so...done. done. Loaded symbols for /lib/tls/i686/cmov/libc.so.6 Reading symbols from /lib/tls/i686/cmov/libm.so.6...Reading symbols from /usr/lib/debug/lib/tls/i686/cmov/libm-2.5.so...done. done. Loaded symbols for /lib/tls/i686/cmov/libm.so.6 Reading symbols from /lib/tls/i686/cmov/libdl.so.2...Reading symbols from /usr/lib/debug/lib/tls/i686/cmov/libdl-2.5.so...done. done. Loaded symbols for /lib/tls/i686/cmov/libdl.so.2 Reading symbols from /lib/tls/i686/cmov/libpthread.so.0...Reading symbols from /usr/lib/debug/lib/tls/i686/cmov/libpthread-2.5.so...done. done. Loaded symbols for /lib/tls/i686/cmov/libpthread.so.0 Reading symbols from /lib/ld-linux.so.2...Reading symbols from /usr/lib/debug/lib/ld-2.5.so...done. done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /home/opt/soft/Graphics/KDEnlive/SVN/espinosa/build/share/mlt/modules/libmltinigo.so...done. Loaded symbols for /home/olo/misc/soft/Graphics/KDEnlive/SVN/espinosa/build/share/mlt/modules/libmltinigo.so Reading symbols from /home/opt/soft/Graphics/KDEnlive/SVN/espinosa/build/share/mlt/modules/libmltfezzik.so...done. Loaded symbols for /home/olo/misc/soft/Graphics/KDEnlive/SVN/espinosa/build/share/mlt/modules/libmltfezzik.so Reading symbols from /home/opt/soft/Graphics/KDEnlive/SVN/espinosa/build/share/mlt/modules/libmltwestley.so...done. Loaded symbols for /home/olo/misc/soft/Graphics/KDEnlive/SVN/espinosa/build/share/mlt/modules/libmltwestley.so Reading symbols from /usr/lib/libxml2.so.2...done. Loaded symbols for /usr/lib/libxml2.so.2 Reading symbols from /usr/lib/libz.so.1...done. Loaded symbols for /usr/lib/libz.so.1 Reading symbols from /home/opt/soft/Graphics/KDEnlive/SVN/espinosa/build/share/mlt/modules/libmltavformat.so...done. Loaded symbols for /home/olo/misc/soft/Graphics/KDEnlive/SVN/espinosa/build/share/mlt/modules/libmltavformat.so Reading symbols from /home/opt/soft/Graphics/KDEnlive/SVN/espinosa/build/lib/libavformat.so.51...done. Loaded symbols for /home/olo/misc/soft/Graphics/KDEnlive/SVN/espinosa/build/lib/libavformat.so.51 Reading symbols from /home/opt/soft/Graphics/KDEnlive/SVN/espinosa/build/lib/libavcodec.so.51...done. Loaded symbols for /home/olo/misc/soft/Graphics/KDEnlive/SVN/espinosa/build/lib/libavcodec.so.51 Reading symbols from /home/opt/soft/Graphics/KDEnlive/SVN/espinosa/build/lib/libavutil.so.49...done. Loaded symbols for /home/olo/misc/soft/Graphics/KDEnlive/SVN/espinosa/build/lib/libavutil.so.49 Reading symbols from /home/opt/soft/Graphics/KDEnlive/SVN/espinosa/build/lib/libswscale.so.0...done. Loaded symbols for /home/olo/misc/soft/Graphics/KDEnlive/SVN/espinosa/build/lib/libswscale.so.0 Reading symbols from /usr/lib/libogg.so.0...done. Loaded symbols for /usr/lib/libogg.so.0 Reading symbols from /usr/lib/libX11.so.6...done. Loaded symbols for /usr/lib/libX11.so.6 Reading symbols from /usr/lib/libXext.so.6...done. Loaded symbols for /usr/lib/libXext.so.6 Reading symbols from /usr/lib/liba52-0.7.4.so...done. Loaded symbols for /usr/lib/liba52-0.7.4.so Reading symbols from /usr/lib/libmp3lame.so.0...done. Loaded symbols for /usr/lib/libmp3lame.so.0 Reading symbols from /usr/lib/libtheora.so.0...done. Loaded symbols for /usr/lib/libtheora.so.0 Reading symbols from /usr/lib/libvorbis.so.0...done. Loaded symbols for /usr/lib/libvorbis.so.0 Reading symbols from /usr/lib/libvorbisenc.so.2...done. Loaded symbols for /usr/lib/libvorbisenc.so.2 Reading symbols from /usr/lib/libXau.so.6...done. Loaded symbols for /usr/lib/libXau.so.6 Reading symbols from /usr/lib/libXdmcp.so.6...done. Loaded symbols for /usr/lib/libXdmcp.so.6 Reading symbols from /home/opt/soft/Graphics/KDEnlive/SVN/espinosa/build/share/mlt/modules/libmltcore.so...done. Loaded symbols for /home/olo/misc/soft/Graphics/KDEnlive/SVN/espinosa/build/share/mlt/modules/libmltcore.so Reading symbols from /home/opt/soft/Graphics/KDEnlive/SVN/espinosa/build/share/mlt/modules/libmltxine.so...done. Loaded symbols for /home/olo/misc/soft/Graphics/KDEnlive/SVN/espinosa/build/share/mlt/modules/libmltxine.so Reading symbols from /home/opt/soft/Graphics/KDEnlive/SVN/espinosa/build/share/mlt/modules/libmltgtk2.so...done. Loaded symbols for /home/olo/misc/soft/Graphics/KDEnlive/SVN/espinosa/build/share/mlt/modules/libmltgtk2.so Reading symbols from /usr/lib/libgtk-x11-2.0.so.0...done. Loaded symbols for /usr/lib/libgtk-x11-2.0.so.0 Reading symbols from /usr/lib/libgdk-x11-2.0.so.0...done. Loaded symbols for /usr/lib/libgdk-x11-2.0.so.0 Reading symbols from /usr/lib/libatk-1.0.so.0...done. Loaded symbols for /usr/lib/libatk-1.0.so.0 Reading symbols from /usr/lib/libgdk_pixbuf-2.0.so.0...done. Loaded symbols for /usr/lib/libgdk_pixbuf-2.0.so.0 Reading symbols from /usr/lib/libpangocairo-1.0.so.0...done. Loaded symbols for /usr/lib/libpangocairo-1.0.so.0 Reading symbols from /usr/lib/libfontconfig.so.1...done. Loaded symbols for /usr/lib/libfontconfig.so.1 Reading symbols from /usr/lib/libXrender.so.1...done. Loaded symbols for /usr/lib/libXrender.so.1 Reading symbols from /usr/lib/libXinerama.so.1...done. Loaded symbols for /usr/lib/libXinerama.so.1 Reading symbols from /usr/lib/libXi.so.6...done. Loaded symbols for /usr/lib/libXi.so.6 Reading symbols from /usr/lib/libXrandr.so.2...done. Loaded symbols for /usr/lib/libXrandr.so.2 Reading symbols from /usr/lib/libXcursor.so.1...done. Loaded symbols for /usr/lib/libXcursor.so.1 Reading symbols from /usr/lib/libXfixes.so.3...done. Loaded symbols for /usr/lib/libXfixes.so.3 Reading symbols from /usr/lib/libpango-1.0.so.0...done. Loaded symbols for /usr/lib/libpango-1.0.so.0 Reading symbols from /usr/lib/libcairo.so.2...done. Loaded symbols for /usr/lib/libcairo.so.2 Reading symbols from /usr/lib/libgobject-2.0.so.0...done. Loaded symbols for /usr/lib/libgobject-2.0.so.0 Reading symbols from /usr/lib/libgmodule-2.0.so.0...done. Loaded symbols for /usr/lib/libgmodule-2.0.so.0 Reading symbols from /usr/lib/libglib-2.0.so.0...done. Loaded symbols for /usr/lib/libglib-2.0.so.0 Reading symbols from /usr/lib/libpangoft2-1.0.so.0...done. Loaded symbols for /usr/lib/libpangoft2-1.0.so.0 Reading symbols from /usr/lib/libfreetype.so.6...done. Loaded symbols for /usr/lib/libfreetype.so.6 Reading symbols from /usr/lib/libexpat.so.1...done. Loaded symbols for /usr/lib/libexpat.so.1 Reading symbols from /usr/lib/libpng12.so.0...done. Loaded symbols for /usr/lib/libpng12.so.0 Reading symbols from /home/opt/soft/Graphics/KDEnlive/SVN/espinosa/build/share/mlt/modules/libmltresample.so...done. Loaded symbols for /home/olo/misc/soft/Graphics/KDEnlive/SVN/espinosa/build/share/mlt/modules/libmltresample.so Reading symbols from /usr/lib/libsamplerate.so.0...done. Loaded symbols for /usr/lib/libsamplerate.so.0 Reading symbols from /usr/lib/gtk-2.0/2.10.0/loaders/libpixbufloader-png.so...done. Loaded symbols for /usr/lib/gtk-2.0/2.10.0/loaders/libpixbufloader-png.so Core was generated by `kdenlive_renderer /tmp/kde-olo/kdenlivedYsnna.westley real_time=0 resize=hyper'. Program terminated with signal 6, Aborted. #0 0xffffe410 in __kernel_vsyscall () (gdb) bt #0 0xffffe410 in __kernel_vsyscall () #1 0x45a72df0 in raise () from /lib/tls/i686/cmov/libc.so.6 #2 0x45a74641 in abort () from /lib/tls/i686/cmov/libc.so.6 #3 0x45a6c43b in __assert_fail () from /lib/tls/i686/cmov/libc.so.6 #4 0xb7b74c73 in ff_rate_estimate_qscale () from /home/olo/misc/soft/Graphics/KDEnlive/SVN/espinosa/build/lib/libavcodec.so.51 #5 0x08244338 in ?? () #6 0x0824a3c0 in ?? () #7 0x45b85ff4 in ?? () from /lib/tls/i686/cmov/libc.so.6 #8 0x00000000 in ?? () (gdb) thread apply all bt Thread 2 (process 12994): #0 0xb7f62770 in generate_hash (name=0xb7f74837 "on") at mlt_properties.c:162 #1 0xb7f62812 in mlt_properties_find (this=0x80790d8, name=0xb7f74830 "_position") at mlt_properties.c:277 #2 0xb7f633f1 in mlt_properties_get_position (this=0x80790d8, name=0xb7f74830 "_position") at mlt_properties.c:662 #3 0xb7f66e34 in mlt_producer_position (this=0x80790d8) at mlt_producer.c:274 #4 0x08048bcc in transport (producer=0x80790d8, consumer=0x8083b80) at /home/opt/soft/Graphics/KDEnlive/SVN/espinosa/kdenlive/renderer/kdenlive_renderer.c:43 #5 0x08048fb4 in main (argc=31, argv=0xbfdbe6d4) at /home/opt/soft/Graphics/KDEnlive/SVN/espinosa/kdenlive/renderer/kdenlive_renderer.c:147 Thread 1 (process 12995): #0 0xffffe410 in __kernel_vsyscall () #1 0x45a72df0 in raise () from /lib/tls/i686/cmov/libc.so.6 #2 0x45a74641 in abort () from /lib/tls/i686/cmov/libc.so.6 #3 0x45a6c43b in __assert_fail () from /lib/tls/i686/cmov/libc.so.6 #4 0xb7b74c73 in ff_rate_estimate_qscale () from /home/olo/misc/soft/Graphics/KDEnlive/SVN/espinosa/build/lib/libavcodec.so.51 #5 0x08244338 in ?? () #6 0x0824a3c0 in ?? () #7 0x45b85ff4 in ?? () from /lib/tls/i686/cmov/libc.so.6 #8 0x00000000 in ?? () (gdb) disass $pc-32 $pc+32 Dump of assembler code from 0xffffe3f0 to 0xffffe430: 0xffffe3f0: add %al,(%eax) 0xffffe3f2: add %al,(%eax) 0xffffe3f4: add %al,(%eax) 0xffffe3f6: add %al,(%eax) 0xffffe3f8: add %al,(%eax) 0xffffe3fa: add %al,(%eax) 0xffffe3fc: add %al,(%eax) 0xffffe3fe: add %al,(%eax) 0xffffe400 <__kernel_vsyscall+0>: push %ecx 0xffffe401 <__kernel_vsyscall+1>: push %edx 0xffffe402 <__kernel_vsyscall+2>: push %ebp 0xffffe403 <__kernel_vsyscall+3>: mov %esp,%ebp 0xffffe405 <__kernel_vsyscall+5>: sysenter 0xffffe407 <__kernel_vsyscall+7>: nop 0xffffe408 <__kernel_vsyscall+8>: nop 0xffffe409 <__kernel_vsyscall+9>: nop 0xffffe40a <__kernel_vsyscall+10>: nop 0xffffe40b <__kernel_vsyscall+11>: nop 0xffffe40c <__kernel_vsyscall+12>: nop 0xffffe40d <__kernel_vsyscall+13>: nop 0xffffe40e <__kernel_vsyscall+14>: jmp 0xffffe403 <__kernel_vsyscall+3> 0xffffe410 <__kernel_vsyscall+16>: pop %ebp 0xffffe411 <__kernel_vsyscall+17>: pop %edx 0xffffe412 <__kernel_vsyscall+18>: pop %ecx 0xffffe413 <__kernel_vsyscall+19>: ret 0xffffe414 <_fini+1226892672>: nop 0xffffe415 <_fini+1226892673>: nop 0xffffe416 <_fini+1226892674>: nop 0xffffe417 <_fini+1226892675>: nop 0xffffe418 <_fini+1226892676>: nop 0xffffe419 <_fini+1226892677>: nop 0xffffe41a <_fini+1226892678>: nop 0xffffe41b <_fini+1226892679>: nop 0xffffe41c <_fini+1226892680>: nop 0xffffe41d <_fini+1226892681>: nop 0xffffe41e <_fini+1226892682>: nop 0xffffe41f <_fini+1226892683>: nop 0xffffe420 <__kernel_sigreturn+0>: pop %eax 0xffffe421 <__kernel_sigreturn+1>: mov $0x77,%eax 0xffffe426 <__kernel_sigreturn+6>: int $0x80 0xffffe428 <_fini+1226892692>: nop 0xffffe429 <_fini+1226892693>: nop 0xffffe42a <_fini+1226892694>: nop 0xffffe42b <_fini+1226892695>: nop 0xffffe42c <_fini+1226892696>: nop 0xffffe42d <_fini+1226892697>: nop 0xffffe42e <_fini+1226892698>: nop 0xffffe42f <_fini+1226892699>: nop End of assembler dump. (gdb) info all-registers eax 0x0 0 ecx 0x32c3 12995 edx 0x6 6 ebx 0x32c2 12994 esp 0xb7855e80 0xb7855e80 ebp 0xb7855e98 0xb7855e98 esi 0xb7855f38 -1215996104 edi 0x45b85ff4 1169711092 eip 0xffffe410 0xffffe410 <__kernel_vsyscall+16> eflags 0x200202 [ IF ID ] cs 0x73 115 ss 0x7b 123 ds 0x7b 123 es 0x7b 123 fs 0x0 0 gs 0x33 51 st0(raw 0xffff0000000000000000) st1 0 (raw 0x00000000000000000000) st2 153.1888888888888970996049465611577 (raw 0x400699305b05b05b0800) st3 21609509.142857141792774200439453125 (raw 0x4017a4de129249249000) st4 1.25 (raw 0x3fffa000000000000000) st5 0 (raw 0x00000000000000000000) st6 -0.09014438092708587646484375 (raw 0xbffbb89d9e0000000000) st7 -0.09014438092708587646484375 (raw 0xbffbb89d9e0000000000) fctrl 0x37f 895 fstat 0x120 288 ftag 0xffff 65535 fiseg 0x0 0 fioff 0x0 0 foseg 0x0 0 fooff 0x0 0 fop 0x0 0 xmm0 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {0x0 }, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0}, uint128 = 0x00000000000000000000000000000000} xmm1 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {0x0 }, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0}, uint128 = 0x00000000000000000000000000000000} xmm2 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {0x0 }, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0}, uint128 = 0x00000000000000000000000000000000} xmm3 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {0x0 }, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0}, uint128 = 0x00000000000000000000000000000000} xmm4 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {0x0 }, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0}, uint128 = 0x00000000000000000000000000000000} xmm5 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {0x0 }, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0}, uint128 = 0x00000000000000000000000000000000} xmm6 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {0x0 }, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0}, uint128 = 0x00000000000000000000000000000000} xmm7 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {0x0 }, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0}, uint128 = 0x00000000000000000000000000000000} mxcsr 0x1f80 [ IM DM ZM OM UM PM ] mm0 {uint64 = 0x0, v2_int32 = {0x0, 0x0}, v4_int16 = {0x0, 0x0, 0x0, 0x0}, v8_int8 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}} mm1 {uint64 = 0x0, v2_int32 = {0x0, 0x0}, v4_int16 = {0x0, 0x0, 0x0, 0x0}, v8_int8 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}} mm2 {uint64 = 0x99305b05b05b0800, v2_int32 = {0xb05b0800, 0x99305b05}, v4_int16 = {0x800, 0xb05b, 0x5b05, 0x9930}, v8_int8 = {0x0, 0x8, 0x5b, 0xb0, 0x5, 0x5b, 0x30, 0x99}} mm3 {uint64 = 0xa4de129249249000, v2_int32 = {0x49249000, 0xa4de1292}, v4_int16 = {0x9000, 0x4924, 0x1292, 0xa4de}, v8_int8 = {0x0, 0x90, 0x24, 0x49, 0x92, ---Type to continue, or q to quit--- 0x12, 0xde, 0xa4}} mm4 {uint64 = 0xa000000000000000, v2_int32 = {0x0, 0xa0000000}, v4_int16 = {0x0, 0x0, 0x0, 0xa000}, v8_int8 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0xa0}} mm5 {uint64 = 0x0, v2_int32 = {0x0, 0x0}, v4_int16 = {0x0, 0x0, 0x0, 0x0}, v8_int8 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}} mm6 {uint64 = 0xb89d9e0000000000, v2_int32 = {0x0, 0xb89d9e00}, v4_int16 = {0x0, 0x0, 0x9e00, 0xb89d}, v8_int8 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x9e, 0x9d, 0xb8}} mm7 {uint64 = 0xb89d9e0000000000, v2_int32 = {0x0, 0xb89d9e00}, v4_int16 = {0x0, 0x0, 0x9e00, 0xb89d}, v8_int8 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x9e, 0x9d, 0xb8}} (gdb) list 50 nanosleep( &tm, NULL );*/ 51 } 52 fprintf( stderr, "\n" ); 53 } 54 } 56 int main( int argc, char **argv ) 57 { 58 int i; 59 mlt_consumer consumer = NULL; (gdb) quit olo@stacja:~/misc/soft/Graphics/KDEnlive/SVN/espinosa$
Backtrace shows that there are still failed assertions in ff_rate_estimate_qscale(). Gdb init shows that correct libavcodec libraries (SVN version) are loaded.
Also, no changes related to this problem can be seen in FFMPEG SVN repository during last 2 weeks:
ffmpeg$ svn log -v -r '{2007-06-20}'
------------------------------------------------------------------------
r9371 | gpoirier | 2007-06-19 23:34:04 +0200 (wto, 19 cze 2007) | 7 lines
Changed paths:
M /trunk/libavcodec/h264.c
Decouple bit context from h264 context in decode_ref_pic_marking()
(done in order to implement slice-level parallel decoding)
Patch by Andreas Öman % andreas olebyn nu %
Original thread:
Date: Jun 15, 2007 10:10 PM
Subject: [FFmpeg-devel] [PATCH] h264 parallelized, (was: Parallelized h264 proof-of-concept)
------------------------------------------------------------------------
$ svn diff -r '{2007-06-20}' libavcodec/ratecontrol.c
Index: libavcodec/ratecontrol.c
===================================================================
--- libavcodec/ratecontrol.c (revision 9371)
+++ libavcodec/ratecontrol.c (working copy)
@@ -184,7 +184,7 @@
//FIXME maybe move to end
if((s->flags&CODEC_FLAG_PASS2) && s->avctx->rc_strategy == FF_RC_STRATEGY_XVID) {
-#ifdef CONFIG_XVID
+#ifdef CONFIG_LIBXVID
return ff_xvid_rate_control_init(s);
#else
av_log(s->avctx, AV_LOG_ERROR, "XviD ratecontrol requires libavcodec compiled with XviD support\n");
@@ -260,7 +260,7 @@
ff_eval_free(rcc->rc_eq_eval);
av_freep(&rcc->entry);
-#ifdef CONFIG_XVID
+#ifdef CONFIG_LIBXVID
if((s->flags&CODEC_FLAG_PASS2) && s->avctx->rc_strategy == FF_RC_STRATEGY_XVID)
ff_xvid_rate_control_uninit(s);
#endif
@@ -676,7 +676,7 @@
Picture * const pic= &s->current_picture;
emms_c();
-#ifdef CONFIG_XVID
+#ifdef CONFIG_LIBXVID
if((s->flags&CODEC_FLAG_PASS2) && s->avctx->rc_strategy == FF_RC_STRATEGY_XVID)
return ff_xvid_rate_estimate_qscale(s, dry_run);
#endif
So I don't think FFMPEG devs have reacted to this problem yet.
Jean Baptiste, I'm puzzled by one strange thing:
Using this script I'm capturing the kdenlive_rederer job that's in progress:
http://kdenlive-dev-helpers.googlecode.com/svn/trunk/capture_kdenlive_renderer_testcase.sh
It generates (among others) a script that should launch kdenlive_renderer with identical arguments, with the exception of paths to the temporary files (which are saved in a permanent location by the capture script).
But when I launch the generated script, the result differs extensively in quality. A DVD-quality timeline export from KDEnlive looks OK, but when I re-run it from the captured script, all video is very blocky - like if the MPEG-2 bitrate has been set to extremely low value.
Also, I can see that kdenlive_renderer, when launched by main KDEnlive process, sends standard error to some socket and standard output to the same destination that main KDEnlive process.
But when I run renderer from my script, it outputs the produced video data on standard output and no data on standard error!
Why does kdenlive_renderer produce different results? Is the problem in environment variables? Or something else?
How do KDEnlive and kdenlive_renderer interface during export?
Here's the difference between two video files produced by kdenlive_renderer launched from KDEnlive and from generated script (shown by mplayer):
Video from KDEnlive
VIDEO: MPEG2 720x576 (aspect 2) 25.000 fps 8000.0 kbps (1000.0 kbyte/s) ... AUDIO: 48000 Hz, 2 ch, s16le, 192.0 kbit/12.50% (ratio: 24000->192000) Selected audio codec: [a52] afm: liba52 (AC3-liba52)
Video from script
VIDEO: MPEG1 720x576 (aspect 8) 25.000 fps 0.0 kbps ( 0.0 kbyte/s) ... AUDIO: 48000 Hz, 2 ch, s16le, 128.0 kbit/8.33% (ratio: 16000->192000) Selected audio codec: [mad] afm: libmad (libMAD MPEG layer 1-2-3)
And the source of the script:
#!/bin/sh export PATH="/home/olo/misc/soft/Graphics/KDEnlive/SVN/espinosa/build.2007-07-07_19_05/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11:/usr/games:/usr/NX/bin:~/bin" export LD_LIBRARY_PATH=/home/olo/misc/soft/Graphics/KDEnlive/SVN/espinosa/build.2007-07-07_19_05/lib /home/olo/misc/soft/Graphics/KDEnlive/SVN/espinosa/build.2007-07-07_19_05/bin/kdenlive_renderer /home/olo/Movies_temp/Pawlik/render_scripts/2007-03-02/2007-07-07_22_07_53.westley real_time=0 resize=hyper in=0 out=23538 -consumer avformat /home/olo/Movies_temp/Pawlik/Pawlik_2007-03-02_12dni-pierwszy_miesiac/output/Pawlik_2007-03-02_12dni-pierwszy_miesiac.vob real_time=0 stats_on=1 qscale=0 display_ratio=1.33333 format=dvd aspect=4:3 vcodec=mpeg2video acodec=ac3 video_bit_rate=6500000 video_rc_max_rate=8000000 video_rc_min_rate=0 video_rc_buffer_size=1835008 mux_packet_size=2048 mux_rate=10080000 audio_bit_rate=192000 audio_sample_rate=48000 frame_size=720x576 frame_rate=25 gop_size=15 me_range=63 ildct=1 ilme=1 > /home/olo/Movies_temp/Pawlik/render_scripts/2007-03-02/2007-07-07_22_07_53_untitled-test_run.vob
Looks like the command line arguments have been evidently ignored by kdenlive renderer (video_rc_max_rate=8000000, audio_bit_rate=192000). This would also explain why the renderer doesn't crash when run like that - it doesn't take the "qscale=0" argument into account!
Could you revert snv revision 9505? Just to be sure they didn't break it again.
There was a discussion about it in mail list, there seems to be problem ffmpeg behaving non reliably in extreme low or high bitrates when encoding mpeg4.
So try to lower the bitrate a little bit and make it variable.
But mpe4 generally seems not to be much designed for high bitrates uset mpeg2 instead or try other formats, theora? x264?
Try to set lower GOP size??
I am only working on dist-clean, in /usr/ not /local/.
Latest ffmpeg and libavcodec from yesterday.
If you have no problem, the problem may be on my side.
Other persons report problems.