Long-standing encoding bug: ff_rate_estimate_qscale: Assertion `pict_type == rce->new_pict_type' failed
Hi everybody! I have been using mplayer and mencoder for a long time, and still am impressed by it's speed / efficiency and quality (both when decoding and encoding). I even developed a small python GUI for mencoder that I plan(ned) to release some day.. ;-) However, I have been having problems for several months now with mencoder stopping during the second (lavc-divx) pass with this assertion failing: mencoder: ratecontrol.c:635: ff_rate_estimate_qscale: Assertion `pict_type == rce->new_pict_type' failed. I found some old messages concerning this assertion in the WWW, but nothing really related. The bug appeared _after_ 1.0pre4 IIRC, and remains until today's CVS. It was not trivial to prepare a testcase, but I finally found the time to strip a file and the failing commands down to this: This triggers the assertion on 1.0pre6-3.3.5, 1.0pre6-3.3.5-20050130 (Gentoo ebuild) and dev-CVS-050509-09:37-3.3.5-20050130. As mentioned, the bug was hard to nail down, because often, it would go away when I tried to encode only small parts of the original file (even when choosing the part where it failed before!), and the testcase that I uploaded now (ff_rate_estimate_qscale_assertion.* in mplayerhq.hu/MPlayer/incoming/) is heavily stripped down, but the assertion disappears when removing either the cropping, the deinterlacing, or the B frame parameters! ;-} I sincerely hope the testcase is useful and someone finds the bug! ;-) Last-minute update: Now that I have the testcase, I found out the day CVS broke (by binary search), it's the 15th of October 2004, with a commit to libavcodec/mpegfile.c concerning B frame handling, see for yourself: cvs diff -D20041014 -D20041015 mpegvideo.c In other words: updating everything to CVS from 20041015 still shows the error, but reversing the version of mpegvideo.c to 1.440 (which is that from 20041014), the encoding works again. However, this does of course not mean that I know a fix.. ;-/ Nice greetings, Ciao, / / /--/ / / ANS
On Tuesday 10 May 2005 13:20, Hans Meine wrote:
However, I have been having problems for several months now with mencoder stopping during the second (lavc-divx) pass with this assertion failing: mencoder: ratecontrol.c:635: ff_rate_estimate_qscale: Assertion `pict_type == rce->new_pict_type' failed.
I just noticed I forgot to add the commands to this mail. It's in the uploaded .txt file, and a complete .log is also on ftp://mplayerhq.hu/MPlayer/incoming/ (under the mentioned prefix "ff_rate_estimate_qscale_assertion.*"), however for people like me not having access to that stuff, this is the combination of options that trigger the error on many of my files (I usually add v4mv and vhq, too): INPUT='ff_rate_estimate_qscale_assertion.avi' VIDEO_PROCESSING='-vf crop=688:400:14:84,pp=lb' VIDEO_ENCODING='-ovc lavc -lavcopts vcodec=mpeg4:vmax_b_frames=2:vb_strategy=1' TARGET='result.avi' mencoder -v $VIDEO_PROCESSING $VIDEO_ENCODING:vpass=1 -oac copy -o /dev/null "$INPUT" && \ mencoder -v $VIDEO_PROCESSING $VIDEO_ENCODING:vpass=2 -oac copy -o "$TARGET" "$INPUT"
[...] cd libavcodec && cvs diff -D20041014 -D20041015 mpegvideo.c ..and this change touched the "pict_type" referenced in the assertion.
Ciao, / / /--/ / / ANS
On Tue, 10 May 2005 13:20:22 +0200 Hans Meine <hans_meine@gmx.net> wrote:
now (ff_rate_estimate_qscale_assertion.* in mplayerhq.hu/MPlayer/incoming/) is heavily stripped down, but the assertion disappears when removing either the cropping, the deinterlacing, or the B frame parameters! ;-}
I've seen the same thing when encoding multiple-passes with B-frames enabled. Funny that you have a hard time reproducing it, when I'm having the problem with every video I try, even with no cropping, scaling, deinterlacing, etc. Bugs in mencoder seem to search me out...
I found out the day CVS broke (by binary search), it's the 15th of October 2004, with a commit to libavcodec/mpegfile.c concerning B frame handling
Looks like michael is the culprit. Attached is a patch against current CVS based on the changes you pointed-out. It just reverts whatever it was that Michael was doing there... It applies and compiles, and I've successfully tested it on one video.
On Tue, 10 May 2005, RC wrote:
On Tue, 10 May 2005 13:20:22 Hans Meine wrote:
now (ff_rate_estimate_qscale_assertion.* in mplayerhq.hu/MPlayer/incoming/) is heavily stripped down, but the assertion disappears when removing either the cropping, the deinterlacing, or the B frame parameters! ;-}
I've seen the same thing when encoding multiple-passes with B-frames enabled. Funny that you have a hard time reproducing it, when I'm having the problem with every video I try, even with no cropping, scaling, deinterlacing, etc. Bugs in mencoder seem to search me out...
While I never tracked it down, I'm suspicious of vb_strategy. It modifies frametypes, and I think it tries to run again in the 2nd pass. --Loren Merritt
Hi RC(?)! On Wednesday 11 May 2005 00:18, RC wrote:
Funny that you have a hard time reproducing it, when I'm having the problem with every video I try, even with no cropping, scaling, deinterlacing, etc. Yeah, I am also having the problem on nearly all videos, but it was not easy to find a *short* (read: <100Mb) source file section that triggered it. (And, I had to find some time to really sit down and dig into it, which I would not have done if it didn't bug me a lot..)
Attached is a patch against current CVS based on the changes you pointed-out. It just reverts whatever it was that Michael was doing there... It applies and compiles, and I've successfully tested it on one video. I also thought about trying that, but one would normally think that this change was intentional *somehow*, so that'd probably be a short-term solution, no?
Loren's patch seemed nicer to me, but unfortunately, it does not even fix the test-case, whereas the reversing does. :-( Thanks a lot for your comments, looking forward to more feedback, Greez, Hans
On Tue, 10 May 2005 15:18:37 -0700 RC <rcooley@spamcop.net> wrote:
It applies and compiles, and I've successfully tested it on one video.
*Sigh* I have to take that back. The video that was consistently crashing on me when using b-frames, is now mysteriously working with any version of mencoder I use. This patch might not have anything to do with it. It may take a while for me to find another test-case.
Hi again! On Thursday 12 May 2005 01:39, RC wrote:
It applies and compiles, and I've successfully tested it on one video.
*Sigh* I have to take that back. The video that was consistently crashing on me when using b-frames, is now mysteriously working with any version of mencoder I use. This patch might not have anything to do with it. It may take a while for me to find another test-case.
Argh. I was about to tell you that I successfully encoded several videos with your patch in the meantime, but I just realized that they don't play back on an mplayer-1.0pre6-3.3.5 on another computer. :-( The screen stays black, so the resulting video must have unwanted properties. I compared the output of mplayer -v -v on some output files, but the only changes are changed offsets / hex values, no recognizable message saying where the files differ. Will have a closer look later, but anyhow - the real fix (tm) is still missing. :-( Greetings, Hans
Hi again! On Monday 16 May 2005 00:02, Hans Meine wrote:
Argh. I was about to tell you that I successfully encoded several videos with your patch in the meantime, but I just realized that they don't play back on an mplayer-1.0pre6-3.3.5 on another computer. :-(
Sorry, that was stupid (too much red wine maybe..); it was just the fourcc which unexpectedly changed to FMP4 in current CVS. Changing it back to DIVX resulted in nice videos. ;-) I encoded several files (.vob from DVDs and MPEG2 from my PVR250 analog encoding card) in the meantime with the mpegvideo.c change from 20041015 reversed (cf. RC's patch), and all of them seem to be flawless results so far. In other words, the patch could IMHO be applied to CVS, if it wasn't already (can't check, being at work). Ciao, / / /--/ / / ANS
On Tue, 17 May 2005 14:48:45 +0200 Hans Meine <hans_meine@gmx.net> wrote:
In other words, the patch could IMHO be applied to CVS, if it wasn't already (can't check, being at work).
I'm not a dev, so I certainly can't apply it (actually, you'd probably want to revert the original commit, not apply a reverse patch). I sent a message to mplayer-dev-eng about the bug (hoping Michael would get around to fixing it), but it's been ignored. Rich? Nico?
RC wrote:
On Tue, 17 May 2005 14:48:45 +0200 Hans Meine <hans_meine@gmx.net> wrote:
In other words, the patch could IMHO be applied to CVS, if it wasn't already (can't check, being at work).
I'm not a dev, so I certainly can't apply it (actually, you'd probably want to revert the original commit, not apply a reverse patch). I sent a message to mplayer-dev-eng about the bug (hoping Michael would get around to fixing it), but it's been ignored.
Rich? Nico?
encoders aren't really my resort, sorry :(
On Tue, May 17, 2005 at 03:43:34PM -0700, RC wrote:
On Tue, 17 May 2005 14:48:45 +0200 Hans Meine <hans_meine@gmx.net> wrote:
In other words, the patch could IMHO be applied to CVS, if it wasn't already (can't check, being at work).
I'm not a dev, so I certainly can't apply it (actually, you'd probably want to revert the original commit, not apply a reverse patch). I sent a message to mplayer-dev-eng about the bug (hoping Michael would get around to fixing it), but it's been ignored.
Rich? Nico?
The bug was already fixed my Michael in ffmpeg CVS. Now lavc should give an error and refuse to encode if B frame strategy is nonzero during the second pass. Rich
The bug was already fixed my Michael in ffmpeg CVS. Now lavc should give an error and refuse to encode if B frame strategy is nonzero during the second pass. Oh, I always thought both passes should always use *exactly* the same cmdline
Hi everybody! On Wednesday 18 May 2005 08:44, Rich Felker wrote: options. Does that mean it was my error to give vb_strategy=1 for the second pass, too? That'd be an evil trap. ;-) I hope mplayer overwrites that automatically in the future. (Again, I am at work and can't check that right now.) Thanks for the update, and nice greetings! Hans
On Wed, May 18, 2005 at 12:28:51PM +0200, Hans Meine wrote:
Hi everybody!
The bug was already fixed my Michael in ffmpeg CVS. Now lavc should give an error and refuse to encode if B frame strategy is nonzero during the second pass. Oh, I always thought both passes should always use *exactly* the same cmdline
On Wednesday 18 May 2005 08:44, Rich Felker wrote: options. Does that mean it was my error to give vb_strategy=1 for the second pass, too? That'd be an evil trap. ;-) I hope mplayer overwrites that automatically in the future. (Again, I am at work and can't check that right now.)
Well, it's not your error snce it was never documented. Hopefully we can improve this better by automatically disabling it during the second pass or something, but at the very least it needs to be documented as a pass1-only option. Rich
On Wed, May 18, 2005 at 10:40:56PM -0400, Rich Felker wrote:
On Wed, May 18, 2005 at 12:28:51PM +0200, Hans Meine wrote:
Oh, I always thought both passes should always use *exactly* the same cmdline options. Does that mean it was my error to give vb_strategy=1 for the second pass, too? That'd be an evil trap. ;-) I hope mplayer overwrites that automatically in the future. (Again, I am at work and can't check that right now.)
Well, it's not your error snce it was never documented. Hopefully we can improve this better by automatically disabling it during the second pass or something, but at the very least it needs to be documented as a pass1-only option.
This is the current text: vb_strategy=<0-1> strategy to choose between I/P/B-frames (pass 1): 0 Always use the maximum number of B-frames (default). 1 Avoid B-frames in high motion scenes. Am I correct in understanding that this option is for pass 1 _only_ and that MEncoder will reject it in subsequent passes? Diego
On Thu, May 19, 2005 at 09:17:08AM +0200, Diego Biurrun wrote:
On Wed, May 18, 2005 at 10:40:56PM -0400, Rich Felker wrote:
Well, it's not your error snce it was never documented. Hopefully we can improve this better by automatically disabling it during the second pass or something, but at the very least it needs to be documented as a pass1-only option.
This is the current text:
vb_strategy=<0-1> strategy to choose between I/P/B-frames (pass 1): 0 Always use the maximum number of B-frames (default). 1 Avoid B-frames in high motion scenes.
Am I correct in understanding that this option is for pass 1 _only_ and that MEncoder will reject it in subsequent passes?
Ping. Diego
On Sun, May 22, 2005 at 03:50:34PM +0200, Diego Biurrun wrote:
On Thu, May 19, 2005 at 09:17:08AM +0200, Diego Biurrun wrote:
On Wed, May 18, 2005 at 10:40:56PM -0400, Rich Felker wrote:
Well, it's not your error snce it was never documented. Hopefully we can improve this better by automatically disabling it during the second pass or something, but at the very least it needs to be documented as a pass1-only option.
This is the current text:
vb_strategy=<0-1> strategy to choose between I/P/B-frames (pass 1): 0 Always use the maximum number of B-frames (default). 1 Avoid B-frames in high motion scenes.
Am I correct in understanding that this option is for pass 1 _only_ and that MEncoder will reject it in subsequent passes?
Ping.
I believe so. And by reject, I mean fatal error from lavc. Rich
On Wed, 18 May 2005 02:44:33 -0400 Rich Felker <dalias@aerifal.cx> wrote:
The bug was already fixed my Michael in ffmpeg CVS. Now lavc should give an error and refuse to encode if B frame strategy is nonzero during the second pass.
Thanks Rich.
On Wednesday 18 May 2005 01:43, RC wrote:
I'm not a dev, so I certainly can't apply it (actually, you'd probably want to revert the original commit, not apply a reverse patch).
It's not possible to revert using CVS, especially not if there have been commits after the commit you want to revert, so reverse patch is probably fine...
participants (7)
-
Diego Biurrun -
Hans Meine -
Jan Knutar -
Loren Merritt -
Nico Sabbi -
RC -
Rich Felker