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

Steve Lhomme <> Sun, 02 December 2018 15:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 96E1F127B92 for <>; Sun, 2 Dec 2018 07:44:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.358
X-Spam-Status: No, score=-3.358 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UMmMkPZMggm0 for <>; Sun, 2 Dec 2018 07:44:47 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::635]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0BF8012F1AC for <>; Sun, 2 Dec 2018 07:44:46 -0800 (PST)
Received: by with SMTP id b5so5170315plr.4 for <>; Sun, 02 Dec 2018 07:44:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-transfer-encoding; bh=Nujn8Er0/s1L1PWRlLq9wFtwwNuVaU9uAutj7Opw7x8=; b=FUrRz4qgjX5lOETuGLJToBcG+XBfxG1RfOKO7+Um8ULTCSuWMNogJW/atXmERIfAPV sarWZk4oYhqA5pSkFMBRgM89ZfFWCxmZTKYU4KR0rrgzpPw9udjVf+W+3EftVxwdXyVj FoiTPhNOTpZ6FXSkwPCl1M0V7L58J1mQPUo5kFzFJQPKdXnLjvEt7acZ7JGDw72LZR46 Piso3xfiTJpC0nxW6LoXTh4PU8qrLwll4e3ZlcqJ0OI6q6x6jVS8WlEKpFGjLHk+VB1r M5il8lJR2aoXSXuzOIMMwr4D2BjZeQcn0SBftXWnV28/Kmk8U5pHymDUo6JaXqmfyGg3 3fEw==
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:to:content-transfer-encoding; bh=Nujn8Er0/s1L1PWRlLq9wFtwwNuVaU9uAutj7Opw7x8=; b=cAe6VPC6SE/UUePcTffJNYnqeHiJ6+3VeEICrJOCQLpX0A92AKsfL2q6tCOYrxKT0B YfegEVfRh+wYHgpNrRgG6dZ4BFF1JtX3gtYq5v1oqUpMAAeshW6ReYY/HHGdg10IkGMc Isif7lnuEd/kb8ADe2uCZMgW+5I5wgyA4k/5+v9o2ENlSsFKfd8R7RR0c8QHJAzHYmPa 2CqHMex0o88tFO5MgQKSlQY2mpD4yBZ4+TsOTWiGsKvK9OIyX35XQkdQG82XHFoVP2jf gfmuxQfu+C20sipd5fNjlntx8zK2Ix5IYJhHi89CWhC1XoTmTOkJk/2dmP2rgvzEEQIR nSQw==
X-Gm-Message-State: AA+aEWaTos/XjrLn0nZ4GJ6MtX3hWX+sWh4uXXSBN7JtGxxaiSIIZXY/ d5Iw602N2LDd+IzAlauqEu3+n8G5QdU2u3H/koiCCA9kvABrCw==
X-Google-Smtp-Source: AFSGD/V46t+u9sWPwN31UlNog9JWrFXrAYhxODkdqy+HF1ed90XF7HENisrirqpXiGNVMqDXmO/1fGVyQZ8Yoppa8cI=
X-Received: by 2002:a17:902:8a8a:: with SMTP id p10mr12859068plo.50.1543765486015; Sun, 02 Dec 2018 07:44:46 -0800 (PST)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Steve Lhomme <>
Date: Sun, 2 Dec 2018 16:44:35 +0100
Message-ID: <>
To: Codec Encoding for LossLess Archiving and Realtime transmission <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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 15:44:50 -0000


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:

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. 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 ? Is it in the supposedly visible area or a
supposedly padded area (which may not correspond in ffmpeg to the
padding Quicktime would use) ?
Le mar. 27 nov. 2018 à 18:44, Kieran O Leary
<>; a écrit :
> Hey,
> Thanks for replying:
> On Sun, 25 Nov 2018, 20:20 Dave Rice < wrote:
>> Hi Kieran,
>> > On Nov 23, 2018, at 4:56 AM, Kieran O Leary <>; wrote:
>> >
>> > Hi,
>> >
>> > Would I be correct in saying that ideally, Clean Aperture values in a
>> > MOV/MPEG-4 file should map to the PixelCrop element in Matroska?
>> Yes, they conceptually do the same thing but I’m a little confused about how to use the vert/horiz offset fractions of the clap atom to convert to the pixel crop atom. I tried in both QuickTime 7 and X, and while QuickTime X uses the cleanAperature w/h fractions to present a cropped image, QuickTime 7 doesn’t but appears to adjust the aspect ratio according to those values. QuickTime X does seem impacted by non-zero offset values not in a way that I consider coherent. Do you have any examples of un-centered aperatures? I was hoping that IMX files would, does the ones I have don’t use any aperature.
> I don't think I've ever seen non-centered.. but it sounds like Matroska is capable of a mapping,but the actual quicktime implementation sounds inconsistent? I guess this could be specified explicitly by an archivist who will hopefully be able to determine the intended rendering of the original QuickTime file..
> Also it looks like here's yet another related ticket:
>> > I'm asking about this in regards to this ffmpeg ticket -
>> >
>> > As it appears that FFmpeg does not currently read the values in the
>> > clap atom and it also does not map them to Matorksa files when
>> > remuxing. It seems to make the most sense to map them to PixelCrop,
>> > but I'd like to hear it from folks more knowledgable than me.
>> Seems reasonable to me, but I’m not exactly certain what the mapping would be.
> I was considering  doing some experiments with some common PAL scenarios ( crop to 703x576 with a PAR of 59:54, or crop to 704x576 with PAR of 12:11) and using mkvpropedit to insert the metadata. I'll have to look beyond VLC to other players that can display these crops and aspect ratio conversions for the moment.
>> > Another associated issue with the display of these kinds of values is
>> > with VLC as it appears that
>> >
>> > 1) PixelCrop values in Matroska are not supported by VLC at the moment
>> > -
>> > 2) Clean aperture values are not supported by VLC at the moment
>> >
>> Sounds like these tickets are in my priority order as well.
> Cheers,
> Kieran O'Leary,
> Irish Film Institute
>> Dave Rice
> _______________________________________________
> Cellar mailing list

Steve Lhomme
Matroska association Chairman