Summary: | media-video/mplayer v1.0_pre8 until v1.0_pre20060810 - 2pass curve failed to converge | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Thomas Kohler <g2t> |
Component: | Current packages | Assignee: | Gentoo Media-video project <media-video> |
Status: | RESOLVED UPSTREAM | ||
Severity: | normal | ||
Priority: | High | ||
Version: | 2006.0 | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
patch for testing the reason of error
a short patch with does it on my amd64 bad and good converge (using test-patch) patch for amd64 and x86 - plot a warning |
Description
Thomas Kohler
2006-08-28 12:11:44 UTC
Same with: media-video/ffmpeg-0.4.9_p20051216 media-video/mplayer-1.0_pre8-r1 update ffmpeg and mplayer and report back. the currently masked snapshot are in p.mask just because the other programs hadn't update x264 bindings... Same with: media-video/ffmpeg-0.4.9_p20051216 media-video/mplayer-1.0_pre20060810 (masked by package.mask and ~amd64 keyword) In reply to Comment #2: Do you mean the mplayer version above? In my opinion the problem is located in ffmpeg. Therefore I will test now the other versions of ffmpeg wich I can find in the actual portage tree. Same with: media-video/ffmpeg-0.4.9_p20050226-r3 media-video/mplayer-1.0_pre20060810 (masked by package.mask and ~amd64 keyword) Same with: media-video/ffmpeg-0.4.9_p20060302 media-video/mplayer-1.0_pre20060810 (masked by package.mask and ~amd64 keyword) Now I have tested the patch from www (see above). With that the function abs() should change to a better one: fabs(). I had tested some modifications but nothing was successfully. Allways the same error: "Error: 2pass curve failed to converge" Last I have modified the patched line to : "if (1>10) {...}" but the error persist. Summary: The patch don't modify the right line. Created attachment 95508 [details]
patch for testing the reason of error
(In reply to comment #6) > Summary: The patch don't modify the right line. Yes and that's because mplayer (I'm used for testing) don't use the ffmpeg-librarys as link but his own included ffmpeg sources during compile! Ok, now I have made a look into the file "ratecontrol.c" of mplayer and find out that the abs-> fabs patch is allways there. Now I had make my own patch file (see attachement). After applying this patch you will see that the error-string is absolutly correct: curve don't converge In my case "expected_bits/all_available_bits" is "0.193" but it should be near "1". I don't know why the curve should converge. Also I don't know about the background of the complete problem. Even though I had removed the line with "return -1". Therfore the second pass now will finished successfully. Created attachment 95635 [details, diff]
a short patch with does it on my amd64
try it out
Changed topic to mplayer it has its own ffmpeg-version and is not related to ffmpeg-ebuild. the patch is for mplayer version: media-video/mplayer-1.0_pre20060810 (In reply to comment #11) > the patch is for mplayer version: > > media-video/mplayer-1.0_pre20060810 Thank you for your patch, but this solves only the reaction of the problem, not the problem itself. Of course, the process dont interrupt now (see also my shorter patch ;o}). But in my opinion the result can't be a valid videofile (I know it will be played correctly with mplayer). Functions are defined as: * int abs ( int n ); (n -> integer) [http://www.cplusplus.com/ref/cmath/abs.html] * double fabs ( double x ); (x -> double) [http://www.cplusplus.com/ref/cmath/fabs.html] I have attached a file with outputs of a incorrect converge and a correct converge (generated with my testing-patch). Created attachment 95668 [details]
bad and good converge (using test-patch)
(In reply to comment #10) The contens of the directory "libavcodec" looks nearly same in mplayer and ffmpeg. Therefore I'm suggesting open a new bug for ffmpeg after testing the same with ffmpeg and the same file. I can do it, but I,m not trained with ffmpeg. Do someone send me the commandline wich equal with mencoder 2-pass encoding? (In reply to comment #9) The error exist on "amd64" and the same on "x86", I have tested. Created attachment 95669 [details, diff]
patch for amd64 and x86 - plot a warning
Not smaller :O[ , but better ;o}
Inform the user with two possibilities, but don't interrupt.
At me tested with mplayer-1.0_pre8. Should also work with versions above.
(In reply to comment #14) > (In reply to comment #10) Today I'm testing the ffmpeg-0.4.9_p20051216. I was first exposed there is no bug. I looked into the sources to understand what's better in ffmpeg-ratecontrol. It's not better! There is the abs-bug in it. After that I make the patch doing the fabs and also the warning like mpeg-patch above. Then I test with that patched version the mpeg4-code and get the message. Now I'm sure the same bug is inside the ffmpeg-code. ffmpeg -t 4 -pass 1 -i Infile.avi -vcodec mpeg4 -s 352x144 OutFilep1.avi ffmpeg -t 4 -pass 2 -i Infile.avi -vcodec mpeg4 -s 352x144 OutFilep2.avi The problem don't exist anymore if I remove the -s Option. In my opinion in that case the higher bitrate correlate better to framesize (704x288). *** Bug 146017 has been marked as a duplicate of this bug. *** Please move this discussion to upstream, something similar will added to the rc1. |