tis 2022-12-13 klockan 10:55 +0800 skrev zhilizhao(赵志立): > > > > On Dec 12, 2022, at 23:28, Tomas Härdin <g...@haerdin.se> wrote: > > > > ons 2022-12-07 klockan 17:31 +0800 skrev Zhao Zhili: > > > From: Zhao Zhili <zhiliz...@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-requ...@ffmpeg.org with subject "unsubscribe".