Hello,
Would someone familiar with the mmx assembler parts of ffmpeg
look over and check that the fp-state is restored as needed?
This is crucial with musl libc which uses floating point in its
malloc() implementation.
My troubleshooting strongly suggests that it is the mmx code which is
the cul
On Sat, Oct 01, 2016 at 05:44:13PM +0200, wm4 wrote:
> AFAIK most MMX code in FFmpeg does not run emms (i.e. keeps the FPU
> state trashed) until returning to the API user.
This means when malloc()/free()/... happens to be called internally,
it corrupts the malloc structures, in a non-straightforw
Hello Moritz,
On Sat, Oct 01, 2016 at 06:13:46PM +0200, Moritz Barsnick wrote:
> On Sat, Oct 01, 2016 at 17:37:50 +0200, u-h...@aetey.se wrote:
> > My troubleshooting
> [...]
> > behaves erratically on certain combinations
> [...]
> > Most often
>
> You are a busy troubleshooter, but you fail to
Hello,
It looks like some general information is due:
Musl libc is a high quality standard C library for Linux
with emphasis on "quality" and "standard"
http://www.musl-libc.org/
On Sat, Oct 01, 2016 at 12:31:05PM -0400, Ronald S. Bultje wrote:
> > This means when malloc()/free()/... happens to
Hello Ronald,
On Sat, Oct 01, 2016 at 03:11:38PM -0400, Ronald S. Bultje wrote:
> I'm not sure we want to go down the rabbit hole of allowing any code to be
> executed inside frame en/decoding routines. Historically, IIRC, we have
> disallowed float in user callbacks like request_frame also.
>
>
Hello Henrik,
On Sun, Oct 02, 2016 at 01:18:29AM +0200, Henrik Gramner wrote:
> Ensuring that emms is issued before every single libc function call is
> likely problematic.
>
> What if we simply document the requirement that C standard library
> functions are assumed to not modify the x87 FPU sta
On Sat, Oct 01, 2016 at 06:25:29PM -0400, Ronald S. Bultje wrote:
> > We are not talking about what you and me "would like inside a standard
> > library" but whether we can rely on the specified interfaces. The
> > malloc() interface was apparently misunderstood as a promise to never
> > do float.
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 :
> > 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 d
Thanks Michael,
On Sun, Oct 02, 2016 at 02:25:30AM +0200, Michael Niedermayer wrote:
> beyond malloc() what else is there ?
>
> string functions ?
> these are in fact not unlikely to use SIMD of some sort
> same for memcpy/move()
>
> also there are callbacks like av_log() we should document any
On Sun, Oct 02, 2016 at 02:25:30AM +0200, Michael Niedermayer wrote:
> If all else fails we could add a emms call behind #if in
> av_malloc() and detect affected libcs but thats IMHO a ugly hack
> but better than declaring "non support"
Unfortunately I see an additional reason for avoiding such ki
Hello Carl Eugen,
On Sun, Oct 02, 2016 at 04:01:21PM +0200, Carl Eugen Hoyos wrote:
> > I do not expect that the ffmpeg developers take the trouble
> > to install an extra build environment with a different libc,
>
> (If I could just understand this sentence: Is it meant as
> an insult? How do yo
On Sun, Oct 02, 2016 at 10:59:31PM -0400, compn wrote:
> vp3 is a decoder written 10+ years ago by a dev who is no longer
> active in ffmpeg.
>
> we have many decoders and encoders (and other code) in ffmpeg that have
> not been audited (to my knowledge).
>
> i know this isnt an excuse for not lo
12 matches
Mail list logo
