FFmpeg

110037 Commits

37 Branches

400 Tags

492 MiB

Tag: Branch: Tree: 2db22d14bf

Commit Graph

Author	SHA1	Message	Date
Sasi Inguva	93db5e3fc4	lavf/mov.c: offset index timestamps by the minimum pts to make first pts zero If the videos starts with B frame, then the minimum composition time as computed by stts + ctts will be non-zero. Hence we need to shift the DTS, so that the first pts is zero. This was the intention of that code-block. However it was subtracting by the wrong amount. For example, for one of the videos in the bug nonFormatted.mp4 we have stts: sample_count duration 960 1001 ctts: sample_count duration 1 3003 2 0 1 3003 .... The resulting composition times are : 3003, 1001, 2002, 6006, ... The minimum composition time or PTS is 1001, which should be used to offset DTS. However the code block was wrongly using ctts[0] which is 3003. Hence the PTS was negative. This change computes the minimum pts encountered while fixing the index, and then subtracts it from all the timestamps after the edit list fixes are applied. Samples files available from: https://bugs.chromium.org/p/chromium/issues/detail?id=721451 https://bugs.chromium.org/p/chromium/issues/detail?id=723537 fate-suite/h264/twofields_packet.mp4 is a similar file starting with 2 B frames. Before this change the PTS of first two B-frames was -6006 and -3003, and I am guessing one of them got dropped when being decoded and remuxed to the framecrc before, and now it is not being dropped. Signed-off-by: Sasi Inguva <isasi@google.com>	8 years ago
Anton Khirnov	38efff92f1	FATE: add a test for H.264 with two fields per packet	9 years ago

Author

SHA1

Message

Date

Sasi Inguva

93db5e3fc4

lavf/mov.c: offset index timestamps by the minimum pts to make first pts zero

If the videos starts with B frame, then the minimum composition time
as computed by stts + ctts will be non-zero. Hence we need to shift
the DTS, so that the first pts is zero. This was the intention of that
code-block. However it was subtracting by the wrong amount.

For example, for one of the videos in the bug nonFormatted.mp4 we have

stts:
sample_count  duration
960           1001

ctts:
sample_count  duration
1             3003
2             0
1             3003
....

The resulting composition times are :  3003, 1001, 2002, 6006, ...

The minimum composition time or PTS is 1001, which should be used to
offset DTS. However the code block was wrongly using ctts[0] which is
3003. Hence the PTS was negative. This change computes the minimum pts
encountered while fixing the index, and then subtracts it from all the
timestamps after the edit list fixes are applied.

Samples files available from:

https://bugs.chromium.org/p/chromium/issues/detail?id=721451
https://bugs.chromium.org/p/chromium/issues/detail?id=723537

fate-suite/h264/twofields_packet.mp4 is a similar file starting with 2
B frames. Before this change the PTS of first two B-frames was -6006
and -3003, and I am guessing one of them got dropped when being decoded
and remuxed  to the framecrc before, and now it is not being dropped.

Signed-off-by: Sasi Inguva <isasi@google.com>

8 years ago

Anton Khirnov

38efff92f1

FATE: add a test for H.264 with two fields per packet

9 years ago

3 Commits (2db22d14bf5f0ae62e5ee335017abba3ac458ce9)