Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 147903

Summary: media-video/ffmpeg-0.4.9_p20060816 mpeg 2pass curve fails to converge with -O3 -march=athlon64
Product: Gentoo Linux Reporter: Trent Apted <tapted>
Component: New packagesAssignee: Gentoo Linux bug wranglers <bug-wranglers>
Status: RESOLVED DUPLICATE    
Severity: normal    
Priority: High    
Version: 2006.1   
Hardware: AMD64   
OS: Linux   
Whiteboard:
Package list:
Runtime testing required: ---
Attachments: emerge --info

Description Trent Apted 2006-09-17 02:21:18 UTC
I get mpeg 2pass curve failed to converge when I emerge ffmpeg with -O3:

[mpeg2video @ 0x2aaaad2e55d0]removing common factors from framerate
tc_memcpy: using amd64 for memcpy
[mpeg2video @ 0x2aaaad2e55d0]Error: 2pass curve failed to converge
[export_ffmpeg.so] could not open FFMPEG codec
[transcode] warning : (encoder.c) video export module error: init failed
[transcode] critical: failed to init encoder

Actually, I had this problem with a whole bunch of previous versions of ffmpeg as well as ~amd64 flavours. For a long time, and after a whole bunch of re-emerges and dependency checking, I had decided to settle for 1-pass encoding, which works fine. I've now decided to do a global backoff of my CFLAGS to -O2, and decided to give 2pass another go; lo and behold it works!

Seems to just affect my AMD64 system, and not any of my pentium4 or pentium-m systems, which I still have at -O3.

My 2pass script is this:

nice transcode -i "$1" -y ffmpeg --export_prof dvd-pal --export_asr 3 \
    -o /dev/null -D0 -m output.ac3 -J modfps=clonetype=3 --export_fps 25 -R 1
nice transcode -i "$1" -y ffmpeg --export_prof dvd-pal --export_asr 3 \
    -o output -D0 -m output.ac3 -J modfps=clonetype=3 --export_fps 25 -R 2
nice mplex -f 8 -o "${1}.mpg" output.m2v output.ac3

But the same problem occurs with a minimum of filters, and also when using ffmpeg alone (i.e. not its plugin via transcode).


Steps to reproduce (just tested):

# CFLAGS="-march=athlon64 -O3" emerge ffmpeg
<run the script above, error results after first pass completes>


Steps to fix:
CFLAGS="-march=athlon64 -O2" emerge ffmpeg
<script now works fine, and 2pass file results>

I'll attach my emerge --info.

And for a resolution.. obviously for a package such as ffmpeg filtering out -O3 is a drastic fix, particularly as 1-pass encoding seems to be unaffected. Maybe a big flashing warning is sufficient. Or maybe ffmpeg devs have a fix. Or maybe there is something strange about my setup and I'm the only one affected..
Comment 1 Trent Apted 2006-09-17 02:25:09 UTC
Created attachment 97212 [details]
emerge --info
Comment 2 Trent Apted 2006-09-17 02:30:25 UTC
... forgot to mention (looking at emerge --info reminded me):

I had the same problem before I moved to 2006.1. That is, while I was still using x86_64-pc-linux-gnu-3.4.6 the same problem occurs. -O3 with gcc-4.1.1 has the same error but so far I've only tested the fix (using -02) with x86_64-pc-linux-gnu-4.1.1
Comment 3 Jakub Moc (RETIRED) gentoo-dev 2006-09-17 03:29:25 UTC

*** This bug has been marked as a duplicate of 146017 ***
Comment 4 Trent Apted 2006-09-17 04:30:13 UTC
Neither

http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2006-July/013055.html

nor

http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2006-August/013748.html

seem to be addressing the same issue. For these, increasing the bitrate makes the problem go away.

Even (duplicate? [sorry - I didn't search closed bugs]) Bug 146017 may be a different problem. While both are occurring on AMD64, this bug is only reported for "-O3" in CFLAGS. Dropping down to "-O2" fixes the problem, where before it occurred for ALL videos and ALL settings.

The (now obsolete) patch on Bug 146017 may actually work in the cases where bug 146017 bug is ocurring -- as mentioned here:

http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2006-August/013746.html

'failed to converge' is just an INFO in some circumstances -- it can be ignored when ffmpeg is just reporting that it is unable to fit the video in the specified number of bits.

However, I could reproduce *this* bug for all settings, all input videos, and and all bitrates, so it would appear to be an intractible convergence that will NOT go away by ignoring the message and/or increasing the bitrate.

My fix works, so I am content (hence, less likely to pursue this). However, the reporter of bug 146017 is not using -O3 so the fix I used (drop to -O2) will clearly not work for him.

May I be so bold to suggest that this bug is reopened, until upstream decide that they are actually fixing the same thing? (Or a link can be posted correlating the two).

I would have wasted a lot less time if there was an einfo in ffmpeg's ebuild stating simply that "on AMD64 instability has been reported when using -O3 with 2-pass encoding".