[FFmpeg-devel] [PATCH v2 4/5] fftools/ffmpeg: flush and recreate encoder instance if resolution changes

[Fu, Linjie]

> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of Fu,
> Linjie
> Sent: Friday, June 12, 2020 10:39
> To: ffmpeg-devel at ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH v2 4/5] fftools/ffmpeg: flush and
> recreate encoder instance if resolution changes
> 
> > From: Nicolas George <george at nsup.org>
> > Sent: Friday, June 12, 2020 00:49
> > To: FFmpeg development discussions and patches <ffmpeg-
> > devel at ffmpeg.org>
> > Cc: Fu, Linjie <linjie.fu at 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.fu at 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