Export/rendering failure [Solved]
Registered Member 
|
Seems to be fixed with the latest FFmpeg Revision: 9505. |
|
Registered Member
|
Not for me, still crashes like before, FFMPEG revision 9509:
And gdb debugging:
Backtrace shows that there are still failed assertions in ff_rate_estimate_qscale(). Gdb init shows that correct libavcodec libraries (SVN version) are loaded. |
|
Registered Member
|
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}'
So I don't think FFMPEG devs have reacted to this problem yet. |
|
Registered Member
|
Jean Baptiste, I'm puzzled by one strange thing: Using this script I'm capturing the kdenlive_rederer job that's in progress: 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? |
|
Registered Member
|
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 from script
And the source of the script:
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! |
|
Registered Member
|
Could you revert snv revision 9505? Just to be sure they didn't break it again. |
|
Registered Member
|
Thanks, I'll try 9505. But note that I _am_ using MPEG2. Actually I didn't even test MPEG4 export. |
|
Registered Member
|
Nope, FFMPEG rev 9505 crashes with assert as usual in the same place. |
|
Registered Member
|
olo: You have i.e. a ':' (colon) should separate 'avformat' from the path name, not a space. |
|
Registered Member
|
You were right! I've checked in a new version of capture script, could you test it how it works? I've captured a DVD export successfully and it runs fine. Here's where it's located: http://kdenlive-dev-helpers.googlecode.com/svn/trunk/capture_kdenlive_renderer_testcase.sh And I've been able to at last see what error does kdenlive_renderer crash with. It's:
|
|
Registered Member
|
The thread about this has started on FFMPEG-devel mailing list: http://lists.mplayerhq.hu/pipermail/ffm ... 32779.html |
|
Registered Member
|
Hi guys...i'm having this problem: I can't render anything... With ffmpeg...with mencoder...with k9copy...and now, with kdenlive... Sometime ago, i rip dvd9 to dvd5 well in k9copy...but in this days, the k9copy and the kdenlive are hanging/freezing my system...and ffmpeg and mencoder give a segmentation failure in the videos wiling rendering... What's it could be?? I think it could be a problem of others here too... Some clue? |
|
Registered Member
|
To help ffmpeg debug, make a custom render profile in kdenlive with a .jpg extension and with no avformat parameters. Then, use a filename like kdenlive-%06d.jpg. Render. You can then use the images in ffmpeg ala: |
|
Registered Member
|
I think I (almost) know what is going on. oldqfactor * abs(i_qfactor) + i_qoffset ffpmeg sets the default for these two values to
mlt, in comsumer_avformat.c sets
They both have a -0.8, but for different values - odd.. Anyway, if 'oldqfactor' is small, and the above formula is applied, then adding While I really don't know how these numbers are used, or what you achieve by setting them, I think the best solution to our problem is to get rid of it. either change the MLT source, I seems sensible to choose the same defaults that ffmpeg chooses. It really seems a strange co-incidence that both use -0.8, but at different places. |
|
Registered Member
|
Just for the record, this problem has been fixing in the MLT SVN. So if you build from SVN, |
Bookmarks
Who is online
Registered users: bancha, Bing [Bot], daret, Evergrowing, Google [Bot], lockheed, sandyvee, Sogou [Bot]
