[FFmpeg-devel] [PATCH]doc/platform: Mention musl where x86_32 is not supported

[Ronald S. Bultje]

Hi,

On Mon, Oct 3, 2016 at 8:46 AM, Carl Eugen Hoyos <ceffmpeg at gmail.com> wrote:

> 2016-10-03 13:57 GMT+02:00 Hendrik Leppkes <h.leppkes at gmail.com>:
>
> > The underlying problem is that mmx code is mixed with allocations,
>
> Definitely.
>
> > which seems like an unusual case to begin with
>
> I am not sure if I understand this but one instance is calling radix_sort()
> in the dnxhd encoder.
>
> Below is what is needed to run the dnxhd fate tests here (the hr hq test
> crashes), the second hunk is needed to fix thread joining and avoid an
> endless loop. There are also issues with h26x.
>
> You may be interested in this post that contains a link to a work-around
> in musl: http://www.openwall.com/lists/musl/2016/09/14/8
>
> No more comments from me, Carl Eugen
>
> diff --git a/libavcodec/dnxhdenc.c b/libavcodec/dnxhdenc.c
> index 88edd6b..5b4a36a 100644
> --- a/libavcodec/dnxhdenc.c
> +++ b/libavcodec/dnxhdenc.c
> @@ -1117,6 +1117,7 @@ static int dnxhd_encode_fast(AVCodecContext
> *avctx, DNXHDEncContext *ctx)
>          if (RC_VARIANCE)
>              avctx->execute2(avctx, dnxhd_mb_var_thread,
>                              NULL, NULL, ctx->m.mb_height);
> +        emms_c();
>          radix_sort(ctx->mb_cmp, ctx->m.mb_num);
>          for (x = 0; x < ctx->m.mb_num && max_bits > ctx->frame_bits; x++)
> {
>              int mb = ctx->mb_cmp[x].mb;
> @@ -1214,6 +1215,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
>
>      ff_side_data_set_encoder_stats(pkt, ctx->qscale * FF_QP2LAMBDA,
> NULL, 0, AV_PICTURE_TYPE_I);
>
> +    emms_c();
>      pkt->flags |= AV_PKT_FLAG_KEY;
>      *got_packet = 1;
>      return 0;


I don't think we should litter each and every decoder/encoder with calls to
emms_c().

Ronald