From patchwork Thu Jun 20 12:32:20 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Alfred E. Heggestad" X-Patchwork-Id: 13646 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 9761A44825F for ; Thu, 20 Jun 2019 15:32:30 +0300 (EEST) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 6C9B368A198; Thu, 20 Jun 2019 15:32:30 +0300 (EEST) X-Original-To: ffmpeg-devel@ffmpeg.org Delivered-To: ffmpeg-devel@ffmpeg.org Received: from mail-lj1-f195.google.com (mail-lj1-f195.google.com [209.85.208.195]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id A6EA468A0C7 for ; Thu, 20 Jun 2019 15:32:23 +0300 (EEST) Received: by mail-lj1-f195.google.com with SMTP id a21so2526009ljh.7 for ; Thu, 20 Jun 2019 05:32:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=dmJkFPPE4aZUxeAX7kPRx3KhbeBB/jQJ7idNS/5mhrg=; b=Ifeo9CnXh/U7T3bzQf6HUITGTABfzsBEJ74/PdaPY4dNEKdVZZPq8451ejt4RFkRAm 1+Ib5630vSVDAHT7Mpa96iXoGE058BbGNVwS6BJUSY8bZfhcCI+MejowgqKgcLeRaOTm Ns1y+i668Wi4wFvlKJexYriWqE8r7ciSqABMqYGrM3Sn6YC6fXPSHNX763bgZTJ7x3fj ZGC+zhYytw6P5yeSoQpzF7K+CertcIGrRzl+NP1drPckun1/DWJ6xEq6gnruhj2qsgD8 PawbO54kqSqjcTkPHwHgpbrfGQNKnvt/l7ngD1crkakZKf5u8ZZGoXxpLDQlD/Leoso5 AnQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=dmJkFPPE4aZUxeAX7kPRx3KhbeBB/jQJ7idNS/5mhrg=; b=bO6ixdmrG7Wwdm0r7RgrXUGTplY6fgQmPpsU11Xlwpq3oskAgKazHk2N5Vzji2kefp 3px/zXyPShBMFBlM8341GOPEf2rtsjcATF81/FG6KM4mwjge6kAVqEeKfakMGZnBJG+o 8adu8oES6EULfVQuDSWDKeiZikQarrmaaUZObxyaJD2PI8+xZuATEzwtBAbfaFrk/FWY RPGWt5/AL8x2lFFiu4Zpq8TUpfrDqefG00C3/Z4VEqttnk6Sj+Di0dqpa2Lefkzc4a+2 6yNTU1T/NPvFHQgDI4JI7evK/ETSffyXeunX3kvagmyl/heQrn2eHnyFOdjqED81P9st 4mPA== X-Gm-Message-State: APjAAAWzCwPLXe0C2hXQVtmhuPREN2QcI4WQz9fqx9yUTOyAI6TPnGIO Le+Ckcop9hnQ/HtANYpR04o= X-Google-Smtp-Source: APXvYqzAwoK0Yz9meCsjiqiKiYH+06jqB4Irut1ffmV6ioKWsrc1xopSf3+1NEp9CY9DYSIBwp+bzQ== X-Received: by 2002:a2e:9116:: with SMTP id m22mr22749600ljg.216.1561033942632; Thu, 20 Jun 2019 05:32:22 -0700 (PDT) Received: from Johns-MacBook-Pro.local (cm-84.208.62.181.getinternet.no. [84.208.62.181]) by smtp.gmail.com with ESMTPSA id r14sm3142386lff.44.2019.06.20.05.32.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Jun 2019 05:32:21 -0700 (PDT) To: FFmpeg development discussions and patches , Derek Buitenhuis References: <44492000-6005-5a20-ed5e-105a16c86d2d@gyani.pro> <374dc81e-446c-482c-d2c8-5544ad9cff30@gyani.pro> From: "Alfred E. Heggestad" Message-ID: <807dee22-1b8f-9404-6b7e-977a6d6d2e42@gmail.com> Date: Thu, 20 Jun 2019 14:32:20 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:60.0) Gecko/20100101 Thunderbird/60.7.1 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US Subject: Re: [FFmpeg-devel] [PATCH] movenc: calculate track_duration without packet 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 Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" On 19/06/2019 15:36, Derek Buitenhuis wrote: > On 19/06/2019 06:43, Gyan wrote: >>> setting track_duration is inconsistent; some times it includes >>> duration and some times not. >> It may be best to check the commits for these assignments to see if the >> inconsistency is deliberate. >> The track duration is written into the media header box for the track. I >> also see it being used elsewhere to adjust dts. Do those roles remain >> intact? >> >> Does FATE pass? > > Wouldn't the correct fix be to fix the places where duration is *not* > used? > > Writing the track duration without taking into account the actual > packet duration of the last packet is just wrong. That's not the > track's duration, and is in fact very problematic for low frame > rate files, such a slide shows; QuickTime will cut off at the > end of the media and track duration, dropping possibly a whole > slide, for example. > I tested with this relatively innocent patch: Test movenc failed. Look at tests/data/fate/movenc.err for details. make: *** [fate-movenc] Error 1 /alfred diff --git a/libavformat/movenc.c b/libavformat/movenc.c index 46d314ff17..719c491869 100644 --- a/libavformat/movenc.c +++ b/libavformat/movenc.c @@ -5012,7 +5012,7 @@ static int mov_flush_fragment(AVFormatContext *s, int force) if (!ff_interleaved_peek(s, i, &pkt, 1)) { if (track->dts_shift != AV_NOPTS_VALUE) pkt.dts += track->dts_shift; - track->track_duration = pkt.dts - track->start_dts; + track->track_duration = pkt.dts - track->start_dts + pkt.duration; if (pkt.pts != AV_NOPTS_VALUE) track->end_pts = pkt.pts; else but this broke the FATE test for movenc: make fate-movenc SAMPLES=fate-suite/ LD libavformat/tests/movenc TEST movenc --- ./tests/ref/fate/movenc 2019-03-24 10:21:55.000000000 +0100 +++ tests/data/fate/movenc 2019-06-20 14:27:27.000000000 +0200 @@ -134,12 +134,12 @@ 3c2c3f98c8a047f0ecefff07570fd457 9299 large_frag write_data len 1231, time nopts, type header atom ftyp write_data len 684, time -33333, type sync atom moof -write_data len 504, time 800000, type boundary atom moof -write_data len 420, time 1266667, type boundary atom moof -write_data len 668, time 1566667, type sync atom moof -write_data len 440, time 2233333, type boundary atom moof +write_data len 504, time 833333, type boundary atom moof +write_data len 512, time 1300000, type boundary atom moof +write_data len 792, time 1566667, type sync atom moof +write_data len 488, time 2233333, type boundary atom moof write_data len 262, time nopts, type trailer atom - -edd19deae2b70afcf2cd744b89b7013d 4209 vfr-noduration-interleave +f579e7fec9c37179ed2def2f8930a093 4473 vfr-noduration-interleave write_data len 1231, time nopts, type header atom ftyp write_data len 916, time 0, type sync atom moof write_data len 908, time 1000000, type sync atom moof