On Thu, Oct 27, 2016 at 10:59 PM, Philip Langdale <phil...@overt.org> wrote: > On 2016-10-27 13:47, Hendrik Leppkes wrote: >> >> On Thu, Oct 27, 2016 at 5:09 PM, Philip Langdale <phil...@overt.org> >> wrote: >>> >>> On Thu, 27 Oct 2016 16:01:42 +0200 >>> Timo Rothenpieler <t...@rothenpieler.org> wrote: >>> >>>> > >>>> > breaks fate: >>>> > >>>> > ./configure && make -j12 fate-vsynth1-msmpeg4 >>>> > ... >>>> > TEST vsynth1-msmpeg4 >>>> > --- ./tests/ref/vsynth/vsynth1-msmpeg4 2016-10-27 >>>> > 03:11:18.675647981 +0200 +++ tests/data/fate/vsynth1-msmpeg4 >>>> > 2016-10-27 15:01:15.397863504 +0200 >>>> >>>> Does fate seriously test crystalhd hardware? >>>> I doubt this patch/series is related to that. >>> >>> >>> Yeah, that's failing because it's attempting to load the decoder and >>> the library spams stdout (which sucks, but what can you do) with the >>> error messages. >>> >>> I've already marked the codec as AV_CODEC_CAP_AVOID_PROBING so I don't >>> think there's anything else I can do. >>> >> >> If the decoder is being used without requesting it explicitly, then >> something is wrong somewhere. >> All these hardware decoders should only ever get used when the user >> asks for it directly. > > > I suspect the answer is this: > > REGISTER_DECODER(MSMPEG4_CRYSTALHD, msmpeg4_crystalhd); > REGISTER_DECODER(MSMPEG4V1, msmpeg4v1); > REGISTER_ENCDEC (MSMPEG4V2, msmpeg4v2); > REGISTER_ENCDEC (MSMPEG4V3, msmpeg4v3); > > It's getting first priority due to declaration order. I imagine that > moving it last will avoid this test failure. > >
Indeed. Hardware codecs should appear after the software. - Hendrik _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
