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

[Mohammad Izadi]

On Tue, Feb 25, 2020, 9:32 PM Vittorio Giovara <vittorio.giovara at gmail.com>
wrote:

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

Thanks for your solution. I have to use the parser or helper function in
libavformat for mkv too. Am I allowed to use the ff_ helpers in lavf?

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