On Sat, Sep 25, 2021 at 04:51:58PM +0300, Jan Ekström wrote: > On Sat, Sep 25, 2021 at 4:35 PM <lance.lmw...@gmail.com> wrote: > > > > On Sat, Sep 25, 2021 at 03:35:53PM +0300, Jan Ekström wrote: > > > On Thu, Sep 23, 2021 at 6:08 PM <lance.lmw...@gmail.com> wrote: > > > > > > > > On Thu, Sep 23, 2021 at 05:11:49PM +0300, Jan Ekström wrote: > > > > > On Thu, Sep 23, 2021 at 4:46 PM Christopher Degawa > > > > > <c...@randomderp.com> wrote: > > > > > > > > > > > > On Sun, Sep 19, 2021 at 2:02 PM Christopher Degawa > > > > > > <c...@randomderp.com> > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > On Fri, Sep 17, 2021 at 9:28 PM <lance.lmw...@gmail.com> wrote: > > > > > > > > > > > > > >> From: Limin Wang <lance.lmw...@gmail.com> > > > > > > >> > > > > > > >> Signed-off-by: Limin Wang <lance.lmw...@gmail.com> > > > > > > >> > > > > > > > As a note, I personally favor this patch over mine since I don't > > > > > > > think > > > > > > > `enable_tpl_la` is worth exposing to the user if its main role is > > > > > > > to switch > > > > > > > between crf and cqp > > > > > > > > > > > > > > > > > > > Ping on this patch, this has been requested on SVT-AV1's side as > > > > > > well > > > > > > > > > > I think my further comments on the previous version were mostly to > > > > > move off from the rc option for rate control, which has become more > > > > > and more seemingly unnecessary (and different from most other encoders > > > > > for no obvious reason). > > > > > > > > > > The only option that with a quick look doesn't match just setting > > > > > quantizer|bit rate|CRF is "cvbr", but it doesn't seem to be impossible > > > > > to either rework "rc" for it, or to utilize a separate option for it. > > > > > > > > Do you think it's OK to remove the rc option? to match other encoders, > > > > We can choose the rate control by the related parameters like: > > > > > > > > if (crf >= 0) > > > > choose crf rate control; > > > > else if (bitrate > 0) > > > > choose cvbr rate control; > > > > else if (cqp >=0 ) > > > > choose cqp rate control; > > > > > > > > > > In general that is the idea, yes (except bit rate would mean either > > > vbr or cvbr). It would be nice to follow whatever is the default on > > > SVT-AV1's side by default, and then if the user specifies a rate > > > control mode that is not the default, his selection is honored. Not > > > sure what the best way for that is to be honest. Possibly the style of > > > setting AVCodecDefault a la libx265? > > > > > > For the rc option, given how much SVT-AV1 itself is in flux, I would > > > be OK with removing the option, or making it an option that decides > > > between cvbr and vbr (essentially making it "VBR bit rate control > > > mode"). I wish cvbr would instead be something like VBV/HRD elsewhere, > > > so we could just utilize maxrate&bufsize for controlling it, instead > > > of having it as another discrete rate control mode. > > > > Yes, I think it's preferable to use utilize maxrate&bufsize to control > > cbr and vbr as most of encoder. Then I'll follow this direction to update > > the patch. > > > > Unfortunately that was just wishful thinking :) . > > Unless you can set the buffer size and max rate in SVT-AV1, of course. > With the limited looking I've done CVBR just uses the bit rate for > each GOP instead of average over the whole clip.
As it's not very clear yet, so I'll not update this patch anymore. > > > > > > > As these things change, I also hope that SVT-AV1 will soon get a > > > key=value style of option API, that way the wrapper will not have to > > > be updated constantly according to the changes in the library :) . As > > > I feel SVT-AV1 will be changed quite a bit in the future (due to its > > > recent age). > > > > > > > Yes, it's good to add svtav1-opts so that we can utilize the update options > > directly. > > > > Let's go with -params ;) Since that is what modules seem to have > standardized on (x264|x265|rav1e|aom) :) > > But that is anyways in the future, since SVT-AV1 doesn't have such an > API yet (as far as I know). I think I have tried to add new options half year again, there are willing to hold and let to wait for the params API. > > Jan > _______________________________________________ > 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". -- Thanks, Limin Wang _______________________________________________ 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".
