From patchwork Thu Aug 25 19:31:19 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sasi Inguva X-Patchwork-Id: 295 Delivered-To: ffmpegpatchwork@gmail.com Received: by 10.103.140.134 with SMTP id o128csp1071953vsd; Thu, 25 Aug 2016 12:31:46 -0700 (PDT) X-Received: by 10.28.138.75 with SMTP id m72mr9282169wmd.50.1472153506835; Thu, 25 Aug 2016 12:31:46 -0700 (PDT) Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org. [79.124.17.100]) by mx.google.com with ESMTP id x206si33258192wmg.67.2016.08.25.12.31.46; Thu, 25 Aug 2016 12:31:46 -0700 (PDT) Received-SPF: pass (google.com: domain of ffmpeg-devel-bounces@ffmpeg.org designates 79.124.17.100 as permitted sender) client-ip=79.124.17.100; Authentication-Results: mx.google.com; dkim=neutral (body hash did not verify) header.i=@google.com; spf=pass (google.com: domain of ffmpeg-devel-bounces@ffmpeg.org designates 79.124.17.100 as permitted sender) smtp.mailfrom=ffmpeg-devel-bounces@ffmpeg.org Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id AF4D5687ECC; Thu, 25 Aug 2016 22:31:33 +0300 (EEST) X-Original-To: ffmpeg-devel@ffmpeg.org Delivered-To: ffmpeg-devel@ffmpeg.org Received: from mail-ua0-f181.google.com (mail-ua0-f181.google.com [209.85.217.181]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id B9C316898E2 for ; Thu, 25 Aug 2016 22:31:19 +0300 (EEST) Received: by mail-ua0-f181.google.com with SMTP id m60so61356784uam.3 for ; Thu, 25 Aug 2016 12:31:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=kXh118NuQxjce/Xj+XH2eXkZ9Ry9DJ3NXCQjKw1R8GI=; b=jMTWRby7By/AptO+hCtOd8zIvyuLOj8mM1TQeiCIicOwbE/2f7Uw7i3Bru3r0+FnaU MgquYP4fX799R1XfvExDsnZdGsgVsGpnNjgfdUzhF5YrbL9mSx8qBoRqmLtRaPJibq18 SBj9PrkdlZUReH1PQwRl1e1zS5zxIkmbhSjv42kxvmcCwd0KkGAPaVHqM4FCb/sWnGnn VDMqOKIJHYTqrht/ZNOpOQYuIJG8Y+hJgGhOnYhShG7B7m4eH9WvnrGTVDTo9fsbnEL3 eQTn9GxsxI31ZmCVrHFflbg0jqqNoATSTkbm+pstr0DBy4I1BnTmMEVVgVg+LdWOzk2r 3DDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=kXh118NuQxjce/Xj+XH2eXkZ9Ry9DJ3NXCQjKw1R8GI=; b=QB2lkCKYcckmTAUH0hVeJof2rfwL9+qH0hzT11to+hzffxVH+Ak56bmfH3LLxGpyd7 gahE4dL40Tk/zjmOUybd1FurUkhyGOc0UM+i9L3964xIKPFb9TSAid17RkM7e/NGNg8v 9R65r7YKx/1Hw6PWfmdvW2cT3ObWFOXIdSuxlJWlVyVZxFFBekU+yui24rklUouHbEZj yDYeaKnE0X/nW3Ao3yFBNg5VIjptO7zldn3EaNuzL4nsnVQB26a0tnOlsO8O5c/2rJCS E1U5XGHZ2vl+CHvYaZLM60JjBrpAbaiCOH/LLKDOWmLhjoqkF9Iii8hz/U0wDvSP1VGu uSDQ== X-Gm-Message-State: AE9vXwMdwICo+XM6Dv2KnKJ50Kp2b1PTLeBqLS5sznRuklgjJJ6ZUiYEHb/LnR8juEElinT6rP6V6GZqU64AVWwH X-Received: by 10.176.82.71 with SMTP id j7mr5881113uaa.66.1472153480739; Thu, 25 Aug 2016 12:31:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.153.207 with HTTP; Thu, 25 Aug 2016 12:31:19 -0700 (PDT) In-Reply-To: <20160825023726.GR5460@nb4> References: <20160814132424.GB26860@leki> <1471313097-26998-1-git-send-email-isasi@google.com> <1471313097-26998-2-git-send-email-isasi@google.com> <20160824230109.GP5460@nb4> <20160825023726.GR5460@nb4> From: Sasi Inguva Date: Thu, 25 Aug 2016 12:31:19 -0700 Message-ID: To: FFmpeg development discussions and patches X-Content-Filtered-By: Mailman/MimeDel 2.1.20 Subject: Re: [FFmpeg-devel] [PATCH 4/4] lavf/mov: Add support for edit list parsing. 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" oops. thanks for pointing that out. Even in our version of ffmpeg, that assert doesn't get compiled so we never catched it. That assert logic is not correct anymore. At the end of one edit list there can be frames marked as discard, for which we would keep increasing the timestamp even if they are marked as discard, so that when the timestamps are rerodered to compute PTS B-frames get the correct PTS. But the next edit list should always start with the timestamp of the last-non-discarded frame of the previous edit list. Hence we will get non-increasing timestamps added as index entries. The test may have passed for you before, because before that line was assert(..) instead of av_assert1(...) so maybe that line wasn't getting compiled before. Attaching the 4 patches again. On Wed, Aug 24, 2016 at 7:37 PM, Michael Niedermayer wrote: > On Wed, Aug 24, 2016 at 06:42:16PM -0700, Sasi Inguva wrote: > > hmm. strange. I just rebased my branch on top of head, and reran the > test, > > and it succeeds along with all other fate tests. I am attaching the 4 > > patches again here. > > you need to build with > --assert-level=2 > to see the failure > > [...] > > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > He who knows, does not speak. He who speaks, does not know. -- Lao Tsu > > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > From 4f91db6f34070f0e02ce224badaffa8c4d69d900 Mon Sep 17 00:00:00 2001 From: Sasi Inguva Date: Wed, 24 Aug 2016 18:30:01 -0700 Subject: [PATCH 2/4] avformat/avframe.h: Add a flag in AVIndexEntry to discard frame after decoding. Signed-off-by: Sasi Inguva --- libavformat/avformat.h | 3 +++ libavformat/version.h | 2 +- 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/libavformat/avformat.h b/libavformat/avformat.h index 3ee7051..d943ae1 100644 --- a/libavformat/avformat.h +++ b/libavformat/avformat.h @@ -814,6 +814,9 @@ typedef struct AVIndexEntry { * is known */ #define AVINDEX_KEYFRAME 0x0001 +#define AVINDEX_DISCARD_FRAME 0x0002 /** + * Flag is used to indicate which frame should be discarded after decoding. + */ int flags:2; int size:30; //Yeah, trying to keep the size of this small to reduce memory requirements (it is 24 vs. 32 bytes due to possible 8-byte alignment). int min_distance; /**< Minimum distance between this and the previous keyframe, used to avoid unneeded searching. */ diff --git a/libavformat/version.h b/libavformat/version.h index 88fd4cc..34226ca 100644 --- a/libavformat/version.h +++ b/libavformat/version.h @@ -32,7 +32,7 @@ // Major bumping may affect Ticket5467, 5421, 5451(compatibility with Chromium) // Also please add any ticket numbers that you believe might be affected here #define LIBAVFORMAT_VERSION_MAJOR 57 -#define LIBAVFORMAT_VERSION_MINOR 48 +#define LIBAVFORMAT_VERSION_MINOR 49 #define LIBAVFORMAT_VERSION_MICRO 100 #define LIBAVFORMAT_VERSION_INT AV_VERSION_INT(LIBAVFORMAT_VERSION_MAJOR, \ -- 2.8.0.rc3.226.g39d4020