On Fri, 11 Jul 2014 21:39:00 +0100, Diego Biurrun <[email protected]> wrote:
This looks copied, please adjust your git configuration as described in
https://www.libav.org/git-howto.html#Personal-Git-installation
to detect copies in patches you send, makes them much easier to review.
Thanks, I wasn't aware of that, very useful. I will resend in a moment in
that form.
+ * This file is part of FFmpeg.
Not quite.
Oops, sorry. I contribute to both forks - there are projects I use that
are downstream of each - which entails much porting of changes back and
forth. Usually I remember to change the headers of new files; this time a
couple slipped through the net.
I'd drop all the copyright and @author attributions, they are likely
inaccurate anyway.
Looking back through git history, the algorithm in question originated in a
commit to libavcodec/h264_parser.c on 2008-12-23 (before the fork). It
had already moved source files once since then, but I believe the
attribution is correct. Not sure about the dates, but I copied those from
the header of libavcodec/arm/h264dsp_armv6.S.
Of course, I still believe my algorithm is fundamentally better, since it
operates on 16-bit quantities. But it does rely upon being able to
interpret those 16-bit quantities as big-endian integers, which can't be
done in portable C. (Of course, to diverge into a recent related thread,
it also relies upon the SETEND instruction, which is deprecated in ARMv8.
This seems like an opportunity for someone to write a NEON version to me.)
> +int ff_startcode_find_candidate_c(const uint8_t *buf, int size);
Please drop the _c suffix while you're at it, it's plain silly.
It also seems to be the convention throughout the rest of libav wherever
there are alternate implementations of a function. No suffix is used for
the function pointers; _c is used for the generic C implementation, _vfp
for ARM VFP, _neon for ARM NEON, _sse2 for x86 SSE2, and so on.
Ben
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
