[FFmpeg-devel] [Internet]Re: [PATCH v2 5/7] avcodec/mediacodecenc: remove the strategy to create DTS

[Anton Khirnov]

Quoting Zhao Zhili (2023-01-04 15:46:52)
> 
> > From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of Tomas Härdin
> > Sent: 2023年1月4日 22:00
> > To: FFmpeg development discussions and patches <ffmpeg-devel at ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] [Internet]Re: [PATCH v2 5/7] avcodec/mediacodecenc: remove the strategy to create DTS
> > 
> > ons 2023-01-04 klockan 19:31 +0800 skrev zhilizhao(赵志立):
> > >
> > > > On Jan 4, 2023, at 18:16, Anton Khirnov <anton at khirnov.net> wrote:
> > > >
> > > > Does this mean the encoder will produce packets with
> > > > dts=AV_NOPTS_VALUE?
> > >
> > > MediaCodec should not encode B frames by default, so dts = pts by
> > > default.
> > > B frames can be enabled explicitly, in that case dts is
> > > AV_NOPTS_VALUE.
> > >
> > > Android system’s MP4 muxer works very hard to recreate dts to
> > > workaround
> > > the limitation of MediaCodec API. It create ‘valid’ but almost
> > > useless
> > > files with a lot of jitters.
> > 
> > Maybe we should disallow B-frames entirely until the MediaCodec API is
> > fixed so as to not add to this mess?
> 
> There are some valid usecases. For example, RTP works fine without DTS.
> With some restriction or precondition, use can create DTS too. So I'd like
> to keep the feature.

It is currently an API guarantee that all encoders return valid DTS
values, so this encoder is behaving in an invalid way.

If you want to keep B-frame functionality in this half-working state,
I'd say it should be hidden behind something like -strict experimental.

-- 
Anton Khirnov