diff mbox

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

Message ID CAB0OVGqJSEQRJp_ef=BuC9uF1quXuqQx4rASOH_tTBRV4jqo3Q@mail.gmail.com
State Not Applicable
Headers show

Commit Message

Carl Eugen Hoyos Oct. 3, 2016, 12:46 p.m. UTC 
2016-10-03 13:57 GMT+02:00 Hendrik Leppkes <h.leppkes@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

             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;

Comments

Ronald S. Bultje Oct. 3, 2016, 1:41 p.m. UTC | #1 
Hi,

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

> 2016-10-03 13:57 GMT+02:00 Hendrik Leppkes <h.leppkes@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
diff mbox

Patch

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++) {