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