[FFmpeg-devel] [PATCH 7/7] lavc: add libopenhevc support

[Timothy Gu]

On Oct 12, 2013 1:44 PM, "Timothy Gu" <timothygu99 at gmail.com> wrote:
>
> On Oct 12, 2013 12:27 PM, "Clément Bœsch" <u at pkh.me> wrote:
> >
> > On Sat, Oct 12, 2013 at 08:54:05PM +0200, Michael Niedermayer wrote:
> > > On Sat, Oct 12, 2013 at 08:25:50PM +0200, Clément Bœsch wrote:
> > > > On Sat, Oct 12, 2013 at 06:44:32PM +0200, Michael Niedermayer wrote:
> > > > > Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
> > > > > ---
> > > > >  configure                |    4 ++
> > > > >  libavcodec/Makefile      |    1 +
> > > > >  libavcodec/allcodecs.c   |    1 +
> > > > >  libavcodec/libopenhevc.c |  127
++++++++++++++++++++++++++++++++++++++++++++++
> > > > >  4 files changed, 133 insertions(+)
> > > > >  create mode 100644 libavcodec/libopenhevc.c
> > > > >
> > > >
> > > > "openHEVC is a fork from smarter's libav git (smarter.free.fr) with
only
> > > > required files from libav to decode HEVC content."
> > > >
> > > > What's the point of this? Isn't it supposed to be meaningful only
outside
> > > > FFmpeg/Libav?
> > >
> > > It depends on smarter, the other openhevc developers and any other
> > > authors or maintainers of the hevc code.
> > >
> >
> > The fork sounds like it is meant to be useful temporary solution until
it
> > is upstreamed.
> >
> > > More precissely, it depends on where they want to and will maintain
> > > the hevc code.
> >
> > > If they maintain the code exclusivly in openhevc then its quite
> > > possible that the wrapper would be more feature packed and bugfree
> > >  than the integrated code at the same time.
> > >
> > > OTOH if they maintain the code in FFmpeg and openhevc, then the
> > > wrapper would be quite usefull for comparing and testing.
> > > (and everyone is of course always welcome to maintain code in ffmpeg)
> > >
> > > the only situation i can see ATM where the wraper would be useless is
> > > when openhevc would not be actively maintained by anyone anymore.
> > >
> > > I cant read peoples minds so i have no idea where the hevc code will
> > > be maintained in the future.
> >
> > > simply supporting all options seemed best and simplest to me, no need
> > > to predict politics ...
> >
> >
> > I'd say it's likely the fork will be dropped/abandoned later after it's
> > upstreamed, because it would not make any sense anymore, assuming it's
the
> > exact same code base origin: having a libavcodec build with only native
> > hevc decoder would be exactly the same as providing such library.
> >
> > Of course if I'm wrong we can apply that decoder later, but since
dropping
> > is harder than adding, I'd suggest to put this patch in standby until
that
> > fork is feature/bugfix relevant.
>
> +1. It's kind of like Aften.

On a second thought, there might be some use in applying the patch. I just
need to know is this patch an addition to the other native patch or is an
alternative of that (do you want to apply both of them or one of them?).

Timothy