[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
> Nicolas George
> Sent: Tuesday, June 16, 2020 21:40
> To: FFmpeg development discussions and patches <ffmpeg-
> devel at ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH v2 4/5] fftools/ffmpeg: flush and
> recreate encoder instance if resolution changes
> 
> Fu, Linjie (12020-06-16):
> > Chapter 2.3 Parameter Sets in < High Efficiency Video Coding (HEVC)
> > Algorithms and Architectures> [1]:
> 
> That is ONE codec. Not all of them.
> 
> > Indeed, the definition in spec is just the conformance, and how an encoder
> is
> > implemented in Libavcodec (and external library if any) is the thing really
> matters.
> >
> > For encoders like libx264[2], libx265[3], libopenh264[4], if
> AV_CODEC_FLAG_GLOBAL_HEADER
> > flag is declared, the parameter Sets would be copied to extra data as the
> global header.
> > If not, parameter sets would be kept in the original bitstream, since it's
> fundamentally
> > supported in the encoder.
> 
> IIRC, encapsulation standards mandate one or the other for their
> respective formats. We cannot choose.
> 
> Fact is, you cannot concatenate two packet streams and expect it to
> work.
> 
Okay, there are also some discussions on IRC yesterday about this, and one
Idea from Anton is to provide some bigger-picture solutions for concatenating
streams, maybe a bitstream filter to accommodate streamcopy.

Hence, I'd like to keep it open for now until we reach the concensus.

And I'd like to apply the patch set [1] soon for auto scale if no objections, as the first step
and touches raw video only for restricted usage for now (which is documented clearly).
This is already being waited for some time.

- Linjie

[1] https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=1434