On Wed, 7 Aug 2013, Hendrik Leppkes wrote:
On Wed, Aug 7, 2013 at 3:25 PM, Ben Avison <[email protected]> wrote:
On Mon, 05 Aug 2013 13:29:14 +0100, Martin Storsjö <[email protected]> wrote:
What do others think about this, is the slowdown acceptable in itself? As
long as you actually do decoding, this slowdown shouldn't really be
measurable in the grand scheme of things - or is it? I guess it would
have most impact on slow systems, and patch 3/6 provides an armv6
implementation.
If this is a major sticking point, it occurs to me that it shouldn't be too
hard to have two separate copies of h264_find_frame_end(), selected between
depending upon whether an optimised h264_find_start_code_candidate function
exists for the current platform - one copy would then retain the existing
inline C implementation, and perform just as well as it ever did for non-
ARM platforms. Opinions?
Personally i just think we should pursue getting a x86 version as soon
as possible, and then avoid any added complexity.
That should then cover the grand majority of all systems.
That sounds pretty sensible to me. Any objections to this, anyone
volunteering for doing an x86 version?
// Martin
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
