On Fri, 11 Jul 2014 21:47:25 +0100, Diego Biurrun <[email protected]> wrote:
Do you plan to share this with more than H.264 and VC-1?
If I get round to them, it seems likely that at some point the same
routine will be useful for MPEG-1, MPEG-2, MPEG-4 Visual and HEVC, yes.
All this duplication could be avoided by adding a CONFIG_EXTRA entry in
configure and having the relevant bits depend on it.
I don't really know anything about configure scripts, but I'm hazarding a
guess that you mean replacing it with
OBJS-$(CONFIG_STARTCODE} += startcode.o
ARMV6-OBJS-$(CONFIG_STARTCODE} += arm/startcode_armv6.o
and then adding "startcode" to the following lines in configure:
h264_decoder_select
h264_parser_select
vc1_decoder_select
vc1_parser_select
Is that right?
+int ff_startcode_find_candidate_armv6(const uint8_t *buf, int size);
This declaration is duplicated so it should be in a header file.
Fair enough.
av_cold void ff_vc1dsp_init_arm(VC1DSPContext *dsp)
{
int cpu_flags = av_get_cpu_flags();
+ if (have_armv6(cpu_flags) && !(have_vfpv3(cpu_flags) ||
have_neon(cpu_flags))) {
+ // This function uses the 'setend' instruction which is deprecated
+ // on ARMv8. This instruction is serializing on some ARMv7 cores as
+ // well. Therefore, only use the function on ARMv6.
+ dsp->vc1_find_start_code_candidate = ff_startcode_find_candidate_armv6;
Maybe it's time to add a macro for this case to libavutil/arm/cpu.h, it
seems to get reused in multiple places already.
That wasn't in the original patch series of course. I noticed the recent
thread where the test was tightened up due to concerns about SETEND and
copied the further restrictions.
Of course, if/when someone writes a NEON version, that would remove the
need to explicitly check for its absence because the NEON one would
naturally be used in preference wherever possible.
Ben
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
