Re: [Cellar] Mapping of MOV clean aperture values to Matroska

Kieran O Leary <kieran.o.leary@gmail.com> Tue, 05 May 2020 12:13 UTC

Return-Path: <kieran.o.leary@gmail.com>
X-Original-To: cellar@ietfa.amsl.com
Delivered-To: cellar@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C01D3A165C for <cellar@ietfa.amsl.com>; Tue, 5 May 2020 05:13:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mKM8RSya3b9W for <cellar@ietfa.amsl.com>; Tue, 5 May 2020 05:13:37 -0700 (PDT)
Received: from mail-qt1-x833.google.com (mail-qt1-x833.google.com [IPv6:2607:f8b0:4864:20::833]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 648323A164C for <cellar@ietf.org>; Tue, 5 May 2020 05:13:37 -0700 (PDT)
Received: by mail-qt1-x833.google.com with SMTP id s30so1690564qth.2 for <cellar@ietf.org>; Tue, 05 May 2020 05:13:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+9lv1sMg11f6rH2I1tORoOtVZzEizuKF/T3mI12MZSQ=; b=sJn+cZFTqqioPiYfKqtP9rCsXMfJAlDoE/tnwDudxo9QhNu88BK4rS2MhDEZKMNeBV S8eQ3tVVwIWRgs4SQ42gEz5aIZ7Z8QiRWpjw5ZQ3VQKbYYT4tI2lA6Y3fYseByHrsOvF O+Mmxzr3KrLLfoYKjblu21aYmJfbEJ7Q3ABkYZ7dGPoNeaq97Qulx6N/2t7kztv/ufZJ xZWTglPmFcPWRbh7Uxt4fW9Kr48QXER6EnIeOBPVQVQpD/PohPgZZS2yV3itfXWmW+Gi nDwTBzhCXFGFJ43FWUldoL9DvpV/YBJ/uFQ2GMOsQrAkzvG4GwdfUkDbkiAhadDwziZw N9ww==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+9lv1sMg11f6rH2I1tORoOtVZzEizuKF/T3mI12MZSQ=; b=bF36pZ3l+3KsjzZhXTMhFetZlCEuN2pZh98XuWfptGS280UNxWXm62FKbZ8L0uzP9J e8cT8j5h5e/kxubsN3GxJVlXn3C2ZPIqQ+wFTGNkWcehT03p3vS26GGxuBnYi4CHeZtG pw7qzuPtu7groBIR1zuFTFvP4CmMrv32JqbWJYkVHtfLwqO0Yn+w2uO/7QnmzF2A+XED xgF5PzDZWtMe1casPcQ3X4q+Ut9tj9yE3OgKoVSqalkgZR4Qgtv3aT2hEL7tfjYE0Ive UEh14PQoY3XBizxqR4S1sEYEC1NJTl4z9vxTXRDRe0oud7OZauaotrU8w9o4uydfEzaz +99A==
X-Gm-Message-State: AGi0Pubxq6XKv3jTFx1xbnhobtxt0fwcEIwfKBYQlllAbWozcJitaAa9 VfxoNw85yv0QGeoJANK3Fd8ZHr7Q2tSdnU+Ykw==
X-Google-Smtp-Source: APiQypIyMYNIbvkAG7CPyuGLSkPhkX/eaIG4iQsMSEpNQ8ch38lth2U4j5IVXPZSEG/4SFZhe1ZblbSSTxWd9H1ckaY=
X-Received: by 2002:aed:208c:: with SMTP id 12mr2240622qtb.152.1588680816511; Tue, 05 May 2020 05:13:36 -0700 (PDT)
MIME-Version: 1.0
References: <CAO7v-1Qci+eGHBbQYuHYn-fSb+WA+ac-=Z89zkcdcYpQaKGQEw@mail.gmail.com> <353D4CFD-370C-4509-B7BE-3D572EC2DEFB@dericed.com> <CAO7v-1RqTcC4ty0O-Qk99g_FoRGhyNb_uTDcj6JxcAbM34sscg@mail.gmail.com> <CAOXsMFL7hv=iA7WTnv_FHJSmcOzHspXfF57Xi+PY7BJR5A+nUw@mail.gmail.com> <CAO7v-1QEuW5oQBd5PBq2cD8ZPLU9kjd1L9c8v=KJ2TKMNcJyiQ@mail.gmail.com> <CAOXsMFJVLusiRZpFNCAwkZCA6CjnbYvx06ARopdCPswqBCoVpA@mail.gmail.com> <CAOXsMFJek_HrnhY=Hz_04dV0udCHHQvT5e4LR0AXo6JMXMmeHA@mail.gmail.com>
In-Reply-To: <CAOXsMFJek_HrnhY=Hz_04dV0udCHHQvT5e4LR0AXo6JMXMmeHA@mail.gmail.com>
From: Kieran O Leary <kieran.o.leary@gmail.com>
Date: Tue, 5 May 2020 13:13:27 +0100
Message-ID: <CAO7v-1TgWP+7gBR57S4itW-5qw1OH=xM_M+7ha9Y7D7ZumMhew@mail.gmail.com>
To: Steve Lhomme <slhomme@matroska.org>, Neil Birkbeck <neil.birkbeck@gmail.com>
Cc: Codec Encoding for LossLess Archiving and Realtime transmission <cellar@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000bace4105a4e593b8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cellar/dvEI8FGqMtJ5PKkqEjdPWj3GrcA>
Subject: Re: [Cellar] Mapping of MOV clean aperture values to Matroska
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Codec Encoding for LossLess Archiving and Realtime transmission <cellar.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cellar>, <mailto:cellar-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cellar/>
List-Post: <mailto:cellar@ietf.org>
List-Help: <mailto:cellar-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cellar>, <mailto:cellar-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 May 2020 12:13:40 -0000

Hi all,

I'm not sure if Neil is subscribed to this listserv, but if not - here's
the rest of this thread:
https://mailarchive.ietf.org/arch/browse/cellar/?q=clean%20aperture
Just to flag that Neil Birkbeck is working on adding support to ffmpeg that
will:
map clap values from mov to mov using side data, as well as also mapping
clap values to PixelCrop values within Matroska.
Here's the thread:
http://ffmpeg.org/pipermail/ffmpeg-devel/2020-April/261465.html
Here's my testing - my mail settings are weird at the moment  so I broke
the threading on ffmpeg-devel which is embarrassing - here's my reply:
http://ffmpeg.org/pipermail/ffmpeg-devel/2020-May/262155.html
And seeing as the source mov file as created by Media Express has clap
width values of 41472/59 , this was rounded up to an even 8 pixelcrop on
each side of the image in the MAtroska file, creating a display output of
704/576. Whereas the source mov file would have been displayed as 703/576.
I think that Neil is going to fix this, but I'm wondering if there's some
restriction within PixelCrop so that only even values can be used?
This reply by Neil showed the rounding issue:
http://ffmpeg.org/pipermail/ffmpeg-devel/2020-April/261592.html

Best,

Kieran.



On Mon, Dec 3, 2018 at 7:50 AM Steve Lhomme <slhomme@matroska.org> wrote:

> > >> In Matroska we assume that we override what the codec says.
> > >> But I don't think that's how it's handled in ffmpeg. Also there's the
> > >> question of what these values apply to: on the decoded surface, which
> > >> may include padding on the right/bottom or the area that's supposed to
> > >> be visible. In Matroska the "PixelWidth/PixelHeight" correspond to the
> > >> visible area, on which we apply extra cropping. (this is currently not
> > >> written anywhere).
> > >>
> > >> As for the MOV atom, is there are spec somewhere ? Or is it clear that
> > >> it's some cropping ?
> > >
> > >
> > > I think this is as good of a spec that is freely available - the 'clap
> section'
> https://developer.apple.com/library/archive/documentation/QuickTime/QTFF/QTFFChap3/qtff3.html#//apple_ref/doc/uid/TP40000939-CH205-125850
> >
> > OK, so we should support it in VLC (which we don't) and that seems to
> > map more or less to Matroska values.
>
> I see you submitted a feature request already, excellent
> https://trac.videolan.org/vlc/ticket/21179
>