[FFmpeg-devel] [PATCH, RFC] lavc/options_table: Add basic candidate h264 profiles

Fu, Linjie linjie.fu at intel.com
Wed May 6 13:50:55 EEST 2020


> From: mypopy at gmail.com <mypopy at gmail.com>
> Sent: Wednesday, May 6, 2020 18:13
> To: FFmpeg development discussions and patches <ffmpeg-
> devel at ffmpeg.org>
> Cc: Fu, Linjie <linjie.fu at intel.com>
> Subject: Re: [FFmpeg-devel] [PATCH, RFC] lavc/options_table: Add basic
> candidate h264 profiles
> 
> On Wed, May 6, 2020 at 6:04 PM mypopy at gmail.com <mypopy at gmail.com>
> wrote:
> >
> > On Wed, May 6, 2020 at 5:40 PM Martin Storsjö <martin at martin.st> wrote:
> > >
> > > On Wed, 6 May 2020, Linjie Fu wrote:
> > >
> > > > Allows specifying avctx->profile with string type profile for
> > > > h264 encoders.
> > > >
> > > > Private field/option "profile" may be abled to be removed for basic
> > > > h264 profiles, directly for encoders like libopenh264/h264_vaapi,
> > > > or with an map to hardware profile like h264_qsv.
> > > >
> > > > Signed-off-by: Linjie Fu <linjie.fu at intel.com>
> > > > ---
> > > > One concern is some encoders have options for specific profiles,
> > > > like "high444p" for nvenc_h264 and "constrained_high" for h264_amf,
> > > > hence they may not be able to remove the private option easily.
> > > >
> > > > Please help to comment.
> > > >
> > > > libavcodec/options_table.h | 4 ++++
> > > > 1 file changed, 4 insertions(+)
> > >
> > > This change in itself looks sensible to me (but I'd like for someone else
> > > to comment as well). Even if it might not be able to get rid of the
> > > private option for all encoders, it should at least simplify the easiest
> > > cases.
> > >
> > > // Martin
> > I think we have a discussion about this case,
> > https://patchwork.ffmpeg.org/project/ffmpeg/patch/fa14da65-9e1a-
> c74b-b3cb-46fc5f3ea932 at gmail.com/

Ahh, thanks for this input since it seems to be well-discussed.

> I agree with Hendrik Leppkes, and I think "main" more natural than
> "h264_main"  for 264 codec profile from a user viewpoint, both of
> command line tools or  application program interface

Indeed, being natural makes sense.
(otherwise we would have used numeric values instead)

- Linjie





More information about the ffmpeg-devel mailing list