[FFmpeg-devel] [PATCH] libutvideo: remove libutvideo wrapper

[Stephen Hutchinson]

On Thu, Oct 16, 2014 at 11:02 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
> On Thu, Oct 16, 2014 at 04:29:13PM -0800, Lou Logan wrote:
>> Native decoder and encoder exists.
>>
>> Signed-off-by: Lou Logan <lou at lrcd.com>
>> ---
>> I don't know if libutvideo has any advantages over native; maybe Derek
>> can elaborate (and answer other questions).
>>
>> Native seemed faster for decoding and encoding in my lazy, quick tests.
>>
>> Mostly a boredom patch/RFC...
>>
>> Todo:
>> =====
>> * I probably forgot to remove something.
>> * Update Changelog.
>> * Version bump.
>>
>>  LICENSE.md                   |   3 -
>>  MAINTAINERS                  |   1 -
>>  configure                    |   6 --
>>  libavcodec/Makefile          |   4 -
>>  libavcodec/allcodecs.c       |   1 -
>>  libavcodec/libutvideo.h      |  70 ------------
>>  libavcodec/libutvideodec.cpp | 212 -------------------------------------
>>  libavcodec/libutvideoenc.cpp | 246 -------------------------------------------
>
> this removes the possibility to easily test our decoder against
> libutvideo.
> Also iam happy to volunteer to take over maintainership for the
> libutvideo wraper if that is wanted, as i suspect that would be
> less work than fixing future issues in utvideo without an easy
> accessible reference
>
> [...]
>

>From my perspective as the one taking the Ut Video release zips
and updating libutvideo itself, I don't particularly care whether the
lib wrapper is removed.  Not that I can provide any insight beyond
that, since I only make sure the lib still compiles.

libutvideoenc is locked to only one prediction type, and the speed
issues in either the encoder or decoder wrapper could (probably are)
the side-effect of libutvideo not enabling the asm by default (mostly
because the asm has had some issues with integration, whether
that's a 'the asm doesn't compile under X, Y, or Z conditions' or
'the asm crashes if you look at it funny').  But since I'm not
typically on a computer that can take advantage of the asm
that's there, I've never really checked whether enabling it
makes that much of difference in speed for the wrappers.

The wrappers also don't support the 10-bit variants of Ut Video's
4:2:2 codec, but when I last checked, the native one didn't either.

On a separate tangent, if the wrapper ends up staying,
simplifying the wrapper's checks for libutvideo's versioning
(and feature set) would probably be best served by
shifting the library check to pkg-config (it would also make it
to where configure wouldn't have to hardcode -lstdc++ into
the library check; I was trying to hammer better detection
for that out with libutvideo's build system, but haven't
gotten that far; it still just assumes the use of g++ and
libstdc++).  It also poses a problem because
there'd need to be a C++-specific pkg-config header check
added to FFmpeg's configure. I do have a patch for moving
libutvideo detection over to pkg-config on my github repo
(github.com/qyot27/FFmpeg/commits/more_pkgconfig), but
it's more of a POC since I severely doubted a pkg-config cpp
check that mostly duplicates the existing C header check
would be approved (and because libutvideo is the only
thing that would even use it).