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

["Tomas Härdin" <git@haerdin.se>]

tis 2022-12-13 klockan 10:55 +0800 skrev zhilizhao(赵志立):
> 
> 
> > On Dec 12, 2022, at 23:28, Tomas Härdin <git@haerdin.se> wrote:
> > 
> > ons 2022-12-07 klockan 17:31 +0800 skrev Zhao Zhili:
> > > From: Zhao Zhili <zhilizhao@tencent.com>
> > > 
> > > Use input PTS as DTS has multiple problems:
> > > 1. If there is no reordering, it's better to just use the output
> > > PTS as DTS, since encoder may change the timestamp value (do it
> > > on purpose or rounding error).
> > > 
> > > 2. If there is reordering, input PTS should be shift a few frames
> > > as DTS to satisfy the requirement of PTS >= DTS. I can't find a
> > > reliable way to determine how many frames to be shift. For
> > > example,
> > > we don't known if the encoder use hierarchical B frames. The
> > > max_num_reorder_frames can be get from VUI, but VUI is optional.
> > > 
> > > 3. Encoder dropping frames makes the case worse. Android has an
> > > BITRATE_MODE_CBR_FD option to allow it explicitly.
> > 
> > Don't we already have code to parse this stuff from h.264 streams?
> 
> We have code to parse max_num_reorder_frames, if the stream contains
> the field.
> 
> We have some code to generate/guess DTS but doesn’t work reliably for
> H.264/H.265. I guess it’s hard, if not impossible. We don’t know the
> prediction structures. Use encoder’s input PTS as DTS works for some
> transport protocols like RTP, and MP4 with negative_cts_offsets,
> otherwise it’s broken due to PTS >= DTS.

Right, H.264 and H.265 support rather arbitrary reference structures. I
guess a pessimistic estimate is good enough

/Tomas

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".