[FFmpeg-devel] [PATCH] Update HDR10+ metadata structure.

Mohammad Izadi moh.izadi at gmail.com
Wed Feb 26 03:54:15 EET 2020


On Mon, Feb 24, 2020 at 9:56 AM Vittorio Giovara <vittorio.giovara at gmail.com>
wrote:

> On Sat, Feb 22, 2020 at 12:44 PM Mohammad Izadi <moh.izadi at gmail.com>
> wrote:
>
> > On Fri, Feb 21, 2020, 6:44 PM Vittorio Giovara <
> vittorio.giovara at gmail.com
> > >
> > wrote:
> >
> > > On Fri, Feb 21, 2020 at 5:17 PM Mohammad Izadi <moh.izadi at gmail.com>
> > > wrote:
> > >
> > > > Why does the struct belong to lavu? This struct is super similar to
> > > structs
> > > > in libavcodec/hevc_sei.h. We just move it to a new file to share it
> > > between
> > > > hevc and vp9 encoder/decoder.
> > > >
> > > > --
> > > >
> > >
> > > 1. Please kindly stop top posting:
> > http://www.idallen.com/topposting.html
> > > 2. It belongs to lavu because it's where the frame code generically
> code
> > > is. I'm not familiar with this API too much, but from what i gather
> users
> > > may need to have a way of accessing this data without pulling in all
> the
> > > dependencies of lavc or lavf.
> > >
> > This struct is related to parsing and SEI, not frame. If so, why other
> > structs are not in lavu? Please check similar structs in hevc_sei?
> >
>
> I don't think I understand your question, but if you need examples you can
> check these patches
> 8f58ecc344a92e63193c38e28c173be987954bbb structure defined in lavu,
> e7a6f8c972a0b5b98ef7bbf393e95c434e9e2539 structure populated in lavc
> d91718107c33960ad295950d7419e6dba292d723 structure defined in lavu, used in
> lavc
> 7e244c68600f479270e979258e389ed5240885fb same
> and so on and so on, so I'd advise you do to the same, scrapping your
> current code if necessary.
>
I will do, but let me explain the problem in more details and you may help
me for a solution. The patches you mentioned, contains two structs
AVSphericalMapping
and  AVMasteringDisplayMetadata in lavu. They are easily set (afew members)
in lavc. The struct for HDR10+ is very similar and I would keep it in lavu.
But, we have to parse and decode a message and then populate the values.
Your structs are simple and no need for parsing them in lavc.
So, my struct needs two steps : 1) parsing/encoding/decoding and 2)
populating. It is not a good idea to implement the 2 steps for each codec
separately. Instead it would be  better to implement once and reuse them as
both steps are long and complex. Now please advise me where is better to
put 1 and 2 in lavc. Right now, I have all with struct in lavu.

> --
> Vittorio
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".


More information about the ffmpeg-devel mailing list