[FFmpeg-devel] [PATCH 4/5] Prefer pts over dts in timestamp correction
Mon Sep 13 08:58:39 CEST 2010
On Sun, Sep 12, 2010 at 11:06 PM, Alexander Strange
<astrange at ithinksw.com> wrote:
> On Tue, Jul 27, 2010 at 9:10 AM, Michael Niedermayer <michaelni at gmx.at> wrote:
>> On Mon, Jul 26, 2010 at 01:16:09PM -0700, Alexander Strange wrote:
>>> Fixes decoder delay incorrectly causing the output picture timestamps
>>> to change.
>>> ?cmdutils.c | ? ?2 +-
>>> ?1 files changed, 1 insertions(+), 1 deletions(-)
>>> diff --git a/cmdutils.c b/cmdutils.c
>>> index cd0b194..f86a182 100644
>>> --- a/cmdutils.c
>>> +++ b/cmdutils.c
>>> @@ -682,7 +682,7 @@ int64_t guess_correct_pts(PtsCorrectionContext *ctx, int64_t reordered_pts, int6
>>> ? ? ? ? ?ctx->num_faulty_pts += reordered_pts <= ctx->last_pts;
>>> ? ? ? ? ?ctx->last_pts = reordered_pts;
>>> ? ? ?}
>>> - ? ?if ((ctx->num_faulty_pts<ctx->num_faulty_dts || dts == AV_NOPTS_VALUE)
>>> + ? ?if ((ctx->num_faulty_pts<=ctx->num_faulty_dts || dts == AV_NOPTS_VALUE)
>>> ? ? ? ? && reordered_pts != AV_NOPTS_VALUE)
>>> ? ? ? ? ?pts = reordered_pts;
>>> ? ? ?else
>> This looks like your code doesnt work with dts.
>> A file can require the use of dts by not having pts or having incorrect
>> pts, this code is there to select which of dts/pts is better.
>> Biasing slightly to pts isnt going to help if there are no pts or wrong
> Here's the specific problem + some other related ones.
> dts can be in-order and valid when it was written but still wrong. The
> problem I found is that if the initial decoder delay is underspecified
> (like h264 without num_reorder_frames set), there can be some dts
> value in the file and it will use that, but all the times will be
> assigned to the wrong pictures.
> Using a logging patch (attached)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 970 bytes
Desc: not available
More information about the ffmpeg-devel