On 08/03/2019 07:44, Oliver Collyer wrote: > From c704e3535f866d9f89535b9df59db9ca9811bcf9 Mon Sep 17 00:00:00 2001 > From: Oliver Collyer <ovcoll...@mac.com> > Date: Fri, 8 Mar 2019 07:42:41 +0000 > Subject: [PATCH 1/1] avcodec/nvenc: Reconfigure resolution on-the-fly > > --- > libavcodec/nvenc.c | 31 ++++++++++++++++++++++++++++--- > libavcodec/nvenc.h | 3 +++ > libavcodec/nvenc_h264.c | 4 ++++ > libavcodec/nvenc_hevc.c | 4 ++++ > 4 files changed, 39 insertions(+), 3 deletions(-)
Can you explain the actual intended use-case for this? The current way to handle resolution changes (or any other stream change of similar magnitude, like a pixel format change) is to flush the existing encoder and then make a new one with the new parameters. Even ignoring the trivial benefit that all encoders handle this with no additional code, it has the significant advantage that all of the stream metadata, including parameter sets, can be handled correctly. The handling here does rather badly at this - stream metadata will be misleading, and if you take one of these streams and try to put it into some container with global headers you may well end up with a quite broken file. Given that, I think there should be some justification for why you might want to do this rather than following the existing approach. Some mention in the API (avcodec.h) to explain what's going on might be a good idea, since that is currently assuming that parameters like width/height are fixed and must be set before opening the encoder. Relatedly, if there isn't any support for retrieving new metadata then it should probably display a big warning if the user tries to make a stream like this with global headers, since the global headers provided to the user on startup won't actually work for the whole stream. Thanks, - Mark _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
