[FFmpeg-devel] lurking bugs in the mmx-related assembler code (?)

u-h8zb at aetey.se u-h8zb at aetey.se
Sun Oct 2 10:27:24 EEST 2016

Hello Carl Eugen,

On Sun, Oct 02, 2016 at 03:05:13AM +0200, Carl Eugen Hoyos wrote:
> 2016-10-01 19:48 GMT+02:00  <u-h8zb at aetey.se>:
> > I do not expect the ffmpeg developers to try to reproduce this.
> (Would you mind explaining this sentence to me? I
> do not understand it.)

I do not expect that the ffmpeg developers take the trouble
to install an extra build environment with a different libc,
just to confirm a fact which is pretty evident when looking
at the code.

> > I expect somebody to look at the code (beginning with the
> > MMX assembler in the vp3 decoder), which is a lower
> > threshold than building a new libc.
> Either you know a lot of things that nobody on this list
> knows or you have very little clue about FFmpeg
> development.

It is safe to assume that the knowledge varies a lot :)
and indeed it has been quite some time since i added code
to ffmpeg.

But discussing personal qualities is not the topic of this thread.

> The expected route if trac is down (but also if
> you don't want to use it) is to send an email to
> the user mailing list.

This discussion is about ffmpeg internal details, not about its usage,
so why go to the wrong forum?

> >  ffmpeg -i test.640x480.19seconds.theora.ogg
> > -c:v libtheora -y test.out.ogg
> Missing console output and backtrace, please do
> not use external libraries unless they are necessary
> to reproduce the issue.

I am aware of the general rules and why/when they make sense.

Is there anybody on this lilst who builds ffmpeg against musl?
If there were, the problem would be noticed and hopefully fixed.
If there is none, nobody here will be able to make sense of my console output.

I am contributing the result of the analysis:

 the assumptions in the mmx-related assembler code in ffmpeg are
 not fulfilled in a real world scenario and they do not conform
 to what standards say

You do not have to reproduce my builds to confirm or deny this. Some
replies have apparently confirmed the situation.

The rest is up to the maintainers of that code.


More information about the ffmpeg-devel mailing list