From patchwork Fri Dec 11 21:56:48 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Josh Allmann X-Patchwork-Id: 24543 Return-Path: X-Original-To: patchwork@ffaux-bg.ffmpeg.org Delivered-To: patchwork@ffaux-bg.ffmpeg.org Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by ffaux.localdomain (Postfix) with ESMTP id 23F5244904F for ; Fri, 11 Dec 2020 23:57:05 +0200 (EET) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id DE8CD68A995; Fri, 11 Dec 2020 23:57:04 +0200 (EET) X-Original-To: ffmpeg-devel@ffmpeg.org Delivered-To: ffmpeg-devel@ffmpeg.org Received: from mail-pg1-f175.google.com (mail-pg1-f175.google.com [209.85.215.175]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 9F68968A980 for ; Fri, 11 Dec 2020 23:56:58 +0200 (EET) Received: by mail-pg1-f175.google.com with SMTP id v29so8032801pgk.12 for ; Fri, 11 Dec 2020 13:56:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id; bh=8Dht6hj/ds4oRo5cXWLZbpRRGMYMjJYDvhJGEHHuteI=; b=jqsJHbyFyp5H/G13mELMahlXO1O/E4oNhy8IZ97wR6J56ZhLzUU5hxWWRJKQ79q4hE 5dTE1W0JK5TQzM6xynD7U/flRF8mveIDV9E67rAeX+heZWqZbC+xYrh5zAvNPAF+W9QF SP+YhPPd+Wf0c+/MDIVIatCjt8x9a63UhpLw6r07MivW7OppY7FJyf6+PhqtodV+zXkJ hzLrQWFspKniDgbT9zXlc2u2jQxe92m9SG5ftOyK6EeIHrQccYDzOXr8nFjvisKZX7iY r8KdBcRifixFOmnyOIk5Fmi+QiDDKIAA5mWGkZZ4uxzb1+NIde5lyiuAj+OFr1ZdD9Y5 z1yA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id; bh=8Dht6hj/ds4oRo5cXWLZbpRRGMYMjJYDvhJGEHHuteI=; b=Ha8pFM3yqorDytAFacU9QZeeJCpdIwtBpoX0csmtLBpu1O1aGIc7YsT5S2XDSv6FmE NSCZWBsbp4h0G9YwwfR4XRdGLPWiXm/YmkLAaq4JAqFCBqQmTbd/ylLh4EDge5odxPag 9qmwp2iWNcb2manO4OEzmsvQ364W1ml1hyGa5CAWxTItU5spGuh3znun3o5I1SYPbOcb On5zvuM8huAnCpngtugSiZfGOIpLmjSbAFBRL0LZbe107sjErw5HAKPnuTBjsxbQYOG3 PB0Ig4utQdzXY7Vg9MESgIarVCOOMwlogpM3gnOr7hx666MgLk8I81ccGESI/T2oh92D T0Pw== X-Gm-Message-State: AOAM533UTiwvQRu7mMxArZ0N7tUqcQweO9OSJ5MzWleWZxN3f1FisEj5 UI2U3eJFE5vWGvXYtz0ZPgIh20M/CH9NBA== X-Google-Smtp-Source: ABdhPJyQF+F9LeR5hUUVLrN5XPQzclcm1AbfulG6TF9+EUM7v7wL9aXB+bydl2bkz8c32wNGTLgHYw== X-Received: by 2002:a65:63da:: with SMTP id n26mr13749417pgv.306.1607723816301; Fri, 11 Dec 2020 13:56:56 -0800 (PST) Received: from localhost.localdomain (cpe-76-172-80-40.socal.res.rr.com. [76.172.80.40]) by smtp.gmail.com with ESMTPSA id t36sm10456513pfg.55.2020.12.11.13.56.55 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 11 Dec 2020 13:56:55 -0800 (PST) From: Josh Allmann To: ffmpeg-devel@ffmpeg.org Date: Fri, 11 Dec 2020 13:56:48 -0800 Message-Id: <1607723808-8154-1-git-send-email-joshua.allmann@gmail.com> X-Mailer: git-send-email 2.7.4 Subject: [FFmpeg-devel] [PATCH] avformat/movenc: Remove dts delay from duration. X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches MIME-Version: 1.0 Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" A negative start_dts value (eg, delay from edit lists) typically yields a duration larger than end_pts. During edit list processing, the delay is removed again, yielding the correct duration within the elst. However, other duration-carrying atoms (tkhd, mvhd, mdhd) still have the delay incorporated into their durations. This is incorrect. Fix this by withholding delay from the duration if edit lists are used. This also simplifies edit-list processing a bit, since the delay does not need to be removed from the calculated duration again. --- The mov spec says that the tkhd duration is "derived from the track's edits" [1] and the duratons of the other atoms (mvhd, mdhd) are in turn taken from the longest track. So it seems that incorporating the delay into the track duration is a bug in itself when the edit list has the correct duration, and this propagates out tothe other top-level durations. Unsure of how this change interacts with other modes that may expect negative timestamps such as CMAF, so the patch errs on the side of caution and only takes effect if edit lists are used. Can loosen that up if necessary. [1] https://developer.apple.com/library/archive/documentation/QuickTime/QTFF/QTFFChap2/qtff2.html#//apple_ref/doc/uid/TP40000939-CH204-BBCEIDFA libavformat/movenc.c | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/libavformat/movenc.c b/libavformat/movenc.c index 7db2e28840..31441a9f6c 100644 --- a/libavformat/movenc.c +++ b/libavformat/movenc.c @@ -2831,7 +2831,14 @@ static int64_t calc_pts_duration(MOVMuxContext *mov, MOVTrack *track) if (track->end_pts != AV_NOPTS_VALUE && track->start_dts != AV_NOPTS_VALUE && track->start_cts != AV_NOPTS_VALUE) { - return track->end_pts - (track->start_dts + track->start_cts); + int64_t dur = track->end_pts, delay = track->start_dts + track->start_cts; + /* Note, this delay is calculated from the pts of the first sample, + * ensuring that we don't reduce the duration for cases with + * dts<0 pts=0. */ + if (delay > 0 || !mov->use_editlist) { + dur -= delay; + } + return dur; } return track->track_duration; } @@ -3118,10 +3125,6 @@ static int mov_write_edts_tag(AVIOContext *pb, MOVMuxContext *mov, * rounded to 0 when represented in MOV_TIMESCALE units. */ av_assert0(av_rescale_rnd(start_dts, MOV_TIMESCALE, track->timescale, AV_ROUND_DOWN) <= 0); start_ct = -FFMIN(start_dts, 0); - /* Note, this delay is calculated from the pts of the first sample, - * ensuring that we don't reduce the duration for cases with - * dts<0 pts=0. */ - duration += delay; } /* For fragmented files, we don't know the full length yet. Setting