On Tue, Feb 25, 2020, 9:32 PM Vittorio Giovara <vittorio.giov...@gmail.com> wrote:
> On Tue, Feb 25, 2020 at 9:16 PM Mohammad Izadi <moh.iz...@gmail.com> > wrote: > > > On Mon, Feb 24, 2020 at 9:56 AM Vittorio Giovara < > > vittorio.giov...@gmail.com> > > wrote: > > > > > On Sat, Feb 22, 2020 at 12:44 PM Mohammad Izadi <moh.iz...@gmail.com> > > > wrote: > > > > > > > On Fri, Feb 21, 2020, 6:44 PM Vittorio Giovara < > > > vittorio.giov...@gmail.com > > > > > > > > > wrote: > > > > > > > > > On Fri, Feb 21, 2020 at 5:17 PM Mohammad Izadi < > moh.iz...@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@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
