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

Kieran O Leary <> Sun, 02 December 2018 16:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B0CC9130EE3 for <>; Sun, 2 Dec 2018 08:18:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.977
X-Spam-Status: No, score=-0.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1Yej2XGFOQ6P for <>; Sun, 2 Dec 2018 08:18:11 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::32e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A81EC130DF5 for <>; Sun, 2 Dec 2018 08:18:10 -0800 (PST)
Received: by with SMTP id m22so3319863wml.3 for <>; Sun, 02 Dec 2018 08:18:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:cc; bh=nIJGggSQ+hlOkiDll+21OWMe+EbcbYiJjFv0hSOPrjQ=; b=lwXJEoTmLs4NLmzz6mvntZUk+sdY+FINWzXvbSjEHjtscXri2NkbW0DnN5JF2ANSy0 BbGI57ViVQKIQ+IeRRFE14Qgt1TnqOL25RCaP9IyBAsORB+spEOa1p9rTIt08ZopMgIc ZBX0dDzorQLAIEecmynqWE4usRwuCMnsd3cWGe2dYv/119eEP4XLXt+gwZWIkJdKwjr9 0AhAjj/15KQbRJ4senEE/J3TxO9IRxsDeqVv8QnDiWyUGiPsH1Q1QOUGkpqMv9fU0L/H qxpx5/4kZOTZY6lP/p8SPIo9vLcdPFUD7INZzY2EW5BCWxJlFsMkb+WPPumiVqNvxyXQ MPJQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:cc; bh=nIJGggSQ+hlOkiDll+21OWMe+EbcbYiJjFv0hSOPrjQ=; b=tUFUZ6TdFdrs6lrf5ok6/CI8JKZCYT2TUinNwofE1UFgjMo3+mopZi1A7/1smMjzQ8 x8dzG/ke6T32CazkOz751PIxXmU3Sk07X/0NwV6b7X2c8HHR4uXB4Z0UL3k4i85Tu10O qHdyHdTt4Dp2rTx7YksTbrRY8gYJr8WyhxjsQqJT5o7YtLWdqzdqdFXu2szJJPfXLSVm p/QqfKHLK04b7Gn/Twrhfdno+2V39Fsrj4SYHSgnXJVbjqpdliqWRz9rXl8QyCDmY0do LiwhWb1QcVjaWHHCK1N/BXIYiYKRVnTflBncFJLzyqHFPMSU9L/tVwFuRGy6hjKjCFT7 1Ysg==
X-Gm-Message-State: AA+aEWaA7YCzklBZPq+TaxOrVkcE2YmGAYndfPoKAWM/XmCR2krQPvb2 RBOg/V6nRGs6glmvZnR4WrDtjYJEN2tuXy6BZeN5zEE=
X-Google-Smtp-Source: AFSGD/W37GGFVmNhESErPgHksxzk+DMenmRw1xj3ZicqtFS868Uei271wCH1Kh2oCEOVOtEz2tmseMAmeQG/VQ1CumQ=
X-Received: by 2002:a1c:6e06:: with SMTP id j6mr5556448wmc.3.1543767488678; Sun, 02 Dec 2018 08:18:08 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Kieran O Leary <>
Date: Sun, 2 Dec 2018 16:17:57 +0000
Message-ID: <>
Content-Type: multipart/alternative; boundary="000000000000c750dd057c0c60c4"
Archived-At: <>
Subject: Re: [Cellar] Mapping of MOV clean aperture values to Matroska
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Codec Encoding for LossLess Archiving and Realtime transmission <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 02 Dec 2018 16:18:13 -0000

Hi Steve,

On Sun, Dec 2, 2018 at 3:44 PM Steve Lhomme <>; wrote:

> Hello,
> For VLC the values are read but they are likely lost along the way to
> the display by the decoder or the video output. You may try this file
> to check if your video output in VLC supports cropping:
> That's pretty cool. ffplay and mpv seem to display the full image, but VLC
displays a crop. At Teasdale in my home Ubuntu 18.04 desktop.

> This illustrates the issue with cropping at the container level (and
> ffmpeg) the container may have some values set but some codecs also
> have such info and may overwrite this value. And there's not really
> any way to tell who is write. It may depend on the codec and the
> container.

I"m mostly familiar with uncompressed video within MOV, which is then
compressed to FFV1/MKV, and in these cases you would only have values in
the container. I hadn't thought of the other codecs that could have
stream-level cropping.

> 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

> Is it in the supposedly visible area or a
> supposedly padded area (which may not correspond in ffmpeg to the
> padding Quicktime would use) ?

Unfortunately I don't fully understand what you mean here by supposedly
visible and padded. PAL video has padded black pillarboxing (i have seen
expections to this) that is not intended to be viewed. These clean aperture
values specify the area that is to be displayed to the viewer. These values
are also essential to generating the correct aspect ratio. If the 720x576
pixels is transformed with a PAR of the PAL standard - 59:54, then you get
786x576 aka 1.364:1, but if the 59:54 value is applied with the clean
aperture values taken into consideration, then you will get the correct 4:3
aspect ratio.


Kieran O'Leary,
Irish FIlm Institute.