Hello, it seems we have a file wmv8_x8intra.wmv in fate-suite but no test runs it? The issue with that is that the MPlayer regression tests use it and the result changed. Since FFmpeg doesn't seem to test it I now have no idea what to do about that (result looks fine as far as I can tell, but that does not have to mean much). Any suggestions? Reimar
On Thu, Jan 05, 2012 at 05:02:21PM +0100, Reimar Döffinger wrote:
Hello, it seems we have a file wmv8_x8intra.wmv in fate-suite but no test runs it? The issue with that is that the MPlayer regression tests use it and the result changed. Since FFmpeg doesn't seem to test it I now have no idea what to do about that (result looks fine as far as I can tell, but that does not have to mean much). Any suggestions?
what commit caused the change ? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope
On Fri, Jan 06, 2012 at 03:06:53AM +0100, Michael Niedermayer wrote:
On Thu, Jan 05, 2012 at 05:02:21PM +0100, Reimar Döffinger wrote:
Hello, it seems we have a file wmv8_x8intra.wmv in fate-suite but no test runs it? The issue with that is that the MPlayer regression tests use it and the result changed. Since FFmpeg doesn't seem to test it I now have no idea what to do about that (result looks fine as far as I can tell, but that does not have to mean much). Any suggestions?
what commit caused the change ?
I don't know. And I also forgot to ask the most important question: why is that sample file not used during "make fate"??
On Sun, Jan 08, 2012 at 12:33:16PM +0100, Reimar Döffinger wrote:
On Fri, Jan 06, 2012 at 03:06:53AM +0100, Michael Niedermayer wrote:
On Thu, Jan 05, 2012 at 05:02:21PM +0100, Reimar Döffinger wrote:
Hello, it seems we have a file wmv8_x8intra.wmv in fate-suite but no test runs it? The issue with that is that the MPlayer regression tests use it and the result changed. Since FFmpeg doesn't seem to test it I now have no idea what to do about that (result looks fine as far as I can tell, but that does not have to mean much). Any suggestions?
what commit caused the change ?
I don't know. And I also forgot to ask the most important question: why is that sample file not used during "make fate"??
Hm, it looks like it gives two sets of results: one for x86_64 and one for everything else. That stays like that even with -flags +bitexact and -idct simple. Any ideas?
On Sun, Jan 08, 2012 at 07:15:10PM +0100, Reimar Döffinger wrote:
On Sun, Jan 08, 2012 at 12:33:16PM +0100, Reimar Döffinger wrote:
On Fri, Jan 06, 2012 at 03:06:53AM +0100, Michael Niedermayer wrote:
On Thu, Jan 05, 2012 at 05:02:21PM +0100, Reimar Döffinger wrote:
Hello, it seems we have a file wmv8_x8intra.wmv in fate-suite but no test runs it? The issue with that is that the MPlayer regression tests use it and the result changed. Since FFmpeg doesn't seem to test it I now have no idea what to do about that (result looks fine as far as I can tell, but that does not have to mean much). Any suggestions?
what commit caused the change ?
I don't know. And I also forgot to ask the most important question: why is that sample file not used during "make fate"??
Hm, it looks like it gives two sets of results: one for x86_64 and one for everything else.
i get the same values on x86_32 and 64 and different ones between different compiler versions on openbsd and iam seeing the same on the ppc machines
That stays like that even with -flags +bitexact and -idct simple. Any ideas?
-idct simple is wrong it should be the wmv2 idct Anyway, IMHO until this is debuged & fixed the test should be disabled, it doesnt serve any purpose when it doesnt work [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No snowflake in an avalanche ever feels responsible. -- Voltaire
On Mon, Jan 09, 2012 at 04:11:53AM +0100, Michael Niedermayer wrote:
On Sun, Jan 08, 2012 at 07:15:10PM +0100, Reimar Döffinger wrote:
On Sun, Jan 08, 2012 at 12:33:16PM +0100, Reimar Döffinger wrote:
On Fri, Jan 06, 2012 at 03:06:53AM +0100, Michael Niedermayer wrote:
On Thu, Jan 05, 2012 at 05:02:21PM +0100, Reimar Döffinger wrote:
Hello, it seems we have a file wmv8_x8intra.wmv in fate-suite but no test runs it? The issue with that is that the MPlayer regression tests use it and the result changed. Since FFmpeg doesn't seem to test it I now have no idea what to do about that (result looks fine as far as I can tell, but that does not have to mean much). Any suggestions?
what commit caused the change ?
I don't know. And I also forgot to ask the most important question: why is that sample file not used during "make fate"??
Hm, it looks like it gives two sets of results: one for x86_64 and one for everything else.
i get the same values on x86_32 and 64 and different ones between different compiler versions on openbsd and iam seeing the same on the ppc machines
Hm, I don't see any all that clear pattern I have to admit.
That stays like that even with -flags +bitexact and -idct simple. Any ideas?
-idct simple is wrong it should be the wmv2 idct
Shouldn't really matter when it comes to eliminating differences in the result between machines.
Anyway, IMHO until this is debuged & fixed the test should be disabled, it doesnt serve any purpose when it doesnt work
Well, it would serve as a reminder that there is something very strange going on in the wmv8 decoder. But I admit that's not much value.
On Fri, Jan 06, 2012 at 03:06:53AM +0100, Michael Niedermayer wrote:
On Thu, Jan 05, 2012 at 05:02:21PM +0100, Reimar Döffinger wrote:
Hello, it seems we have a file wmv8_x8intra.wmv in fate-suite but no test runs it? The issue with that is that the MPlayer regression tests use it and the result changed. Since FFmpeg doesn't seem to test it I now have no idea what to do about that (result looks fine as far as I can tell, but that does not have to mean much). Any suggestions?
what commit caused the change ?
This was caused by this commit: commit 8400b126acb153329c418433c377d96afd1d1e02 Author: Mans Rullgard <mans@mansr.com> Date: Sun Dec 18 20:41:42 2011 +0000 avcodec: deprecate AVFrame.age This was intended as an optimisation for skipped blocks in MPEG2 P-frames and never used elsewhere. Removing this "optimisation" speeds up MPEG2 decoding by 1-2% (ARM Cortex-A9). Signed-off-by: Mans Rullgard <mans@mansr.com> I'd say it obviously must be buggy, because according to the commit message it should not be possible for it to change any results. It contains far too many non-trivial changes for me to guess what exactly is wrong, so if someone could review it that would be welcome.
On Sun, Apr 08, 2012 at 07:05:23PM +0200, Reimar Döffinger wrote:
On Fri, Jan 06, 2012 at 03:06:53AM +0100, Michael Niedermayer wrote:
On Thu, Jan 05, 2012 at 05:02:21PM +0100, Reimar Döffinger wrote:
Hello, it seems we have a file wmv8_x8intra.wmv in fate-suite but no test runs it? The issue with that is that the MPlayer regression tests use it and the result changed. Since FFmpeg doesn't seem to test it I now have no idea what to do about that (result looks fine as far as I can tell, but that does not have to mean much). Any suggestions?
what commit caused the change ?
This was caused by this commit:
commit 8400b126acb153329c418433c377d96afd1d1e02 Author: Mans Rullgard <mans@mansr.com> Date: Sun Dec 18 20:41:42 2011 +0000
avcodec: deprecate AVFrame.age
This was intended as an optimisation for skipped blocks in MPEG2 P-frames and never used elsewhere. Removing this "optimisation" speeds up MPEG2 decoding by 1-2% (ARM Cortex-A9).
Signed-off-by: Mans Rullgard <mans@mansr.com>
I'd say it obviously must be buggy, because according to the commit message it should not be possible for it to change any results. It contains far too many non-trivial changes for me to guess what exactly is wrong, so if someone could review it that would be welcome.
Not the cause, but it seems at least below code no makes that much sense after that commit: mpegvideo.c:1511 if (s->avctx->debug & FF_DEBUG_SKIP) { int count = s->mbskip_table[x + y * s->mb_stride]; if (count > 9) count = 9; av_log(s->avctx, AV_LOG_DEBUG, "%1d", count); } mbskip_table can only be 0 or 1 now, so calling it count and clamping to 9 is at least pointless.
participants (2)
-
Michael Niedermayer -
Reimar Döffinger