From 2131dfda89a7c013cba353fc8f5de79ccb0c23b5 Mon Sep 17 00:00:00 2001
From: Sasi Inguva <isasi@google.com>
Date: Tue, 9 Aug 2016 18:11:57 -0700
Subject: [PATCH 2/4] avformat/avframe.h: Add a flag in AVIndexEntry to discard
frame after decoding.
Signed-off-by: Sasi Inguva <isasi@google.com>
---
libavformat/avformat.h | 3 +++
libavformat/version.h | 2 +-
2 files changed, 4 insertions(+), 1 deletion(-)
@@ -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. */
@@ -32,7 +32,7 @@
// Major bumping may affect Ticket5467, 5421, 5451(compatibility with Chromium)
// Also please add any ticket numbers that you belive might be affected here
#define LIBAVFORMAT_VERSION_MAJOR 57
-#define LIBAVFORMAT_VERSION_MINOR 46
+#define LIBAVFORMAT_VERSION_MINOR 47
#define LIBAVFORMAT_VERSION_MICRO 100
#define LIBAVFORMAT_VERSION_INT AV_VERSION_INT(LIBAVFORMAT_VERSION_MAJOR, \
--
2.8.0.rc3.226.g39d4020
Oops. I messed up with git send-email, and my message didn't occur in reply to this thread. So, here I am typing in Gmail.. Hi Clement and Michael, Sorry that I hadn't started a discussion on the patch before sending it for review. However this patch has been there for years in our ffmpeg version. I simply made some cosmetic changes to prepare it to send for review, hence I haven't wasted much work/time on it. That said, I think that the code we have, correctly decodes almost 100% of the edit list uploads that we receive and I think will be of good use to others, at least on a temporary basis, until a permanent solution can be agreed upon. As can be seen, the API changes to libav{format/codec/util} are very minor. I've fixed all the fate tests, and you can find in this doc https://docs.google.com/document/d/1V2nWYUcKsKv6uycRnknXzAnGjE3mL YcO_5ti5hLHUn8/pub , justifications of existing fate test reference modifications. I have also separated the patch into 4 patches . I messed up with git send-email so those patches got sent as separate mails. I am attaching them as files anyway here. On Mon, Aug 8, 2016 at 8:09 AM, Clément Bœsch <u@pkh.me> wrote: > Hi, > > On Fri, Aug 05, 2016 at 05:18:39PM -0700, Sasi Inguva wrote: > > In YouTube we have long been receiving MOV files from users, which have > non-trivial edit lists (Those edit lists which are not just used to offset > video start from audio start) and multiple edit lists. Recently the uploads > of such files has increased with the introduction of apps that allow video > editing and upload like Vine etc. mov.c in ffmpeg does not have edit list > parsing support i.e. the support for deciding what video/audio packets > should be output with what timestamps, based on edit lists. For this > reason, we had built a basic support for edit list parsing in our version > of ffmpeg, which fixes the AVIndexEntries built by mov_build_index by > looking at edit lists, and introduces new DISCARD flags in AVPacket and > AVFrame to signal to the decoder to discard certain packets. > > > > For a while our edit list support was broken, as in it didn't properly > work for multiple edit lists and it had problems with edit-lists ending on > B-frames. But we've fixed most of these issues in recent times, and we > think that now it is in a good enough condition so that it can be submitted > to HEAD. This will not only help the vast userbase of ffmepg, but will also > help us with staying up-to-date with ffmpeg and also by adding the power of > ffmpeg developer community to our MOV support. So here's a go at it. > > What is supported: > > - multiple edit lists > > - edit lists ending on B-frames > > - zero segment duration edit lists > > > > What is not supported: > > - Changing the rate of playing with edit lists. We basically ignore > MediaRate field of edit. > > > > I have added fate tests too. Here is a no-sign-in required link to the > test files https://drive.google.com/folderview?id=0Bz6XfEJZ- > 9N3R3o3QXNHUGRqbms&usp=sharing. > > First, thanks for working on this. But it would be much much more > appropriate to discuss such changes with developers before engaging > yourself in such heavy development. As you can guess, this issue has been > discussed many times in the past within the project, and a proper solution > had yet to come out of it. It looks like the approach you took was > dismissed in the past from an infrastructure PoV. > > I will have a look to this patch later this week, but please don't follow > this corporate approach when doing such huge contribution. You're risking > too much by doing so (your work could be dismissed, or worse your work > introduce fundamental issues within the project which we'll take years to > fix because $API) > > You can use the mailing list, or simply IRC to have quick talk with us. > > -- > Clément B. > > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > >