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