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