On Thu, Oct 16, 2014 at 11:02 PM, Michael Niedermayer <michae...@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 <l...@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). _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel