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

[Michael Niedermayer]

On Sat, Oct 12, 2013 at 01:59:29PM -0700, Timothy Gu wrote:
> 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?).

its in addition to the other patch

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Republics decline into democracies and democracies degenerate into
despotisms. -- Aristotle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20131012/fddbc70e/attachment.asc>