Hi,
On Tue, 20 Jul 2021, 胡玮文 wrote:
After compile and run this code, run this command to inspect the dts (which
comes from the out of sync tfdt)
ffprobe -show_packets bug.mp4 | grep dts=
The output is:
dts=0
dts=1
dts=2
dts=2
dts=3
dts=4
With this patch applied, the output is:
dts=0
dts=1
Hi Martin,
OK, here I provide some codes to demo this bug. Many of these are copied from
libavformat/tests/movenc.c
#include
#include
#include
#include
static const uint8_t h264_extradata[] = {
0x01, 0x4d, 0x40, 0x1e, 0xff, 0xe1, 0x00, 0x02, 0x67, 0x4d, 0x01, 0x00,
0x02, 0x68, 0xef
};
Hi,
Thanks for the patch! I'll try to look into it in a while (I'm a bit
swamped and short on time at the moment), hopefully within a couple days
or so.
On Sun, 18 Jul 2021, Hu Weiwen wrote:
Fix an edge case when auto flushing an empty fragment, and the previous fragment
has inaccurate dura
Fix an edge case when auto flushing an empty fragment, and the previous fragment
has inaccurate duration, the track->frag_start would be out of sync from input
dts, and all subsequent tfdt box will have out of sync base_media_decode_time.
This error can accumulate to quite large over long-running s
