On Fri, Nov 24, 2017 at 5:42 PM, Michael Niedermayer <mich...@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 <mich...@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 propose a different wording to allow encoders to slightly adjust the value in a compatible manner, we're all ears. :) - Hendrik _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
