[FFmpeg-devel] [PATCH]lavc/avcodec: Allow libavcodec to overwrite profile and level

[Michael Niedermayer]

On Fri, Nov 24, 2017 at 05:50:36PM +0100, Hendrik Leppkes wrote:
> On Fri, Nov 24, 2017 at 5:42 PM, Michael Niedermayer
> <michael at niedermayer.cc> wrote:
> > On Fri, Nov 24, 2017 at 12:47:16AM +0100, Carl Eugen Hoyos wrote:
> >> 2017-11-23 22:58 GMT+01:00 Michael Niedermayer <michael at niedermayer.cc>:
> >> > On Thu, Nov 23, 2017 at 04:01:06PM +0100, Carl Eugen Hoyos wrote:
> >> >> Hi!
> >> >>
> >> >> The (external) encoders may overwrite level and profile because of
> >> >> requested encoding properties, allowing libavcodec to (also) overwrite
> >> >> them in the context makes sense (and is already done in some cases
> >> >> afaict).
> >> >>
> >> >> Please comment, Carl Eugen
> >> >
> >> > If a user needs to generate a file with a specific profile/level
> >> > for example because its for broadcast, some specification or a hw
> >> > decoder.
> >> > How could he after this patch ensure that exactly the needed profile
> >> > is used?
> >>
> >> Afair, x264 does change profile and / or level depending on properties
> >> set by the user. Currently there is no way for the libavcodec user to
> >> know that libx264 changed something.
> >> With this change the user can know that he does not get the
> >> requested values.
> >>
> >> Or am I wrong and libx264 never overwrites requested values
> >> for level and / or profile?
> >
> > IIUC (someone please correct me if iam wrong) libx264 can change
> > the profile/level to a compatible one.
> >
> > The proposed API would allow any change.
> > That would add a requirement to the user apps to check if the actual
> > profile/level is compatible to the users requirements. And that would
> > make this require special treatment in many user apps, not just pass
> > user options to ffmpeg
> >
> 

> But this change doesn't actually change behavior. If you want to

No change to any (API) documentation changes implementation behavior.

It allows though implementations to change behavior and then also
requires the other side of the interface to support this.

aka badly worded API docs can lead to misunderstanding and pain


> propose a different wording to allow encoders to slightly adjust the
> value in a compatible manner, we're all ears. :)

Maybe something like this:

An encoder may change this to a compatible profile / level.
For example if profile.level 5.7 requires decoder support of lower
levels then an encoder may choose to use 5.6 instead and update these
fields.

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Everything should be made as simple as possible, but not simpler.
-- Albert Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20171124/99a1ebb7/attachment.sig>