On Mon, Jun 8, 2020 at 7:19 AM Tobias Rapp wrote:
> On 30.05.2020 12:41, Kieran O Leary wrote:
> > Hi,
> >
> > On Fri 29 May 2020, 22:47 Neil Birkbeck,
> wrote:
> >
> >> [...]
> >> I've changed the side data to be PixelCrop (instead of CleanAperture)
> given
> >> the intent to reuse as cropping
On 30.05.2020 12:41, Kieran O Leary wrote:
Hi,
On Fri 29 May 2020, 22:47 Neil Birkbeck, wrote:
[...]
I've changed the side data to be PixelCrop (instead of CleanAperture) given
the intent to reuse as cropping elsewhere.
-For now, I've kept the rational representation--although CLAP seems to
Hi,
On Fri 29 May 2020, 22:47 Neil Birkbeck, wrote:
> On Mon, May 11, 2020 at 9:37 PM Neil Birkbeck
> wrote:
>
> >
> >
> > On Wed, May 6, 2020 at 8:45 AM James Almer wrote:
> >
> >> On 5/6/2020 12:22 PM, Neil Birkbeck wrote:
> >> > On Tue, May 5, 2020 at 5:11 AM Kieran O Leary <
>
On Mon, May 11, 2020 at 9:37 PM Neil Birkbeck
wrote:
>
>
> On Wed, May 6, 2020 at 8:45 AM James Almer wrote:
>
>> On 5/6/2020 12:22 PM, Neil Birkbeck wrote:
>> > On Tue, May 5, 2020 at 5:11 AM Kieran O Leary > >
>> > wrote:
>> >
>> >> Hi,
>> >>
>> >> I broke the threading with my last reply, i
On Wed, May 6, 2020 at 8:45 AM James Almer wrote:
> On 5/6/2020 12:22 PM, Neil Birkbeck wrote:
> > On Tue, May 5, 2020 at 5:11 AM Kieran O Leary
> > wrote:
> >
> >> Hi,
> >>
> >> I broke the threading with my last reply, i apologise. Here goes another
> >> attempt:
> >>
> >> On Tue, Apr 28,
On Thu, May 7, 2020 at 10:21 AM Andreas Rheinhardt <
andreas.rheinha...@gmail.com> wrote:
> Neil Birkbeck:
> > On Tue, Apr 28, 2020 at 3:18 AM Nicolas George wrote:
> >
> >> Andreas Rheinhardt (12020-04-28):
> >>> That's expected. The patch provided only provides the structure in
> which
> >>>
Neil Birkbeck:
> On Tue, Apr 28, 2020 at 3:18 AM Nicolas George wrote:
>
>> Andreas Rheinhardt (12020-04-28):
>>> That's expected. The patch provided only provides the structure in which
>>> the values are intended to be exported; it does not add any demuxing or
>>> muxing capabilities for mov
Neil Birkbeck:
> On Tue, Apr 28, 2020 at 3:18 AM Nicolas George wrote:
>
>> Andreas Rheinhardt (12020-04-28):
>>> That's expected. The patch provided only provides the structure in which
>>> the values are intended to be exported; it does not add any demuxing or
>>> muxing capabilities for mov
On 5/6/2020 12:22 PM, Neil Birkbeck wrote:
> On Tue, May 5, 2020 at 5:11 AM Kieran O Leary
> wrote:
>
>> Hi,
>>
>> I broke the threading with my last reply, i apologise. Here goes another
>> attempt:
>>
>> On Tue, Apr 28, 2020 at 6:23 PM Neil Birkbeck
>> wrote:
>>
>>> On Tue, Apr 28, 2020 at
On Tue, May 5, 2020 at 5:11 AM Kieran O Leary
wrote:
> Hi,
>
> I broke the threading with my last reply, i apologise. Here goes another
> attempt:
>
> On Tue, Apr 28, 2020 at 6:23 PM Neil Birkbeck
> wrote:
>
> > On Tue, Apr 28, 2020 at 3:18 AM Nicolas George wrote:
> >
> > > Andreas Rheinhardt
Hi,
I broke the threading with my last reply, i apologise. Here goes another
attempt:
On Tue, Apr 28, 2020 at 6:23 PM Neil Birkbeck
wrote:
> On Tue, Apr 28, 2020 at 3:18 AM Nicolas George wrote:
>
> > Andreas Rheinhardt (12020-04-28):
> > > That's expected. The patch provided only provides
Hi Neil,
I have to look deeper into the MKV side of things and most likely raise it
with the cellar mailing list so that better minds than mine can weigh in. I
do see that the rounding up to 704 could be an issue alright.
As for MOV, your patch appears to generate the same output clap values as
On Tue, Apr 28, 2020 at 3:18 AM Nicolas George wrote:
> Andreas Rheinhardt (12020-04-28):
> > That's expected. The patch provided only provides the structure in which
> > the values are intended to be exported; it does not add any demuxing or
> > muxing capabilities for mov or mkv (as you can
Andreas Rheinhardt (12020-04-28):
> That's expected. The patch provided only provides the structure in which
> the values are intended to be exported; it does not add any demuxing or
> muxing capabilities for mov or mkv (as you can see from the fact that
> none of these (de)muxers have been
Kieran O Leary:
> Hi Neil,
>
> Thanks so much for working on this - what was the impetus?
> I started the ticket you mentioned. I applied your patch and tested it with
> the clap.mov file from that ticket. How do I know if behaviour has changed
> with this patch, how should I be testing?
> I
Hi Neil,
Thanks so much for working on this - what was the impetus?
I started the ticket you mentioned. I applied your patch and tested it with
the clap.mov file from that ticket. How do I know if behaviour has changed
with this patch, how should I be testing?
I don't see any reference to the
On Mon, Apr 27, 2020 at 4:38 AM Lynne wrote:
> Apr 27, 2020, 05:27 by neil.birkb...@gmail.com:
>
> > The clean aperature represents a cropping of the stored image data used
> to
> > relate the image data to a canonical video system and exists as container
> > metadata (see 'clap' section in
>
Apr 27, 2020, 05:27 by neil.birkb...@gmail.com:
> The clean aperature represents a cropping of the stored image data used to
> relate the image data to a canonical video system and exists as container
> metadata (see 'clap' section in
>
The clean aperature represents a cropping of the stored image data used to
relate the image data to a canonical video system and exists as container
metadata (see 'clap' section in
https://developer.apple.com/library/archive/documentation/QuickTime/QTFF/QTFFChap3/qtff3.html)
Addition of the side
19 matches
Mail list logo
