Quoting Zhao Zhili (2023-01-04 15:46:52) > > > From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On Behalf Of Tomas > > Härdin > > Sent: 2023年1月4日 22:00 > > To: FFmpeg development discussions and patches <ffmpeg-devel@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 <an...@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 _______________________________________________ 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".
