> 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. If we can and decided to implement such algorithm, it should go in a higher level, so remux raw stream works better. > > /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". _______________________________________________ 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".
