[FFmpeg-devel] [PATCH 0/6] sse2/avx functions for 8-bit simple idct

James Darnley jdarnley at obe.tv
Tue Jun 13 16:07:32 EEST 2017


On 2017-06-13 00:18, James Darnley wrote:
> On 2017-06-12 18:57, Michael Niedermayer wrote:
>> ./ffplay ~/videos/matrixbench_mpeg2.mpg
>> looks pretty bad
> 
> If that would happen to be the FATE sample
> mpeg2/matrixbench_mpeg2.lq1.mpg then I see that too.
> 
> As I said on IRC I was able to partly remedy it by moving patch 6 up.

I think this problem occurs because although I assign a function for the
plain IDCT and set the perm_type for that, the mpeg decoder uses the
add/put functions which the C and MMX do not want to be transposed.

Removing the perm_type assignment fixes that and the new function is not
called.

I have no idea how patch 6 managed to change anything or whether I
failed to test properly.

> Ultimately I have no idea what is going on here.  I've tested decoding
> the sample mentioned above before my inline to external conversion of
> the MMX.  I've done that immediately after that commit.  I've done that
> on the current master.  I get the same result for all of those.
> 
> Going to my patches.  I can get the same result with -cpuflags none.
> Surely -cpuflags mmx+mmxext would then be the same as above.

I'm still stuck on that part though.  I have no idea what's going on.
Why is permutation an option?!  Why is it not binary?  Why can some
functions be NULL and not others?

I tried setting add/put to NULL (like the high bit depth does for add)
which makes ffmpeg segfault because it tries to call NULL.

<rant swearing="off">

Why does simplemmx produce the same output for some files but not
others?  Why can't I let simplemmx be used for simple and have it pass
fate?  Why is it different?  Why is it not the same as C?  Why does the
dct test program show it is the same?  Is that program good for anything?

</rant>



More information about the ffmpeg-devel mailing list