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

[Vittorio Giovara]

On Tue, Feb 25, 2020 at 9:16 PM Mohammad Izadi <moh.izadi at gmail.com> wrote:

> 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.
>

Hi Mohammad,
thanks for explaining the problem a bit better. If that's the case you
could have an helper function that parses the data in lavc (usually these
functions are prefixed with ff_, meaning their intended use is internal
within a library) and use the helper function to parse whatever buffer you
pass. This wrapper could then return a lavu struct to be embedded in a side
data message like in the examples I sent you.
Let me know if this is clear enough for you
Thanks
-- 
Vittorio