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

["zhilizhao(赵志立)"]

> On Dec 12, 2022, at 23:28, Tomas Härdin <git at haerdin.se> wrote:
> 
> ons 2022-12-07 klockan 17:31 +0800 skrev Zhao Zhili:
>> From: Zhao Zhili <zhilizhao at 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 at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".