[FFmpeg-devel] [PATCH] avfilter: initial macroblock types export and visualization

Michael Niedermayer michael at niedermayer.cc
Thu Nov 2 13:05:18 EET 2017


Hi

On Sat, Oct 28, 2017 at 07:43:05AM -0400, Ronald S. Bultje wrote:
> Hi,
> 
> On Fri, Oct 27, 2017 at 10:14 PM, Michael Niedermayer <
> michael at niedermayer.cc> wrote:
> 
> > On Fri, Oct 27, 2017 at 10:03:54PM +0200, Paul B Mahol wrote:
> > > Signed-off-by: Paul B Mahol <onemda at gmail.com>
> > > ---
> > >  libavcodec/mpegvideo.c     |  10 +++++
> > >  libavfilter/vf_codecview.c | 105 ++++++++++++++++++++++++++++++
> > +++++++++++++++
> > >  libavutil/frame.h          |   4 ++
> > >  3 files changed, 119 insertions(+)
> >
> > First, thanks for working on this.
> >
> >
> > [...]
> >
> > > diff --git a/libavutil/frame.h b/libavutil/frame.h
> > > index fef558ea2f..8481dc080b 100644
> > > --- a/libavutil/frame.h
> > > +++ b/libavutil/frame.h
> > > @@ -141,6 +141,10 @@ enum AVFrameSideDataType {
> > >       * metadata key entry "name".
> > >       */
> > >      AV_FRAME_DATA_ICC_PROFILE,
> > > +    /**
> > > +     * Macroblock types exported by some codecs.
> > > +     */
> > > +    AV_FRAME_DATA_MACROBLOCK_TYPES,
> > >  };
> > >
> >
> > This makes the internal data of the decoder part of the ABI and API of
> > libavcodec and libavfilter
> > and its undocumented
> >
> > do people prefer to make the internal data part of the ABI, document
> > it and ensure it does not change till the next bump
> >
> [..]
> 
> > or is there some other option iam missing ?
> >
> 
> I noted this on IRC also. A third option is to not document it and consider
> it codec-specific.
> 
> (Codec-specific implies "ABI/API unstable" and subject to change - "don't
> mix versions".)

If you say the interface is "ABI/API unstable" then we cannot use it
from another lib like libavfilter. So this would not work.


> 
> > or design a new interface, document it and convert to it?
> 
> I think we'd all prefer this, but this requires someone to do the work.
> Exciting!

how generic do we want this to be ?
do we have a volunteer to implement this ? because IMO the volunteer
doing the work should be the one primarly deciding how generic to do
this ...

16x16 MB only, or any size ?
first level of subdivision only or multi level ?
only H/V divisions at 50% points or any points, what about divisions by
non 90° angles?
what about non square or non rectangular MBs ?


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

Modern terrorism, a quick summary: Need oil, start war with country that
has oil, kill hundread thousand in war. Let country fall into chaos,
be surprised about raise of fundamantalists. Drop more bombs, kill more
people, be surprised about them taking revenge and drop even more bombs
and strip your own citizens of their rights and freedoms. to be continued
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20171102/d386d182/attachment.sig>


More information about the ffmpeg-devel mailing list