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

Timothy Gu timothygu99 at gmail.com
Sat Oct 12 22:44:00 CEST 2013


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.

Timothy


More information about the ffmpeg-devel mailing list