> From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On Behalf Of Fu, > Linjie > Sent: Friday, June 12, 2020 10:39 > To: ffmpeg-devel@ffmpeg.org > Subject: Re: [FFmpeg-devel] [PATCH v2 4/5] fftools/ffmpeg: flush and > recreate encoder instance if resolution changes > > > From: Nicolas George <geo...@nsup.org> > > Sent: Friday, June 12, 2020 00:49 > > To: FFmpeg development discussions and patches <ffmpeg- > > de...@ffmpeg.org> > > Cc: Fu, Linjie <linjie...@intel.com> > > Subject: Re: [FFmpeg-devel] [PATCH v2 4/5] fftools/ffmpeg: flush and > > recreate encoder instance if resolution changes > > > > Linjie Fu (12020-06-11): > > > Add recreate_encoder_instance() function. > > > > > > If resolution changing is allowed, discard > > AV_CODEC_FLAG_GLOBAL_HEADER > > > even if the avformat/container declares AVFMT_GLOBALHEADER flag. > > Place > > > header information in every keyframe instead of single global header. > > > > Why? How is it valid? If the codec requires global header, we cannot > > just ignore them. > > IIRC, the global header in extra data is optional in codec level. By storing > the > parameter set in global header, it allows reusing of the shared information > and hence is bitrate efficient. Also it's loss robust since it allows > parameter > set content to be carried in a more reliable way.(or repeated frequently) > > Hence IMHO fallback to store the sequence header in key frame may lose > the advantage of bitrate efficient and loss robust, but it seems to be correct > since it's more fundamental. (And the test result shows it works) > > (Please correct if my understanding is not correct) > > > And if the codec can change resolution, there is no point in recreating it. > > Agree with this, for these codecs I'd prefer to implement corresponding > method > In specific encoder (like libvpx-vp9): > https://patchwork.ffmpeg.org/project/ffmpeg/patch/1565688544-9043-1- > git-send-email-linjie...@intel.com/ > Ping for this.
The patch set in series[1] would be the first step to settle down the whole solution, which supports raw video only. Then we'd focus on the common solutions(like recreating encoder instance) for the encoders who declare such capabilities. - Linjie [1] https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=1434 _______________________________________________ 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".
