Re: [FFmpeg-devel] [PATCH v2] mxf : allow using codecs RAWVIDEO and V210 (with more rgb format and correct stored width/height)

[Kieran O Leary]

Woah, can't test this but it would be a brilliant addition to ffmpeg!

Best,

Kieran O'Leary
National Library of Ireland
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avcodec/dpxenc: stop hardcoding color trc/primaries

[Kieran O Leary]

On Fri, Oct 9, 2020 at 12:10 PM Paul B Mahol  wrote:

> On Fri, Oct 09, 2020 at 10:08:45AM +0100, Kieran O Leary wrote:
> > Pinging as I think my comment got lost in the conversation, my main
> concern
> > is about the Printing Density value aka 1,
>
> This patch is for encoder, not for decoder (well decoder also need fixing
> but later).
>
> The meaning of 1 value is same as 0 IMHO.
>

http://www.simplesystems.org/users/bfriesen/dpx/S268M_Revised.pdf
I know it's an older version of the spec but pretty sure new one still has
a value of 1 being Printing Density in tables 5a and 5b.

Best,

Kieran
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avcodec/dpxenc: stop hardcoding color trc/primaries

[Kieran O Leary]

Pinging as I think my comment got lost in the conversation, my main concern
is about the Printing Density value aka 1,

K

On Thu, Oct 8, 2020 at 10:25 AM Kieran O Leary 
wrote:

> Woah, more amazing film preservation patches, thank you!
> From my uninformed reading of the code, does this only support the
> detection of Linear, 709, 240M, 170M, Gamm22?  The reason I ask is that you
> frequently see Printing Density appear as well, which has a value of  '1'
> in the 801/802 offset..
>
> Best,
>
> Kieran O'Leary,
> National Library of Ireland
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avcodec/dpxenc: stop hardcoding color trc/primaries

[Kieran O Leary]

Woah, more amazing film preservation patches, thank you!
From my uninformed reading of the code, does this only support the
detection of Linear, 709, 240M, 170M, Gamm22?  The reason I ask is that you
frequently see Printing Density appear as well, which has a value of  '1'
in the 801/802 offset..

Best,

Kieran O'Leary,
National Library of Ireland
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avcodec: add Cintel RAW decoder

[Kieran O Leary]

Woah, this is unexpected and amazing. Which versions of Cintel RAW does
this support? If I recall correctly, there's a lossy mode, lossless
compression mode and  maybe originally it was uncompressed raw?

Best,

Kieran O'Leary
National Library of Ireland
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Project orientation

[Kieran O Leary]

Hi,

On Thu, Jul 9, 2020 at 1:56 AM Manolis Stamatogiannakis 
wrote:

> On Tue, 7 Jul 2020 at 16:27, Nicolas George  wrote:
>
> > Manolis Stamatogiannakis (12020-07-07):
> > > If I reply to the email, my response will appear online in the issue/PR
> > > page.
> >
> > That is good to know. I have never noticed it documented. Does it work
> > reliably?
> >
> >
> Haven't noticed any glitches so far.
>

Same here, been using email to reply to github issues and pull requests
over the years. The only things i have to watch out for are:
* People can edit their post in a github issue, so the email version you
receive may be outdated as it could be updated on github itself. Perhaps
there's a setting for getting email notifications about updates.
* I usually need to delete the full email quote before replying, as it just
looks ugly and weird on the web client.

-Kieran
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] release/4.3

[Kieran O Leary]

On Tue 9 Jun 2020, 13:21 Michael Niedermayer, 
wrote:

> On Mon, Jun 08, 2020 at 11:55:15PM +0100, Kieran O Leary wrote:
> > hi
> >
> > On Mon, Jun 8, 2020 at 10:17 PM Michael Niedermayer
> 
> > wrote:
> >
> > > Hi
> > >
> > > ive branched release/4.3, will make the 4.3 release from its HEAD in a
> > > few days (maybe a week depending on comments from other developers or
> > > any major issues)
> > >
> > > If theres any issue remaining which you want to work on and
> fix+backport
> > > now is your last chance to get it into 4.3
> > >
> > > Is there any chance that the naming system could be changed for this
> one
> > release so it's 4:3 instead?
>
> thats a funny idea but we would be causing pain with that to anyone trying
> to grep or sort releases
>

Haha yeah, it was just a joke more than anything. Thank you for all your
amazing work on this!

Best,

Kieran O'Leary
Irish Film Institute
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] release/4.3

[Kieran O Leary]

hi

On Mon, Jun 8, 2020 at 10:17 PM Michael Niedermayer 
wrote:

> Hi
>
> ive branched release/4.3, will make the 4.3 release from its HEAD in a
> few days (maybe a week depending on comments from other developers or
> any major issues)
>
> If theres any issue remaining which you want to work on and fix+backport
> now is your last chance to get it into 4.3
>
> Is there any chance that the naming system could be changed for this one
release so it's 4:3 instead?

Best,

Kieran.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v4 2/2] libavcodec/libaomenc.c: Support lossless encoding

[Kieran O Leary]

Hi all - just wondering about the status of this. I was doing some tests
with just -crf 0 with mixed results before I saw this thread.
http://ffmpeg.org/pipermail/ffmpeg-user/2020-June/048885.html

K
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 3/3] lavfi: add basicplay filter.

[Kieran O Leary]

Hi

On Tue 2 Jun 2020, 20:50 Nicolas George,  wrote:

> Paul B Mahol (12020-06-02):
> > No need to reinvent yet another poor synthesizer.
>
> Which is precisely why what I implemented is something well established.
>
> Can somebody give a third opinion please?
>

I doubt my opinion means much but I remember making bad attempts at music
on a commodore 64 and this looks like it would be really fun to play with.

Best,

Kieran
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] libavutil: add clean aperture (CLAP) side data.

[Kieran O Leary]

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 <
> kieran.o.le...@gmail.com
> >> >
> >> > 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 <
> neil.birkb...@gmail.com
> >> >
> >> >> 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 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 changed in the patch).
> >> >>>>
> >> >>>> Which is something I intended to comment on: adding code without
> >> users
> >> >>>> is rarely a good idea. I suggest we do not commit until at least
> one
> >> >>>> demuxer use it, preferably at least two. Otherwise, we may realize
> >> that
> >> >>>> “oh crap, it doesn't work” because of a tiny unforeseen detail.
> >> >>>
> >> >>>
> >> >>> Thanks for the feedback. I also have patches for the demux (MOV/MKV)
> >> and
> >> >>> mux (MOV/MKV).
> >> >>>
> >> >>> As there is still the alternative of using the fields in the
> >> >>> AVCodecParameters/AVCodecContext, my intention was to keep the first
> >> >> patch
> >> >>> small to resolve discussion on that point.
> >> >>>
> >> >>> I've included the patches, if you'd like to try test it, Kieren. I
> >> see on
> >> >>> your test file that there may be some slight rounding error making
> >> output
> >> >>> crop 704 not 703 (MKV file ends up with pixel_crop_{left,right} =
> 8).
> >> >>>
> >> >>> /ffprobe ../testdata/clap.mov 2>&1 | grep -A1 "Side"
> >> >>> Side data:
> >> >>>   Clean aperture:[width 41472/59 height:576/1 h_offset:0/1
> >> >>> v_offset:0/1]
> >> >>> ./ffmpeg -i ../testdata/clap.mov  -vcodec copy -acodec copy
> >> /tmp/clap.mkv
> >> >>> ./ffprobe /tmp/clap.mkv 2>&1 | grep -A1 "Side"
> >> >>> Side data:
> >> >>>   Clean aperture:[width 704/1 height:576/1 h_offset:0/1
> >> v_offset:0/1]
> >> >>>
> >> >>
> >> >> 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
> >> >> the input, so that's really great! command line and mediainfo trace
> >> below:
> >> >>
> >> >
> >> > Thanks for testing, Kieran and for linking the discussion on the
> cellar
> >> > list.
> >> >
> >> > Any additional thoughts from ffmpeg devs on container-level SideData
> vs
> >> > adding the extra fields into AVCodecParameters/AVCodecContext and
> >> plumbing
> >> > into the frame instead? I anticipate some situations where there can
> be
> >> > interaction between cropping in bitstream and container-level
> cropping.
> >> > Maybe the best way forward is for me to share some sample patches for
> >> the
> >> > alternative to validate whether it supports the various use cases
> >> > (transmux, decode+crop, any other application level handling), and to
> >> > confirm the interface changes for

Re: [FFmpeg-devel] [PATCH] libavutil: add clean aperture (CLAP) side data.

[Kieran O Leary]

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 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 changed in the patch).
> >
> > Which is something I intended to comment on: adding code without users
> > is rarely a good idea. I suggest we do not commit until at least one
> > demuxer use it, preferably at least two. Otherwise, we may realize that
> > “oh crap, it doesn't work” because of a tiny unforeseen detail.
>
>
> Thanks for the feedback. I also have patches for the demux (MOV/MKV) and
> mux (MOV/MKV).
>
> As there is still the alternative of using the fields in the
> AVCodecParameters/AVCodecContext, my intention was to keep the first patch
> small to resolve discussion on that point.
>
> I've included the patches, if you'd like to try test it, Kieren. I see on
> your test file that there may be some slight rounding error making output
> crop 704 not 703 (MKV file ends up with pixel_crop_{left,right} = 8).
>
> /ffprobe ../testdata/clap.mov 2>&1 | grep -A1 "Side"
> Side data:
>   Clean aperture:[width 41472/59 height:576/1 h_offset:0/1
> v_offset:0/1]
> ./ffmpeg -i ../testdata/clap.mov  -vcodec copy -acodec copy /tmp/clap.mkv
> ./ffprobe /tmp/clap.mkv 2>&1 | grep -A1 "Side"
> Side data:
>   Clean aperture:[width 704/1 height:576/1 h_offset:0/1 v_offset:0/1]
>

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
the input, so that's really great! command line and mediainfo trace below:
$ ./ffmpeg -i /mnt/c/Users/blaaa/Downloads/clap.mov -c:v v210 newv210.mov
&& mediainfo --Details=1 newv210.mov |grep -i clap -n10
ffmpeg version N-97506-g2fae000994 Copyright (c) 2000-2020 the FFmpeg
developers
  built with gcc 7 (Ubuntu 7.5.0-3ubuntu1~18.04)
  configuration:
  libavutil  56. 43.100 / 56. 43.100
  libavcodec 58. 82.100 / 58. 82.100
  libavformat58. 42.101 / 58. 42.101
  libavdevice58.  9.103 / 58.  9.103
  libavfilter 7. 79.100 /  7. 79.100
  libswscale  5.  6.101 /  5.  6.101
  libswresample   3.  6.100 /  3.  6.100
Guessed Channel Layout for Input Stream #0.1 : stereo
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from
'/mnt/c/Users/blaaa/Downloads/clap.mov':
  Metadata:
major_brand : qt
minor_version   : 537199360
compatible_brands: qt
creation_time   : 2018-09-13T08:48:41.00Z
  Duration: 00:00:01.00, start: 0.00, bitrate: 80686 kb/s
Stream #0:0(eng): Video: v210 (v210 / 0x30313276),
yuv422p10le(smpte170m/bt470bg/bt709, top coded first (swapped)), 720x576,
79626 kb/s, SAR 59:54 DAR 295:216, 9 fps, 25 tbr, 25k tbn, 25k tbc (default)
Metadata:
  creation_time   : 2018-09-13T08:48:41.00Z
  handler_name: ?Apple Video Media Handler
  encoder : Uncompressed 10-Bit YUV
  timecode: 00:00:00:00
Side data:
  Clean aperture:[width 41472/59 height:576/1 h_offset:0/1 v_offset:0/1]
Stream #0:1(eng): Audio: pcm_s24le (in24 / 0x34326E69), 48000 Hz,
stereo, s32 (24 bit), 2304 kb/s (default)
Metadata:
  creation_time   : 2018-09-13T08:48:41.00Z
  handler_name: ?Apple Sound Media Handler
  timecode: 00:00:00:00
Stream #0:2(eng): Data: none (tmcd / 0x64636D74), 0 kb/s (default)
Metadata:
  creation_time   : 2018-09-13T08:48:41.00Z
  handler_name: Time Code Media Handler
  reel_name   : 001
  timecode: 00:00:00:00
File 'newv210.mov' already exists. Overwrite? [y/N] y
Stream mapping:
  Stream #0:0 -> #0:0 (v210 (native) -> v210 (native))
  Stream #0:1 -> #0:1 (pcm_s24le (native) -> aac (native))
Press [q] to stop, [?] for help
Output #0, mov, to 'newv210.mov':
  Metadata:
major_brand : qt
minor_version   : 537199360
compatible_brands: qt
encoder : Lavf58.42.101
Stream #0:0(eng): Video: v210 (v210 / 0x30313276), yuv422p10le(top
coded first (swapped)), 720x576 [SAR 59:54 DAR 295:216], q=2-31, 221184
kb/s, 0.04 fps, 12800 tbn, 25 tbc (default)
Metadata:
  creation_time   : 2018-09-13T08:48:41.00Z
  handler_name: ?Apple Video Media Handler
  timecode: 00:00:00:00
  encoder : Lavc58.82.100 v210
Side data:
  Clean aperture:[width 41472/59 height:576/1 h_offset:0/1 v_offset:0/1]
Stream #0:1(eng): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz,
stereo, fltp (24 bit), 128 kb/s (default)
Metadata:
  

Re: [FFmpeg-devel] [PATCH] libavutil: add clean aperture (CLAP) side data.

[Kieran O Leary]

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
the input, so that's really great! command line and mediainfo trace below:
$ ./ffmpeg -i /mnt/c/Users/blaaa/Downloads/clap.mov -c:v v210 newv210.mov
&& mediainfo --Details=1 newv210.mov |grep -i clap -n10
ffmpeg version N-97506-g2fae000994 Copyright (c) 2000-2020 the FFmpeg
developers
  built with gcc 7 (Ubuntu 7.5.0-3ubuntu1~18.04)
  configuration:
  libavutil  56. 43.100 / 56. 43.100
  libavcodec 58. 82.100 / 58. 82.100
  libavformat58. 42.101 / 58. 42.101
  libavdevice58.  9.103 / 58.  9.103
  libavfilter 7. 79.100 /  7. 79.100
  libswscale  5.  6.101 /  5.  6.101
  libswresample   3.  6.100 /  3.  6.100
Guessed Channel Layout for Input Stream #0.1 : stereo
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from
'/mnt/c/Users/blaaa/Downloads/clap.mov':
  Metadata:
major_brand : qt
minor_version   : 537199360
compatible_brands: qt
creation_time   : 2018-09-13T08:48:41.00Z
  Duration: 00:00:01.00, start: 0.00, bitrate: 80686 kb/s
Stream #0:0(eng): Video: v210 (v210 / 0x30313276),
yuv422p10le(smpte170m/bt470bg/bt709, top coded first (swapped)), 720x576,
79626 kb/s, SAR 59:54 DAR 295:216, 9 fps, 25 tbr, 25k tbn, 25k tbc (default)
Metadata:
  creation_time   : 2018-09-13T08:48:41.00Z
  handler_name: ?Apple Video Media Handler
  encoder : Uncompressed 10-Bit YUV
  timecode: 00:00:00:00
Side data:
  Clean aperture:[width 41472/59 height:576/1 h_offset:0/1 v_offset:0/1]
Stream #0:1(eng): Audio: pcm_s24le (in24 / 0x34326E69), 48000 Hz,
stereo, s32 (24 bit), 2304 kb/s (default)
Metadata:
  creation_time   : 2018-09-13T08:48:41.00Z
  handler_name: ?Apple Sound Media Handler
  timecode: 00:00:00:00
Stream #0:2(eng): Data: none (tmcd / 0x64636D74), 0 kb/s (default)
Metadata:
  creation_time   : 2018-09-13T08:48:41.00Z
  handler_name: Time Code Media Handler
  reel_name   : 001
  timecode: 00:00:00:00
File 'newv210.mov' already exists. Overwrite? [y/N] y
Stream mapping:
  Stream #0:0 -> #0:0 (v210 (native) -> v210 (native))
  Stream #0:1 -> #0:1 (pcm_s24le (native) -> aac (native))
Press [q] to stop, [?] for help
Output #0, mov, to 'newv210.mov':
  Metadata:
major_brand : qt
minor_version   : 537199360
compatible_brands: qt
encoder : Lavf58.42.101
Stream #0:0(eng): Video: v210 (v210 / 0x30313276), yuv422p10le(top
coded first (swapped)), 720x576 [SAR 59:54 DAR 295:216], q=2-31, 221184
kb/s, 0.04 fps, 12800 tbn, 25 tbc (default)
Metadata:
  creation_time   : 2018-09-13T08:48:41.00Z
  handler_name: ?Apple Video Media Handler
  timecode: 00:00:00:00
  encoder : Lavc58.82.100 v210
Side data:
  Clean aperture:[width 41472/59 height:576/1 h_offset:0/1 v_offset:0/1]
Stream #0:1(eng): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz,
stereo, fltp (24 bit), 128 kb/s (default)
Metadata:
  creation_time   : 2018-09-13T08:48:41.00Z
  handler_name: ?Apple Sound Media Handler
  timecode: 00:00:00:00
  encoder : Lavc58.82.100 aac
frame=   25 fps=0.0 q=-0.0 Lsize=   27009kB time=00:00:00.96
bitrate=230455.2kbits/s dup=16 drop=0 speed=19.8x
video:27000kB audio:6kB subtitle:0kB other streams:0kB global headers:0kB
muxing overhead: 0.008794%
[aac @ 0x7fffe91cc680] Qavg: 171.537
226-1A5FBA4 detail: 9 (0x09)
227-1A5FBA5Pixel Aspect Ratio (16 bytes)
228-1A5FBA5 Header (8 bytes)
229-1A5FBA5  Size:  16 (0x0010)
230-1A5FBA9  Name:  pasp
231-1A5FBAD hSpacing:   59 (0x003B)
232-1A5FBB1 vSpacing:   54 (0x0036)
233-1A5FBB5Clean Aperture (40 bytes)
234-1A5FBB5 Header (8 bytes)
235-1A5FBB5  Size:  40 (0x0028)
236:1A5FBB9  Name:  clap
237-1A5FBBD apertureWidth_N:41472 (0xA200)
238-1A5FBC1 apertureWidth_D:59 (0x003B)
239-1A5FBC5 apertureHeight_N:   576 (0x0240)
240-1A5FBC9 apertureHeight_D:   1 (0x0001)
241-1A5FBCD horizOff_N: 0 (0x)
242-1A5FBD1 horizOff_D: 1 (0x0001)
243-1A5FBD5 vertOff_N:  0 (0x)
244-1A5FBD9 vertOff_D:  1 (0x0001)
245-1A5FBDD  Time to Sample (24 bytes)
246-1A5FBDD   Header (8 bytes)


and here's similar info for mkv:

 ./ffmpeg -i 

Re: [FFmpeg-devel] [PATCH] libavutil: add clean aperture (CLAP) side data.

[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 don't see any reference to the clap atom values when transcoding the file
to MKV or to another mov:

./ffmpeg -i /mnt/c/Users/kieran.oleary/Downloads/clap.mov out.mkv
ffmpeg version N-97506-g2fae000994 Copyright (c) 2000-2020 the FFmpeg
developers
  built with gcc 7 (Ubuntu 7.5.0-3ubuntu1~18.04)
  configuration:
  libavutil  56. 43.100 / 56. 43.100
  libavcodec 58. 82.100 / 58. 82.100
  libavformat58. 42.101 / 58. 42.101
  libavdevice58.  9.103 / 58.  9.103
  libavfilter 7. 79.100 /  7. 79.100
  libswscale  5.  6.101 /  5.  6.101
  libswresample   3.  6.100 /  3.  6.100
Guessed Channel Layout for Input Stream #0.1 : stereo
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from
'/mnt/c/Users/kieran.oleary/Downloads/clap.mov':
  Metadata:
major_brand : qt
minor_version   : 537199360
compatible_brands: qt
creation_time   : 2018-09-13T08:48:41.00Z
  Duration: 00:00:01.00, start: 0.00, bitrate: 80686 kb/s
Stream #0:0(eng): Video: v210 (v210 / 0x30313276),
yuv422p10le(smpte170m/bt470bg/bt709, top coded first (swapped)), 720x576,
79626 kb/s, SAR 59:54 DAR 295:216, 9 fps, 25 tbr, 25k tbn, 25k tbc (default)
Metadata:
  creation_time   : 2018-09-13T08:48:41.00Z
  handler_name: ?Apple Video Media Handler
  encoder : Uncompressed 10-Bit YUV
  timecode: 00:00:00:00
Stream #0:1(eng): Audio: pcm_s24le (in24 / 0x34326E69), 48000 Hz,
stereo, s32 (24 bit), 2304 kb/s (default)
Metadata:
  creation_time   : 2018-09-13T08:48:41.00Z
  handler_name: ?Apple Sound Media Handler
  timecode: 00:00:00:00
Stream #0:2(eng): Data: none (tmcd / 0x64636D74), 0 kb/s (default)
Metadata:
  creation_time   : 2018-09-13T08:48:41.00Z
  handler_name: Time Code Media Handler
  reel_name   : 001
  timecode: 00:00:00:00
File 'out.mkv' already exists. Overwrite? [y/N] y
Stream mapping:
  Stream #0:0 -> #0:0 (v210 (native) -> mpeg4 (native))
  Stream #0:1 -> #0:1 (pcm_s24le (native) -> ac3 (native))
Press [q] to stop, [?] for help
Output #0, matroska, to 'out.mkv':
  Metadata:
major_brand : qt
minor_version   : 537199360
compatible_brands: qt
encoder : Lavf58.42.101
Stream #0:0(eng): Video: mpeg4 (FMP4 / 0x34504D46), yuv420p(top coded
first (swapped)), 720x576 [SAR 59:54 DAR 295:216], q=2-31, 200 kb/s, 25
fps, 1k tbn, 25 tbc (default)
Metadata:
  creation_time   : 2018-09-13T08:48:41.00Z
  handler_name: ?Apple Video Media Handler
  timecode: 00:00:00:00
  encoder : Lavc58.82.100 mpeg4
Side data:
  cpb: bitrate max/min/avg: 0/0/20 buffer size: 0 vbv_delay: N/A
Stream #0:1(eng): Audio: ac3 ([0] [0][0] / 0x2000), 48000 Hz, stereo,
fltp (24 bit), 192 kb/s (default)
Metadata:
  creation_time   : 2018-09-13T08:48:41.00Z
  handler_name: ?Apple Sound Media Handler
  timecode: 00:00:00:00
  encoder : Lavc58.82.100 ac3
frame=9 fps=0.0 q=1.6 Lsize=  36kB time=00:00:00.41 bitrate=
717.1kbits/s speed=9.05x
video:25kB audio:10kB subtitle:0kB other streams:0kB global headers:0kB
muxing overhead: 3.596637%
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC PATCH v2] libavcodec/jpeg2000_parser: Add jpeg2000 parser

[Kieran O Leary]

Hi,

Forgive my ignorance ,but what is the difference between a parser and a
decoder in this context? What does this parser add that wasn't covered in
the decoder?

Best,

Kieran O'Leary
Irish Film Institute
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] FFmpeg developer meeting 2019/12/9 notes

[Kieran O Leary]

These notes are really helpful, I hope they continue for future meetings!

Best,

Kieran
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avcodec/ffv1enc: Use version 3 by default (CRCs by default)

[Kieran O Leary]

On Sun, 8 Dec 2019, 22:50 Michael Niedermayer, 
wrote:

> Version 3 is since 2013 (FFmpeg 2.1) non experimental so should be widely
> supported
>

This was recently raised at the No Time To Wait conference in Budapest, so
it would be great to see version three as the default!

Best,

Kieran O'Leary
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Ableton live aiff file

[Kieran O Leary]

On Fri, 20 Sep 2019, 08:58 Adam Johnson,  wrote:

> I have some aiff files in my music production library that I'd like to
> convert to flac. However they aren't recognized by ffmpeg:
>
> $ ffmpeg -i Raylon-190-Full.aif
> ...
> [aiff @ 0x7fc3ce80] unknown or unsupported codec tag: able is not
> implemented. Update your FFmpeg version to the newest one from Git. If the
> problem still occurs, it means that your file has a feature which has not
> been implemented.
> [aiff @ 0x7fc3ce80] If you want to help, upload a sample of this file
> to ftp://upload.ffmpeg.org/incoming/ and contact the ffmpeg-devel mailing
> list. (ffmpeg-devel@ffmpeg.org)
> [aiff @ 0x7fc3ce80] could not find COMM tag or invalid block_align
> value
> Raylon-190-Full.aif: Operation not permitted
>
> These files can only be decoded by Ableton Live. Quicktime, VLC, MPlayer,
> and ffmpeg can't read them. I believe the 'able' tag is Ableton's
> proprietary format. I know it's 24 bit but no more.
>
> I exported one through Ableton to a 44.1khz 24 bit wav and the filesize
> comes out exactly the same so I know the format is not compressed. Also the
> exported wav matches the waveform precisely since if I add it back  with
> inverted phase I hear nothing.
>
> Here is a sample file, in aif format and wav format:
>
> https://files-adamj-eu.s3.amazonaws.com/ffmpeg-devel/Raylon-190-Full.aif
> https://files-adamj-eu.s3.amazonaws.com/ffmpeg-devel/Raylon-190-Full.wav


This list is for posting patches,you should post on ffmpeg-user instead. It
might make sense to also post an aiff output if possible via Ableton. I
wasn't clear from your post of the aiff file was an export from Ableton, or
raw capture files stores in a working directory.

Best,

Kieran.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] blended telecine... possible?

[Kieran O Leary]

Hi,

On Wed, 4 Sep 2019, 04:09 Mark Filipak, <
markfilipak.windows+ffm...@gmail.com> wrote:

> No one has responded. What does that indicate? Lack of interest? Lack of
> knowledge? Lack of time? Shunning of anyone who's not a current developer?
>

You didn't wait very long for a reply, also you wrote to the development
list which is purely for posting patches/new code. You should write to
ffmpeg-user instead.

Best,

Kieran
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avformat/mov: improve timecode calculation

[Kieran O Leary]

On Thu, 22 Aug 2019, 17:18 Paul B Mahol,  wrote:

> Hi,
>
> patch attached.
>


Maybe it's a Gmail issue but I see no attachment. Also for those of us
unable to understand the code,what's the improvement?

Best,

Kieran

>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 0/1] Parsing quicktime tracks in matroska containers

[Kieran O Leary]

On Tue, 13 Aug 2019, 20:25 Stanislav Ionascu, 
wrote:

> Hi All,
>
> when remuxing some of the mp4 files into the mkv container, not all
> video codecs can be properly represented.


Purely out of curiosity, what other codes does this affect?

Best,

Kieran O'Leary
Irish Film Institute
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] avcodec/proresenc_aw : add interlace encoding support

[Kieran O Leary]

Hi, can this be merged or is more rigourous testing necessary?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] lavc/libvpxenc: Deprecate lossless option

[Kieran O Leary]

On Sat, 9 Feb 2019, 06:49 Gyan 
>
> On 09-02-2019 02:26 AM, Carl Eugen Hoyos wrote:
> > 2019-02-08 6:08 GMT+01:00, Gyan :
> >>
> >> On 08-02-2019 03:31 AM, Carl Eugen Hoyos wrote:
> >>> .
> >>> No strong opinion here, I hadn't realized that -crf 0 only works with
> >>> newer versions.
> >>>
> >>> Can you explain why crf alone has no effect and needs -b:v 0?
> >>> Isn't this a bug both with libvpx and libaom?
> >>>
> >> With crf present but VBV params absent, VPX operates using a constrained
> >> Q RC mode , where the target bitrate acts as a ceiling. Since acvodec
> >> has a non-zero default -b of 200 kbps, this produces undesirable
> >> effects. If set to 0, VPX switches to constant quality.
> > Yes.
> > This looks like a bug to me.
> If there's a bug, it's in libav, in that, we can't signal when a value
> is assigned by the user or via user-initiated logic, versus being
> assigned as a default fallback. So it's a design conflict, and the
> workaround has been long documented.
>
> Maybe just before the next major bump, a new field should be introduced
> in AVOptions which registers if the field was populated at the behest of
> the user.
> >> I do see this block though,
> >>
> >>   if (avctx->codec_id == AV_CODEC_ID_VP9 && ctx->lossless == 1) {
> >>   enccfg.rc_min_quantizer =
> >>   enccfg.rc_max_quantizer = 0;
> >>   } else {
> >>   if (avctx->qmin >= 0)
> >>   enccfg.rc_min_quantizer = avctx->qmin;
> >>   if (avctx->qmax >= 0)
> >>   enccfg.rc_max_quantizer = avctx->qmax;
> >>   }
> >>
> >>
> >> Looks like the quantizer range is disabled only by using the deprecated
> >> option, or has this changed?
> > Is your question "Isn't 'lossless 1' necessary for lossless encoding"?
> Yes. A quick glance at vpx HEAD indicates it is, although -qmin & -qmax
> 0 should also work.
>
> >> Also, with libvpx v1.7.0-1758, I get different results for -crf 0 -b:v
> >> 0  vs only -lossless 1, with the latter producing a slightly larger
> >> file, and its result showing a slightly larger SSIM score. Although
> >> neither produces a SSIM of 1, like libx264. Not truly lossless?
> > Please provide your input sample.
> I can reproduce the difference in result with
> fate-suite/h264-conformance/src19td.IBP.264
>
> although the `-lossless 1` encoding does return as lossless in SSIM.
>

What ssim command did you use, and why use this over a hash muxer like
framehash? I'm always on the lookout for losslessness verification methods.

Best,

Kieran
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] avcodec/proresenc_aw : add interlace encoding support

[Kieran O Leary]

On Sun, 10 Feb 2019, 11:57 Martin Vignali  Hello,
>
> >
> > > Use +ildct flag to switch between progressive and interlace encoding
> > >
> > > Use AVFrame flag to switch between tff and bff frame organization.
> > >
> >
> > Is this what you mean by altering the -setparams filter?
> >
> > In order to choose between top field first and bottom field first, i use
> the AVFrame property (interlaced, and top_field_first)
> (these property can be set using setparams filter using field_mode (so
> setparams make a more predictable result of field order (and color property
> (if set) at the same time))
>
>
> > > If AVFrame->interlaced value is not set to 1, but +ildct is set
> > (interlace
> > > encoding of progressive frame), define field order to top (most common
> > case
> > > for prores file)
> > >
> >
> > It appears that prores_ks defaults to BFF?
> >
>
> Following source code of prores_ks, i think prores_ks, doesn't really make
> a choice for interlace encoding of not interlace content
> it test for top field first property, if not set define to bottom (but
> doesn't check the interlaced flag before)
> Make more sense to me to convert progressive content to top field first.
>

I've no preference,I was just curious why there was a difference. Thanks
again for adding this. It will be very useful for those of us still dealing
with PAL/NTSC.

Best,

Kieran
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] avcodec/proresenc_aw : add interlace encoding support

[Kieran O Leary]

Hi,

On Sat, Feb 9, 2019 at 6:10 PM Martin Vignali 
wrote:

> Hello,
>
> Patchs in attach add interlace encoding support to prores aw encoding
>

Thanks so much for adding this. I can really only judge by the metadata for
now, but this all looks good to me (ffmpeg encode and mediainfo check):

$ ./ffmpeg -f lavfi -i testsrc -field_order tt -flags ildct -c:v prores_aw
-t 10 tt_ildct_aw.mov && mediainfo tt_ildct_aw.mov |grep -i scan
ffmpeg version N-93103-gd20902fd23 Copyright (c) 2000-2019 the FFmpeg
developers
  built with gcc 7 (Ubuntu 7.3.0-27ubuntu1~18.04)
  configuration:
  libavutil  56. 26.100 / 56. 26.100
  libavcodec 58. 47.100 / 58. 47.100
  libavformat58. 26.101 / 58. 26.101
  libavdevice58.  6.101 / 58.  6.101
  libavfilter 7. 48.100 /  7. 48.100
  libswscale  5.  4.100 /  5.  4.100
  libswresample   3.  4.100 /  3.  4.100
Input #0, lavfi, from 'testsrc':
  Duration: N/A, start: 0.00, bitrate: N/A
Stream #0:0: Video: rawvideo (RGB[24] / 0x18424752), rgb24, 320x240
[SAR 1:1 DAR 4:3], 25 tbr, 25 tbn, 25 tbc
File 'tt_ildct_aw.mov' already exists. Overwrite ? [y/N] y
Stream mapping:
  Stream #0:0 -> #0:0 (rawvideo (native) -> prores (prores_aw))
Press [q] to stop, [?] for help
[prores_aw @ 0x55b56f330c80] encoding with ProRes  (ap4h) profile
[prores_aw @ 0x55b56f334180] encoding with ProRes  (ap4h) profile
[prores_aw @ 0x55b56f337580] encoding with ProRes  (ap4h) profile
[prores_aw @ 0x55b56f33aa00] encoding with ProRes  (ap4h) profile
[prores_aw @ 0x55b56f305ec0] encoding with ProRes  (ap4h) profile
Output #0, mov, to 'tt_ildct_aw.mov':
  Metadata:
encoder : Lavf58.26.101
Stream #0:0: Video: prores (prores_aw) () (ap4h / 0x68347061),
yuv444p10le(top first), 320x240 [SAR 1:1 DAR 4:3], q=2-31, 200 kb/s, 25
fps, 12800 tbn, 25 tbc
Metadata:
  encoder : Lavc58.47.100 prores_aw
frame=  250 fps=0.0 q=-0.0 Lsize=   10145kB time=00:00:09.96
bitrate=8344.2kbits/s speed=26.8x
video:10143kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB
muxing overhead: 0.017619%
Scan type: Interlaced
Scan type, store method  : Separated fields (2 fields per
block)
Scan order   : Top Field First



>
> Use +ildct flag to switch between progressive and interlace encoding
>
> Use AVFrame flag to switch between tff and bff frame organization.
>

Is this what you mean by altering the -setparams filter?


> If AVFrame->interlaced value is not set to 1, but +ildct is set (interlace
> encoding of progressive frame), define field order to top (most common case
> for prores file)
>

It appears that prores_ks defaults to BFF?

$ ./ffmpeg -f lavfi -i testsrc  -flags ildct -c:v prores_ks -t 10
ildct_ks.mov && mediainfo ildct_ks.mov |grep -i scan
ffmpeg version N-93103-gd20902fd23 Copyright (c) 2000-2019 the FFmpeg
developers
  built with gcc 7 (Ubuntu 7.3.0-27ubuntu1~18.04)
  configuration:
  libavutil  56. 26.100 / 56. 26.100
  libavcodec 58. 47.100 / 58. 47.100
  libavformat58. 26.101 / 58. 26.101
  libavdevice58.  6.101 / 58.  6.101
  libavfilter 7. 48.100 /  7. 48.100
  libswscale  5.  4.100 /  5.  4.100
  libswresample   3.  4.100 /  3.  4.100
Input #0, lavfi, from 'testsrc':
  Duration: N/A, start: 0.00, bitrate: N/A
Stream #0:0: Video: rawvideo (RGB[24] / 0x18424752), rgb24, 320x240
[SAR 1:1 DAR 4:3], 25 tbr, 25 tbn, 25 tbc
File 'ildct_ks.mov' already exists. Overwrite ? [y/N] y
Stream mapping:
  Stream #0:0 -> #0:0 (rawvideo (native) -> prores (prores_ks))
Press [q] to stop, [?] for help
[prores_ks @ 0x557a246a5f80] Autoselected 4:4:4:4 profile because of the
used input colorspace. It can be overridden through -profile option.
[prores_ks @ 0x557a246b0e00] Autoselected 4:4:4:4 profile because of the
used input colorspace. It can be overridden through -profile option.
[prores_ks @ 0x557a246bbdc0] Autoselected 4:4:4:4 profile because of the
used input colorspace. It can be overridden through -profile option.
[prores_ks @ 0x557a246c6e40] Autoselected 4:4:4:4 profile because of the
used input colorspace. It can be overridden through -profile option.
[prores_ks @ 0x557a24677d80] Autoselected 4:4:4:4 profile because of the
used input colorspace. It can be overridden through -profile option.
Output #0, mov, to 'ildct_ks.mov':
  Metadata:
encoder : Lavf58.26.101
Stream #0:0: Video: prores (prores_ks) (ap4h / 0x68347061),
yuv444p10le, 320x240 [SAR 1:1 DAR 4:3], q=2-31, 200 kb/s, 25 fps, 12800
tbn, 25 tbc
Metadata:
  encoder : Lavc58.47.100 prores_ks
frame=   72 fps=0.0 q=-0.0 size=2816kB time=00:00:02.68
bitrate=8607.6kbits/frame=  144 fps=144 q=-0.0 size=5632kB
time=00:00:05.56 bitrate=8298.0kbits/frame=  216 fps=144 q=-0.0 size=
8704kB time=00:00:08.44 bitrate=8448.2kbits/frame=  250 fps=141 q=-0.0
Lsize=   10434kB time=00:00:09.96 bitrate=8582.2kbits/s speed=5.63x
video:10433kB audio:0kB 

Re: [FFmpeg-devel] [PATCH] img2enc: mention -frames:v in error message

[Kieran O Leary]

On Tue, 15 Jan 2019, 00:25 Lou Logan  Signed-off-by: Lou Logan 
> ---
>  libavformat/img2enc.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/libavformat/img2enc.c b/libavformat/img2enc.c
> index a09cc8ec50..bec4bf81dd 100644
> --- a/libavformat/img2enc.c
> +++ b/libavformat/img2enc.c
> @@ -110,7 +110,8 @@ static int write_packet(AVFormatContext *s, AVPacket
> *pkt)
>
>  AV_FRAME_FILENAME_FLAGS_MULTIPLE) < 0 &&
> img->img_number > 1) {
>  av_log(s, AV_LOG_ERROR,
> -   "Could not get frame filename number %d from pattern
> '%s' (either set update or use a pattern like %%03d within the filename
> pattern)\n",
> +   "Could not get frame filename number %d from pattern
> '%s'. "
> +   "Use '-frames:v 1' for a single image, or '-update'
> option, or use a pattern such as %%03d within the filename.\n",
>

Looks good to me. The adding of a dash is useful as my colleagues and I
have seen that error many times and I never really new what 'set update'
meant. I only now looked up -update in the documentation.

-Kieran

img->img_number, img->path);
>  return AVERROR(EINVAL);
>  }
> --
> 2.20.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] doc/developer: require transparency about sponshorships.

[Kieran O Leary]

On Sun, 13 Jan 2019, 15:57 Nicolas George  James Almer (12019-01-13):
> > And kill the project by reducing development speed to crawl? Unreviewed
>
> That is indeed the problem.
>
> > and unchallenged patches by long time devs with commit rights can and
> > will still be pushed after enough time and ping attempts have been made.
> > Expecting anything else will take ffmpeg through the same road libav
> > found itself in.
> > Bad commits that were ignored but noticed after the fact have been
> > reverted in the past. They will inevitably crash under the weight of its
> > own crappiness. That will not change.
> >
> > Rewrite this patch, make it palatable, and then the rest of the project
> > will consider it. Stop wasting your and everyone's time by insisting on
> > a patch everyone NAKed.
>
> You keep saying that, but you waltz around the problem. So let me state
> it plainly:
>
> If there is somebody (1) who repeatedly pushes patches without review
> (because it is new code or because it is over code that they maintain by
> self-appointment), (2) whose patches frequently cause regressions, some
> of them detected by Coverity, (3) when they get a review and it requires
> more work from them, are rude and unhelpful, and possibly ignore the
> comments, (4) as a result from that rudeness receive even less reviews,
> and (5) all this seems to be motivated by sponsorship, can you tell what
> course of action you propose?
>

How would declaring the sponsorship help in this regard,when the real issue
is your points 1 to 4?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Transparency of sponsored works (was: avcodec: add photocd decoder)

[Kieran O Leary]

On Fri, 11 Jan 2019, 15:31 Nicolas George  Carl Eugen Hoyos (12019-01-11):
> > I believe amount is never published (so far at least afair).
>
> I think it should. I wonder what other people think.
>

I don't see why this declaration is helpful or necessary in any way. Can
you elaborate on why it is?

Best,

Kieran
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] avcodec/proresaw_enc : improvment (vendor and color properties, 4444Xq)

[Kieran O Leary]

On Mon, Nov 26, 2018 at 8:06 AM Kieran O Leary 
wrote:

>
>
> On Sat, 24 Nov 2018, 22:11 Martin Vignali 
>> Hello,
>>
>> Patch in attach add some improvments to prores aw encoder
>>
>> 012 : Add vendor option (code come from prores_ks encoder)
>> 013 : Only write color properties, if defined in rdd36 (other values are
>> "converted" to unspecified)
>> 014 : Add  XQ encoding support
>>
>
> I hope to test these patches out today with 12-bit RGB DPX/FFV1 as input.
> Is the  XQ encoder intended to be 10 or 12-bit?
>

So I applied these patches and it appears that ffmpeg will encode XQ as
10-bit, but it will decode as 12-bit. Is this intentional? I worry that I
might have applied the patches incorrectly.  And is it possible to add
12-bit encoding?

$ ./ffmpeg -f lavfi -i testsrc -c:v prores -profile:v 5 xq.mov

ffmpeg version N-92541-g598755603c Copyright (c) 2000-2018 the FFmpeg
developers

  built with Apple LLVM version 9.0.0 (clang-900.0.39.2)

  configuration:

  libavutil  56. 24.101 / 56. 24.101

  libavcodec 58. 40.100 / 58. 40.100

  libavformat58. 23.100 / 58. 23.100

  libavdevice58.  6.100 / 58.  6.100

  libavfilter 7. 46.100 /  7. 46.100

  libswscale  5.  4.100 /  5.  4.100

  libswresample   3.  4.100 /  3.  4.100

Input #0, lavfi, from 'testsrc':

  Duration: N/A, start: 0.00, bitrate: N/A

Stream #0:0: Video: rawvideo (RGB[24] / 0x18424752), rgb24, 320x240
[SAR 1:1 DAR 4:3], 25 tbr, 25 tbn, 25 tbc

File 'xq.mov' already exists. Overwrite ? [y/N] y

Stream mapping:

  Stream #0:0 -> #0:0 (rawvideo (native) -> prores (native))

Press [q] to stop, [?] for help

Output #0, mov, to 'xq.mov':

  Metadata:

encoder : Lavf58.23.100

Stream #0:0: Video: prores (XQ) (ap4x / 0x78347061), yuv444p10le,
320x240 [SAR 1:1 DAR 4:3], q=2-31, 200 kb/s, 25 fps, 12800 tbn, 25 tbc

Metadata:

  encoder : Lavc58.40.100 prores

frame=14747 fps=2015 q=-0.0 Lsize=  469689kB time=00:09:49.84
bitrate=6523.3kbits/s speed=80.6x

video:469627kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB
muxing overhead: 0.013138%

Exiting normally, received signal 2.

telecine:ffmpeg administrator$ ./ffmpeg -i xq.mov

ffmpeg version N-92541-g598755603c Copyright (c) 2000-2018 the FFmpeg
developers

  built with Apple LLVM version 9.0.0 (clang-900.0.39.2)

  configuration:

  libavutil  56. 24.101 / 56. 24.101

  libavcodec 58. 40.100 / 58. 40.100

  libavformat58. 23.100 / 58. 23.100

  libavdevice58.  6.100 / 58.  6.100

  libavfilter 7. 46.100 /  7. 46.100

  libswscale  5.  4.100 /  5.  4.100

  libswresample   3.  4.100 /  3.  4.100

Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'xq.mov':

  Metadata:

major_brand : qt

minor_version   : 512

compatible_brands: qt

encoder : Lavf58.23.100

  Duration: 00:09:49.88, start: 0.00, bitrate: 6522 kb/s

Stream #0:0(eng): Video: prores (XQ) (ap4x / 0x78347061),
yuv444p12le(tv, progressive), 320x240, 6521 kb/s, SAR 1:1 DAR 4:3, 25 fps,
25 tbr, 12800 tbn, 12800 tbc (default)

Metadata:

  handler_name: VideoHandler
  encoder : Lavc58.40.100 prores


Best,

Kieran.

>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] avcodec/proresaw_enc : improvment (vendor and color properties, 4444Xq)

[Kieran O Leary]

On Sat, 24 Nov 2018, 22:11 Martin Vignali  Hello,
>
> Patch in attach add some improvments to prores aw encoder
>
> 012 : Add vendor option (code come from prores_ks encoder)
> 013 : Only write color properties, if defined in rdd36 (other values are
> "converted" to unspecified)
> 014 : Add  XQ encoding support
>

I hope to test these patches out today with 12-bit RGB DPX/FFV1 as input.
Is the  XQ encoder intended to be 10 or 12-bit?

Kieran.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] avcodec/proresdec : add 12b decoding support

[Kieran O Leary]

On Sun, 18 Nov 2018, 21:58 Martin Vignali 
> I don't know, how to get the "wanted" pix_fmt output using ffmpeg cli, and
> I don't know, what the general "rules" of this project for multiple pix_fmt
> output for the same input file.
>
> If user option for decoding precision need to be remove,
> i think 422 need to stay in 10b decoding, and 444 need to be decode in 12b.
>

What happens if a 10-bit 444 file is decoded with 12-bit precision? Is this
just a resampling up to 12-bit for no real benefit?

-Kieran
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] avcodec/proresdec : add 12b decoding support

[Kieran O Leary]

Hi

On Sat, 17 Nov 2018, 23:28 Martin Vignali  Hello,
>
> Patchs in attach add 12b decoding for prores
> Theses patch are based on patch by Kieran Kunhya
> https://pastebin.com/mYNJkdMH
>
> After theses patch by default Prores 422 are decode in 10b and 444 in 12b
> I add a user option, to force 10b or 12b decoding
>

Are all 444(4?) Encodings 12-bit? Also is there a way to verify if your
file should be decoded as 10 or 12-bit? Or does this code automate this
detection?

This all looks very cool.

Thanks,

Kieran O Leary
Irish Film Institute
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] web/documentation: add new book about FFmpeg in China

[Kieran O Leary]

On Wed, 17 Oct 2018, 04:28 Steven Liu,  wrote:

> Signed-off-by: Steven Liu 
> ---
>  src/documentation | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/src/documentation b/src/documentation
> index e3bbf4c..7569e86 100644
> --- a/src/documentation
> +++ b/src/documentation
> @@ -131,6 +131,8 @@
>
>  http://ffmpeg.tv;>FFmpeg Basics by Frantisek
> Korbel,
>describes various FFmpeg features and common tasks.
> +http://book.chinaffmpeg.com;>FFmpeg Beginner's
> handbook Chinese Version by Steven Liu,
> +  describes FFmpeg common use method in China, from command line
> to API usage.
>

Should this be Chinese instead of China?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/3] avfilter: Add support for colour range as a link parameter

[Kieran O Leary]

Hi,

On Thu, Feb 22, 2018 at 4:15 PM, Philip Langdale  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Thu, 22 Feb 2018 12:39:16 +0100
> Nicolas George  wrote:
>
>> Philip Langdale (2018-02-21):
>> > Negotiation is part of Paul's larger changeset, and will be a useful
>> > feature. My change is still a strict improvement over the current
>> > state of the world - where range is not propagated at all,
>> > regardless of compatibility. In those situations where negotiation
>> > is required, the status quo will essentially continue, with the
>> > range value not accurately reflecting the frame contents.
>>
>> I am not comfortable with what you write here.
>>
>> I am afraid that adding negotiation on top of this would be more work
>> than adding negotiation on top of the current code.
>>
>> I am also afraid that an incorrect value is worse than an unspecified
>> one.
>>
>> But it all depends on what filters and codecs actually do with the
>> color range, and that I do not know.
>>
>> Could you perhaps make a little summary of that issue: where the color
>> range comes from, which filters and encoders do not care, which ones
>> only work with one, which ones do something special with it? Maybe as
>> a longer doxy comment for enum AVColorRange in libavutil/pixfmt.h?
>
> You can go back and read through Paul's patchset from december, which
> implements negotiation. My changes here are a strict subset of those,
> so empirically, merging this subset on its own does not make
> negotiation harder. You are also welcome to recommend merging his full
> patchset now; it never got the reviews it needed, but that doesn't mean
> it can't.
>

I am hoping to test out this patchset in the hopes that it could
rectify the issue we're having with colour metadata in a MOV/ProRes
file not being migrated over to Matroska:
https://ffmpeg.org/pipermail/ffmpeg-user/2018-July/040717.html

I have two questions as I'm a bit confused:
1. Does this patchset require Paul's patchset to be merged? I can't
tell if it has already or not.
2. I see that this thread describes a series of 4 patches, but there
also seems to be
a set of three patches from February - do the set of 3 supercede this
set of 4? https://patchwork.ffmpeg.org/patch/7694/

Best,

Kieran O'Leary
IFI Irish Film Archive
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Sponsoring request

[Kieran O Leary]

Hi

On Thu, 19 Jul 2018, 14:04 Paul B Mahol,  wrote:

> Hi,
>
> I want that FFmpeg community sponsor addition of new code I gonna
> develop in following days/months.
>

Are you suggesting a patreon type payment?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Limited timecode support for lavd/decklink

[Kieran O Leary]

Hi Jonathan,

On Fri, May 25, 2018 at 6:32 PM, Jonathan Morley  wrote:
> Hi Kieran,
>
> To answer your question, this change basically takes the first valid TC as a 
> string and sticks it in the video’s avstream metadata dictionary where other 
> muxers and encoders look. It does not make an independent timecode 
> track/stream with samples per frame. That is why I called the patch 
> “limited”. However there doesn’t seem to be many if any parts of ffmpeg that 
> use dedicated timecode streams with individual samples. That is why it still 
> seemed worth submitting my work back as we move on to other solutions.

It sounds great to me! I think that this type of timecode (just
storing first value as a string string) is all I've ever really seen
in the real world(I work in the Irish Film Archive and we have several
thousand video tapes as well). This is how AJA Control Room and
Blackmagic Media Express work anyhow. I'm hoping that this will allow
open source archival capture tools like
https://github.com/amiaopensource/vrecord to be able to capture
timecode.

I look forward to trying it out, as our goal is to be able to use
vrecord in order to capture tape to FFV1/Matroska. Matroska doesn't
support data tracks (yet), but ffmpeg does store the starting timecode
string as a Matroska Tag when it detects a timecode track in a source
video. I would love if capturing to Matroska from tape could store
that starting timecode value, but it's a completely seperate issue to
this patch.

>
> I hope that still helps you in your case. I will stay the course to address 
> Marton’s feedback and get this in there.

yeah it's great, I'm also interested in your AJA work as we also have
AJA hardware, though as there's no open SDK for AJA, I'm not sure how
this would integrate into FFmpeg.

Best,

Kieran.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Limited timecode support for lavd/decklink

[Kieran O Leary]

I'd love to see some documentation and to know how timecode is stored in
the output file. This looks like a really welcome development!
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] github

[Kieran O Leary]

On Thu, 26 Apr 2018, 14:42 Daniel Oberhoff, 
wrote:

>
> > On 26. Apr 2018, at 14:40, wm4  wrote:
> >
> > On Thu, 26 Apr 2018 14:12:14 +0200
> > Hendrik Leppkes >
> wrote:
> >
> >> On Thu, Apr 26, 2018 at 2:02 PM, Daniel Oberhoff
> >>  wrote:
> >>>
>  Am 26.04.2018 um 13:59 schrieb Daniel Oberhoff <
> danieloberh...@googlemail.com>:
> 
> 
> > Am 26.04.2018 um 13:56 schrieb Daniel Oberhoff <
> danieloberh...@googlemail.com>:
> >
> >
> >> Am 26.04.2018 um 13:52 schrieb Nicolas George :
> >>
> >> Daniel Oberhoff (2018-04-26):
> >>> I was wondering if there is any chance to move development to
> github?
> >>> I.e. not just mirror, but as primary development repo, with issues
> and
> >>> pull requests? Would make collaboration a *lot* easier (think of
> >>> submitting a pr instead of having to generate/format/split
> patches).
> >>
> >> If development involves working in a web browser a lot, count me
> out.
> >> Can you point me to the command-line
> >
> > https://hub.github.com/hub.1.html
> 
>  But you can’t really do reviews that way, so the criticism stands.
> >>>
> >>> BTW, is there any kind of issue tracking?
> >>
> >> https://trac.ffmpeg.org/
> >
> > To be fair, I'd prefer the github issue tracker over TRAC any day.
> > Still has the other problems I mentioned.
>
> gitlab?
>


Mkvtoolnix moved to gitlab from GitHub due to some of the concerns raised
in this thread. The comments in this blog by Moritz Bunkus are worth
reading. https://www.bunkus.org/blog/2017/12/mkvtoolnix-moves-to-gitlab/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH][RFC] avcodec/dpxenc: add option to force color transfer characteristics

[Kieran O Leary]

On Wed, Apr 11, 2018 at 9:42 AM, Tobias Rapp <t.r...@noa-archive.com> wrote:
> On 11.04.2018 10:23, Kieran O Leary wrote:
>>
>> Hi Carl,
>>
>> On Sat, Dec 16, 2017 at 2:31 PM, Carl Eugen Hoyos <ceffm...@gmail.com>
>> wrote:
>>>
>>> 2017-12-15 22:22 GMT+01:00 Tobias Rapp <t.r...@noa-archive.com>:
>>>
>>>> +{ "dpx_color_trc",  "Transfer Characteristics", OFFSET(color_trc),
>>>> AV_OPT_TYPE_INT, { .i64 = DPX_TRC_UNDEFINED }, DPX_TRC_UNDEFINED,
>>>> DPX_TRC_NB-1, VE, "trc" },
>>>
>>>
>>> This seems wrong to me, we have colour characteristics in general code.
>>>
>>
>> There is a method in this patch that takes values from -color_trc, is
>> that not sufficient?
>>
>> [...]
>
>
> If I understand it correctly Carl wants to have the DPX_TRC_* enum values
> merged into AVCOL_TRC_*. My feeling is that I currently don't have enough
> knowledge about all those TRC specifications to properly sort them into the
> list, and did not find time to dig into the topic. Also I doubt the general
> usefulness of DPX_TRC_USER_DEFINED or DPX_TRC_UNSPECIFIED_VIDEO outside of
> DPX encoding.
>

I also don't see the point of the DPX specific values to be used in
the general list. I'd include Printing Density in this as well.

Best,

Kieran.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH][RFC] avcodec/dpxenc: add option to force color transfer characteristics

[Kieran O Leary]

Hi Carl,

On Sat, Dec 16, 2017 at 2:31 PM, Carl Eugen Hoyos  wrote:
> 2017-12-15 22:22 GMT+01:00 Tobias Rapp :
>
>> +{ "dpx_color_trc",  "Transfer Characteristics", OFFSET(color_trc), 
>> AV_OPT_TYPE_INT, { .i64 = DPX_TRC_UNDEFINED }, DPX_TRC_UNDEFINED, 
>> DPX_TRC_NB-1, VE, "trc" },
>
> This seems wrong to me, we have colour characteristics in general code.
>

There is a method in this patch that takes values from -color_trc, is
that not sufficient?

$ ./ffmpeg -f lavfi -i testsrc -color_trc bt709 -vframes 1 out.dpx &&
mediainfo out.dpx |tail -n 4

ffmpeg version N-90649-g9825f77 Copyright (c) 2000-2018 the FFmpeg developers

  built with Apple LLVM version 8.0.0 (clang-800.0.42.1)

  configuration:

  libavutil  56. 13.100 / 56. 13.100

  libavcodec 58. 17.100 / 58. 17.100

  libavformat58. 11.101 / 58. 11.101

  libavdevice58.  2.100 / 58.  2.100

  libavfilter 7. 14.100 /  7. 14.100

  libswscale  5.  0.102 /  5.  0.102

  libswresample   3.  0.101 /  3.  0.101

Input #0, lavfi, from 'testsrc':

  Duration: N/A, start: 0.00, bitrate: N/A

Stream #0:0: Video: rawvideo (RGB[24] / 0x18424752), rgb24,
320x240 [SAR 1:1 DAR 4:3], 25 tbr, 25 tbn, 25 tbc

File 'out.dpx' already exists. Overwrite ? [y/N] y

Stream mapping:

  Stream #0:0 -> #0:0 (rawvideo (native) -> dpx (native))

Press [q] to stop, [?] for help

Output #0, image2, to 'out.dpx':

  Metadata:

encoder : Lavf58.11.101

Stream #0:0: Video: dpx, rgb24(unknown/unknown/bt709), 320x240
[SAR 1:1 DAR 4:3], q=2-31, 200 kb/s, 25 fps, 25 tbn, 25 tbc

Metadata:

  encoder : Lavc58.17.100 dpx

frame=1 fps=0.0 q=-0.0 Lsize=N/A time=00:00:00.04 bitrate=N/A
speed=20.6x

video:227kB audio:0kB subtitle:0kB other streams:0kB global
headers:0kB muxing overhead: unknown

Color primaries  : BT.709

Transfer characteristics : BT.709


Best,

Kieran.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/dpx: Support for RGB 12-bit packed decoding

[Kieran O Leary]

On Tue, Apr 10, 2018 at 3:16 PM, Paul B Mahol <one...@gmail.com> wrote:
> On 4/10/18, Kieran O Leary <kieran.o.le...@gmail.com> wrote:
>>
>> Hopefully this is a bit better than just using ffmpeg?
>
> No, you must not use tragic software ever.
>
> Besides ffmpeg also can give you checksums for image only.
> See framehash muxer, and it can give you sha512 hash.

Yes, I've used framehash but we use framemd5 internally in the Irish
Film Institute. I was just using another DPX decoder as Carl is
sceptical about using framemd5, or ffmpeg in general to determine
losslessness of files created by ffmpeg.
This was one of the only times I've ever used Image/GraphicsMagick to be honest.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/dpx: Support for RGB 12-bit packed decoding

[Kieran O Leary]

Actually, here's another test that might be a bit more meaningful.
This is using graphicksmagic and the identify/signature command in
order to generate sha256 hashes for the image data only.

It is producing identical hashes for:
1. The original 12-bit DPX from Da Vinci Resolve (not packed to 16-bit)
2. The graphicsmagick 12-bit DPX to 12-bit DPX (padded to 16-bit DPX) file
3. The ffmpeg convert 12-bit DPX to 12-bit DPX (padded to 16-bit DPX)
which uses the ffmpeg decoder with Jerome's patch.

$ gm identify -verbose
6e0edc3b-7d89-4710-8b9a-66c8c990f9dc_1_00094787.dpx  |grep -i
signature

  Signature: 3fb67059dca860c483b1deac912973b76d48fa9f0114d63e8116cff69d55bb4c

$ gm identify -verbose gm_dpx_to_dpx.dpx  |grep -i signature

  Signature: 3fb67059dca860c483b1deac912973b76d48fa9f0114d63e8116cff69d55bb4c


$ gm identify -verbose ffmpeg_dpx_to_dpx.dpx  |grep -i signature

  Signature: 3fb67059dca860c483b1deac912973b76d48fa9f0114d63e8116cff69d55bb4c

Hopefully this is a bit better than just using ffmpeg?

Best,

Kieran.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/dpx: Support for RGB 12-bit packed decoding

[Kieran O Leary]

Hi

On Tue, Apr 10, 2018 at 11:34 AM, Carl Eugen Hoyos <ceffm...@gmail.com> wrote:
> 2018-04-10 12:28 GMT+02:00, Kieran O Leary <kieran.o.le...@gmail.com>:
>> I just tested this patch non packed to 16-bit gbrp12le DPX from DaVinci
>> Resolve.
>
> Testing is good, apart from more brackets (and less comments) it would
> be better if Jerome sends his public keys to Michael and pushes the patch.
>
>> Encoding to FFV1 and back again to DPX produced the same
>> framemd5 values.
>
> (I believe we already discussed in public that testing FFmpeg's bugs
> with FFmpeg makes limited sense.)
>

Yes, and at the risk of making a fool of myself, here's some slightly
different testing sing the graphicsmagick dpx encoder:
The following console outputs have 4 steps:

1. Use gm convert to decode 12-bit DPX to 12-bit DPX (padded to 16-bit DPX)
2. Use ffmpeg convert to decode 12-bit DPX to 12-bit DPX (padded to 16-bit DPX)
3. Use ffmpeg to decode the graphicsmagick file with the md5 muxer
4. Use ffmpeg to decode the ffmpeg file with the md5 muxer

The same md5 values are produced in steps 3 and 4- not sure what it
proves exactly, maybe that even if the ffmpeg decoder is buggy, at
least it decodes the files produced by Jerome's patch and the existing
GM decoder in the same way?

$ gm convert -verbose
6e0edc3b-7d89-4710-8b9a-66c8c990f9dc_1_00094787.dpx gm_dpx_to_dpx.dpx

6e0edc3b-7d89-4710-8b9a-66c8c990f9dc_1_00094787.dpx DPX 1600x1168+0+0
DirectClass 12-bit 8.0Mi 0.030u 0m:0.05s

6e0edc3b-7d89-4710-8b9a-66c8c990f9dc_1_00094787.dpx=>gm_dpx_to_dpx.dpx
DPX 1600x1168+0+0 DirectClass 12-bit 10.7Mi 0.040u 0m:0.15s
(11.9Mi pixels/s)



$ ./ffmpeg  -i 6e0edc3b-7d89-4710-8b9a-66c8c990f9dc_1_00094787.dpx
ffmpeg_dpx_to_dpx.dpx

ffmpeg version N-90642-gd64183e Copyright (c) 2000-2018 the FFmpeg developers

  built with Apple LLVM version 8.0.0 (clang-800.0.42.1)

  configuration:

  libavutil  56. 13.100 / 56. 13.100

  libavcodec 58. 17.100 / 58. 17.100

  libavformat58. 11.101 / 58. 11.101

  libavdevice58.  2.100 / 58.  2.100

  libavfilter 7. 14.100 /  7. 14.100

  libswscale  5.  0.102 /  5.  0.102

  libswresample   3.  0.101 /  3.  0.101

[dpx_pipe @ 0x7f80db809000] Stream #0: not enough frames to estimate
rate; consider increasing probesize

Input #0, dpx_pipe, from '6e0edc3b-7d89-4710-8b9a-66c8c990f9dc_1_00094787.dpx':

  Duration: N/A, bitrate: N/A

Stream #0:0: Video: dpx, gbrp12le, 1600x1168 [SAR 1:1 DAR 100:73],
24 tbr, 25 tbn, 24 tbc

Stream mapping:

  Stream #0:0 -> #0:0 (dpx (native) -> dpx (native))

Press [q] to stop, [?] for help

Output #0, image2, to 'ffmpeg_dpx_to_dpx.dpx':

  Metadata:

encoder : Lavf58.11.101

Stream #0:0: Video: dpx, gbrp12le, 1600x1168 [SAR 1:1 DAR 100:73],
q=2-31, 200 kb/s, 24 fps, 24 tbn, 24 tbc

Metadata:

  encoder : Lavc58.17.100 dpx

frame=1 fps=0.0 q=-0.0 Lsize=N/A time=00:00:00.04 bitrate=N/A
speed=0.286x

video:10952kB audio:0kB subtitle:0kB other streams:0kB global
headers:0kB muxing overhead: unknown



$ ./ffmpeg -i ffmpeg_dpx_to_dpx.dpx -f md5 -

ffmpeg version N-90642-gd64183e Copyright (c) 2000-2018 the FFmpeg developers

  built with Apple LLVM version 8.0.0 (clang-800.0.42.1)

  configuration:

  libavutil  56. 13.100 / 56. 13.100

  libavcodec 58. 17.100 / 58. 17.100

  libavformat58. 11.101 / 58. 11.101

  libavdevice58.  2.100 / 58.  2.100

  libavfilter 7. 14.100 /  7. 14.100

  libswscale  5.  0.102 /  5.  0.102

  libswresample   3.  0.101 /  3.  0.101

[dpx_pipe @ 0x7ff76b009000] Stream #0: not enough frames to estimate
rate; consider increasing probesize

Input #0, dpx_pipe, from 'ffmpeg_dpx_to_dpx.dpx':

  Duration: N/A, bitrate: N/A

Stream #0:0: Video: dpx, gbrp12le, 1600x1168 [SAR 1:1 DAR 100:73],
25 tbr, 25 tbn, 25 tbc

Stream mapping:

  Stream #0:0 -> #0:0 (dpx (native) -> rawvideo (native))

Press [q] to stop, [?] for help

Output #0, md5, to 'pipe:':

  Metadata:

encoder : Lavf58.11.101

Stream #0:0: Video: rawvideo (G3[0][12] / 0xC003347), gbrp12le,
1600x1168 [SAR 1:1 DAR 100:73], q=2-31, 1681920 kb/s, 25 fps, 25 tbn,
25 tbc

Metadata:

  encoder : Lavc58.17.100 rawvideo

MD5=aa43e3ec1c2a8e4499b3bc796a35185b

frame=1 fps=0.0 q=-0.0 Lsize=   0kB time=00:00:00.04 bitrate=
 7.4kbits/s speed=1.25x

video:10950kB audio:0kB subtitle:0kB other streams:0kB global
headers:0kB muxing overhead: unknown



$ ./ffmpeg -i gm_dpx_to_dpx.dpx -f md5 -

ffmpeg version N-90642-gd64183e Copyright (c) 2000-2018 the FFmpeg developers

  built with Apple LLVM version 8.0.0 (clang-800.0.42.1)

  configuration:

  libavutil  56. 13.100 / 56. 13.100

  libavcodec 58. 17.100 / 58. 17.100

  libavformat58. 11.101 / 58. 11.101

  libavdevice58.  2.100 / 58.  2.100

  libavfilter 7. 14.100 /  7. 14.100

  libswscale  5.  0.102 /  5.  0.102

 

Re: [FFmpeg-devel] [PATCH] avcodec/dpx: Support for RGB 12-bit packed decoding

[Kieran O Leary]

I just tested this patch non packed to 16-bit gbrp12le DPX from DaVinci
Resolve. Encoding to FFV1 and back again to DPX produced the same framemd5
values.

Does any more testing need to happen before this can be merged?

Best,

Kieran
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/dpx: Support for RGB and RGBA 12-bit packed decoding

[Kieran O Leary]

Hi both,

I'm just wondering if the past duration errors in my earlier email mean
anything,or should they be ignored?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/dpx: Support for RGB and RGBA 12-bit packed decoding

[Kieran O Leary]

Hi Jerome,

Thank you so much for this patch.

I ran a quick test and ffmpeg and ffplay seems to decode these files
just fine. I noticed that taking a short 12-bit sequence (i didn't
even realise that they were big endian actually) from the Blackmagic
Cintel Scanner turned into FFV1 version 3 in Matroska with identical
framemd5s. I did get some past duration errors in the terminal though:

Here's a few frames that I used in this example. It seems to happen at
the 16th frame..
https://www.dropbox.com/sh/imaasud6yora8me/AAAXXGIQ9w6fFfvx9qigizyVa?dl=0https://www.dropbox.com/sh/imaasud6yora8me/AAAXXGIQ9w6fFfvx9qigizyVa?dl=0

./ffmpeg -start_number 00086400 -i
first_frames/99075c82-2770-4020-a289-d191dab0b852_1_%08d.dpx -c:v ffv1
-level 3 out.mkv

ffmpeg version N-89977-gddd851f Copyright (c) 2000-2018 the FFmpeg developers

  built with Apple LLVM version 8.0.0 (clang-800.0.42.1)

  configuration:

  libavutil  56.  7.100 / 56.  7.100

  libavcodec 58. 10.100 / 58. 10.100

  libavformat58.  9.100 / 58.  9.100

  libavdevice58.  1.100 / 58.  1.100

  libavfilter 7. 11.101 /  7. 11.101

  libswscale  5.  0.101 /  5.  0.101

  libswresample   3.  0.101 /  3.  0.101

Input #0, image2, from
'first_frames/99075c82-2770-4020-a289-d191dab0b852_1_%08d.dpx':

  Duration: 00:00:00.92, start: 0.00, bitrate: N/A

Stream #0:0: Video: dpx, gbrp12le, 2160x1702 [SAR 1:1 DAR
1080:851], 24 tbr, 25 tbn, 24 tbc

Stream mapping:

  Stream #0:0 -> #0:0 (dpx (native) -> ffv1 (native))

Press [q] to stop, [?] for help

[ffv1 @ 0x7fd89c013800] bits_per_raw_sample > 8, forcing range coder

Output #0, matroska, to 'out.mkv':

  Metadata:

encoder : Lavf58.9.100

Stream #0:0: Video: ffv1 (FFV1 / 0x31564646), gbrp12le, 2160x1702
[SAR 1:1 DAR 1080:851], q=2-31, 200 kb/s, 24 fps, 1k tbn, 24 tbc

Metadata:

  encoder : Lavc58.10.100 ffv1

frame=2 fps=0.0 q=-0.0 size=   11653kB time=00:00:00.04
bitrate=2220121.7kbiframe=4 fps=3.4 q=-0.0 size=   34930kB
time=00:00:00.12 bitrate=2270993.5kbiframe=6 fps=3.4 q=-0.0 size=
 58259kB time=00:00:00.20 bitrate=2283544.4kbiframe=8 fps=3.3
q=-0.0 size=   81588kB time=00:00:00.29 bitrate=2281121.4kbiframe=
10 fps=3.3 q=-0.0 size=  104852kB
time=00:00:00.37bitrate=2284434.3kbiframe=   12 fps=3.3 q=-0.0 size=
128130kB time=00:00:00.45 bitrate=2286805.8kbiframe=   14 fps=3.3
q=-0.0 size=  151452kB time=00:00:00.54 bitrate=2284891.4kbiframe=
16 fps=3.3 q=-0.0 size=  174741kB time=00:00:00.62
bitrate=2286710.7kbiPast duration 0.639992 too large

Past duration 0.679985 too large

frame=   18 fps=3.2 q=-0.0 size=  198043kB time=00:00:00.70
bitrate=2288247.4kbiPast duration 0.719994 too large

Past duration 0.759987 too large

frame=   20 fps=3.2 q=-0.0 size=  221335kB time=00:00:00.79
bitrate=2286478.6kbiPast duration 0.75 too large

Past duration 0.839989 too large

frame=   22 fps=3.2 q=-0.0 size=  244648kB time=00:00:00.87
bitrate=2287850.0kbiPast duration 0.879997 too large

frame=   23 fps=3.1 q=-0.0 size=  256309kB time=00:00:00.91
bitrate=2287235.2kbiframe=   23 fps=3.1 q=-0.0 Lsize=  267948kB
time=00:00:00.91 bitrate=2391103.3kbits/s speed=0.123x

video:267947kB audio:0kB subtitle:0kB other streams:0kB global
headers:0kB muxing overhead: 0.000610%

Best,

Kieran O'Leary
IFI Irish Film Archive
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Decklink question

[Kieran O Leary]

On 29 Sep 2017 03:22,  wrote:


I will continue to do testing..
>



This works and captures full range (data levels, but the captured data
happens to be video levels 64-940) to the output file and the out.mov file
looks good/clean. Not sure how to flag (metadata) output color space and
levels, but can always force it in most programs (KDEnlive, Resolve).


Add -color_range mpeg to your command line.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] doc: add mailing list faq

[Kieran O Leary]

Just one typo below, thanks for providing the html as well.

On 28 Sep 2017 01:00, "Lou Logan"  wrote:

Signed-off-by: Lou Logan 
---
 doc/Makefile  |   1 +
 doc/mailing-list-faq.texi | 204 ++

 2 files changed, 205 insertions(+)
 create mode 100644 doc/mailing-list-faq.texi

diff --git a/doc/Makefile b/doc/Makefile
index b670f0bd4c..9a4d225e65 100644
--- a/doc/Makefile
+++ b/doc/Makefile
@@ -24,6 +24,7 @@ HTMLPAGES   = $(AVPROGS-yes:%=doc/%.html)
$(AVPROGS-yes:%=doc/%-all.html) $(COMP
   doc/fate.html \
   doc/general.html  \
   doc/git-howto.html\
+  doc/mailing-list-faq.html \
   doc/nut.html  \
   doc/platform.html \

diff --git a/doc/mailing-list-faq.texi b/doc/mailing-list-faq.texi
new file mode 100644
index 00..a047fdcd51
--- /dev/null
+++ b/doc/mailing-list-faq.texi
@@ -0,0 +1,204 @@
+\input texinfo @c -*- texinfo -*-
+@documentencoding UTF-8
+
+@settitle FFmpeg Mailing List FAQ
+@titlepage
+@center @titlefont{FFmpeg Mailing List FAQ}
+@end titlepage
+
+@top
+
+@contents
+
+@chapter General Questions
+
+@section What is a mailing list?
+
+A mailing list is not much different than emailing someone, but the
+main difference is that your message is received by everyone who
+subscribes to the list. It is somewhat like a forum but in email form.
+
+See the @url{https://lists.ffmpeg.org/pipermail/ffmpeg-user/, ffmpeg-user
archives}
+for examples.
+
+@section What type of questions can I ask?
+
+@url{https://lists.ffmpeg.org/mailman/listinfo/ffmpeg-user/, ffmpeg-user}:
+For questions involving unscripted usage or compilation of the FFmpeg
+command-line tools (@command{ffmpeg}, @command{ffprobe}, @command{ffplay},
+@command{ffserver}).
+
+@url{https://lists.ffmpeg.org/mailman/listinfo/libav-user/, libav-user}:
+For questions involving the FFmpeg libav* libraries (libavcodec,
+libavformat, libavfilter, etc).
+
+@url{https://lists.ffmpeg.org/mailman/listinfo/ffmpeg-devel/,
ffmpeg-devel}:
+Only for discussions involving the development of FFmpeg and for
+submitting patches. User questions should be asked at ffmpeg-user or
+libav-user.
+
+To report a bug see @url{https://ffmpeg.org/bugreports.html}.
+
+We cannot provide help for scripts and/or third-party tools.
+
+@section How do I ask a question or send a message to the mailing list?
+
+E-mail @email{ffmpeg-user@@ffmpeg.org}.
+
+If you are not subscribed to the mailing list then your question must be
+manually approved. Approval may take several days, but the wait is
+usually less. If you want the message to be sent with no delay then you
+must subscribe first.
+
+Please do not send a message, subscribe, and re-send the message: this
+results in duplicates, causes more work for the admins, and may lower
+your chance at getting an answer. However, you may do so if you first
+@ref{How do I delete my message in the moderation queue, delete your
original message from the moderation queue}.
+
+@chapter Subscribing / Unsubscribing
+
+@section Do I need to subscribe?
+
+No.
+
+However, you will not directly receive replies unless you ask to be CCd
+in your message, but on occasion users will forget to CC you when
+replying. Alternatively, you can view and reply to messages via the
+@ref{Where are the archives, archives}.
+
+@section How do I subscribe?
+
+Email @email{ffmpeg-user-request@@ffmpeg.org} with the subject
+@emph{subscribe}.
+
+Or visit the @url{https://lists.ffmpeg.org/mailman/listinfo/ffmpeg-user/,
ffmpeg-user mailing list info page}
+and refer to the @emph{Subscribing to ffmpeg-user} section.
+
+The process is the same for the other mailing lists.
+
+@section How do I unsubscribe?
+
+Email @email{ffmpeg-user-request@@ffmpeg.org} with subject
@emph{unsubscribe}.
+
+Or visit the @url{https://lists.ffmpeg.org/mailman/listinfo/ffmpeg-user/,
ffmpeg-user mailing list info page},
+scroll to bottom of page, enter your email address in the box, and click
+the @emph{Unsubscribe or edit options} button.
+
+The process is the same for the other mailing lists.
+
+Please avoid asking a mail admin to unsubscribe you: there should be no
+reason to do so.
+
+@anchor{How do I delete my message in the moderation queue}
+@section How do I delete my message in the moderation queue?
+
+You should have received an email with the subject @emph{Your message to
ffmpeg-user awaits moderator approval}.
+A link is in the message that will allow you to delete your message
+unless a mail admin already approved or rejected it.
+
+@chapter Archives
+
+@anchor{Where are the archives}
+@section Where are the archives?
+
+See the @emph{Archives} section on the 

Re: [FFmpeg-devel] [PATCH] prores: Always assume limited range

[Kieran O Leary]

On Wed, Sep 27, 2017 at 10:28 PM, Vittorio Giovara
 wrote:
> As defined by the spcifications

Is this the paywalled SMPTE spec? I don't see any mention of it in the
openly available whitepaper,
https://images.apple.com/final-cut-pro/docs/Apple_ProRes_White_Paper.pdf
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] movenc:adds keywords metadata

[Kieran O Leary]

Thanks Derek/Michael!

-Kieran.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] movenc:adds keywords metadata

[Kieran O Leary]

Hi,

A user mentioned in ffmpeg-user (
http://ffmpeg.org/pipermail/ffmpeg-user/2017-July/036571.html)  that they
couldn't write the 'keywords' metadata tag. I tested this patch and it
appears to add the metadata value when using MOV and MP4 as output. I'm
sure I've messed something up so please let me know if I can improve this.

Patch is attached and posted here too:

>From c474a7f5095fc1a84c4bd2d811546a821f6420f6 Mon Sep 17 00:00:00 2001
From: Kieran O'Leary 
Date: Mon, 10 Jul 2017 22:54:56 +0100
Subject: [PATCH] movenc:adds keywords metadata

---
 libavformat/movenc.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 88f2f2c..3989ac1 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -3321,6 +3321,7 @@ static int mov_write_ilst_tag(AVIOContext *pb,
MOVMuxContext *mov,
 mov_write_string_metadata(s, pb, "tvsh","show" , 1);
 mov_write_string_metadata(s, pb, "tven","episode_id",1);
 mov_write_string_metadata(s, pb, "tvnn","network"  , 1);
+mov_write_string_metadata(s, pb, "keyw","keywords"  , 1);
 mov_write_int8_metadata  (s, pb, "tves","episode_sort",4);
 mov_write_int8_metadata  (s, pb, "tvsn","season_number",4);
 mov_write_int8_metadata  (s, pb, "stik","media_type",1);
@@ -3543,6 +3544,7 @@ static int mov_write_udta_tag(AVIOContext *pb,
MOVMuxContext *mov,
 mov_write_string_metadata(s, pb_buf, "\251mak", "make",0);
 mov_write_string_metadata(s, pb_buf, "\251mod", "model",   0);
 mov_write_string_metadata(s, pb_buf, "\251xyz", "location",0);
+mov_write_string_metadata(s, pb_buf, "\251key", "keywords",0);
 mov_write_raw_metadata_tag(s, pb_buf, "XMP_", "xmp");
 } else {
 /* iTunes meta data */
-- 
2.7.4


Best,

Kieran O'Leary
IFI Irish Film Archive
From c474a7f5095fc1a84c4bd2d811546a821f6420f6 Mon Sep 17 00:00:00 2001
From: Kieran O'Leary 
Date: Mon, 10 Jul 2017 22:54:56 +0100
Subject: [PATCH] movenc:adds keywords metadata

---
 libavformat/movenc.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 88f2f2c..3989ac1 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -3321,6 +3321,7 @@ static int mov_write_ilst_tag(AVIOContext *pb, MOVMuxContext *mov,
 mov_write_string_metadata(s, pb, "tvsh","show" , 1);
 mov_write_string_metadata(s, pb, "tven","episode_id",1);
 mov_write_string_metadata(s, pb, "tvnn","network"  , 1);
+mov_write_string_metadata(s, pb, "keyw","keywords"  , 1);
 mov_write_int8_metadata  (s, pb, "tves","episode_sort",4);
 mov_write_int8_metadata  (s, pb, "tvsn","season_number",4);
 mov_write_int8_metadata  (s, pb, "stik","media_type",1);
@@ -3543,6 +3544,7 @@ static int mov_write_udta_tag(AVIOContext *pb, MOVMuxContext *mov,
 mov_write_string_metadata(s, pb_buf, "\251mak", "make",0);
 mov_write_string_metadata(s, pb_buf, "\251mod", "model",   0);
 mov_write_string_metadata(s, pb_buf, "\251xyz", "location",0);
+mov_write_string_metadata(s, pb_buf, "\251key", "keywords",0);
 mov_write_raw_metadata_tag(s, pb_buf, "XMP_", "xmp");
 } else {
 /* iTunes meta data */
-- 
2.7.4

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] vf_colorspace: Add support for smpte248 color primaries

[Kieran O Leary]

Hi,

Should the vf colorspace documentation be updated with this new addition?

Best,

Kieran
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/dpxenc: support colour metadata in DPX encoder, fixes ticket #6023

[Kieran O Leary]

Hi Vittorio!

thanks for getting back to me.

On Fri, Feb 3, 2017 at 12:57 PM, Vittorio Giovara <
vittorio.giov...@gmail.com> wrote:

>
>
> Hey Kieran,
> I think the code looks fine. I am just wondering if we should also
> offer the possibility to set these flags from the standard context
> options (-color_trc and others). I'm aware that not all values match
> or are valid but maybe a small conversion table or extending the main
> table could be a viable approach. Similarly this could be done for the
> decoder so that color properties are not lost during a dpx->dpx
> conversion maybe.
>

That seems to be the general consensus from the replies from James Almer
and Carl Eugen and it's what i should push towards.
I added the new values locally to pixfmt.h. I'm thinking that these could
be called in a similar way to the EXR decoder? https://github.com/
FFmpeg/FFmpeg/blob/8a1759ad46f05375c957f33049b459
2befbcb224/libavcodec/exr.c#L1840

In terms of translation tables, could you point me to some simlar code that
could serve as a starting point for me? The nearest that made sense to me
seems to be these values in vf_colorpsace.c
https://github.com/FFmpeg/FFmpeg/blob/master/libavfilter/vf_colorspace.c#L97
?

-kieran
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/dpxenc: support colour metadata in DPX encoder, fixes ticket #6023

[Kieran O Leary]

Hi

On 2 Feb 2017 08:20, "Carl Eugen Hoyos" <ceffm...@gmail.com> wrote:

2017-02-01 23:37 GMT+01:00 Kieran O Leary <kieran.o.le...@gmail.com>:

> DPX contains some values that are super-specific to film, such as
'Printing
> Density'. I do not see that value in either of those enums but it's a
> common value that pops up in film scans.

Then I believe you have to add this property to the enums.


Will do. In a separate patch?


> The larger issue that I see with this approach is that it's an integer
that
> needs to be written to the 801/802 offsets in the DPX header. So if I want
> logarithmic transfer characteristic, 3 needs to be written as the value
and
> this is interpreted by the decoder. Logarithmic is listed as 9 in
>  AVColorTransferCharacteristic

This means you need a translation in dpxenc.c.


Ah,  great. Thanks for the heads up. I'll prepare another patch once I
figure this out.

Thanks for your help!

-Kieran
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/dpxenc: support colour metadata in DPX encoder, fixes ticket #6023

[Kieran O Leary]

Hi James and Carl,

Thanks for getting back to me. It looks like your comments are similar,
though you might be asking to pull the information from different places?
more below

On Wed, Feb 1, 2017 at 5:01 PM, James Almer  wrote:

>
> I may be missing something and apologizes if it was already mentioned, but
> libavcodec already have options for these, color_trc and if i'm reading
> this right colorspace, making use of the AVColorTransferCharacteristic and
> AVColorSpace enums defined in avutil's pixfmt.h header.
>
> Can't you use them instead?
>
>
>
DPX contains some values that are super-specific to film, such as 'Printing
Density'. I do not see that value in either of those enums but it's a
common value that pops up in film scans.
The larger issue that I see with this approach is that it's an integer that
needs to be written to the 801/802 offsets in the DPX header. So if I want
logarithmic transfer characteristic, 3 needs to be written as the value and
this is interpreted by the decoder. Logarithmic is listed as 9 in
 AVColorTransferCharacteristic - but perhaps this is irrelevant and I'm
misunderstanding how pixfmt.h works? Things like 'unspecified video' are
not in those enums either.

Carl Eugen mentioned AvCodecContext but I don't know enough about this to
be able to see if the values as specified by SMPTE will map.

-Kieran.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avcodec/dpxenc: support colour metadata in DPX encoder, fixes ticket #6023

[Kieran O Leary]

Hello,

I'm cc'ing Vittorio as I don't think that he's subscribed to the list but
he's contributed to dpxenc.c and recent colorspace filters. The same with
Kate Murray from the Library of Congress who knows a lot more about DPX
than me. Apologies if this is inappropriate.

I mostly based this patch on other ffmpeg encoders, such as pncenc.c. I'm
not really a C coder, I'm a moving image archivist who needs to be able to
specify colour metadata in DPX for various workflows. Please excuse my
ignorance/mistakes.

This patch adds documentation and two command line options for the DPX
encoder:
-trc (Transfer Characteristics) and -clr (Colorimetric Specification),
which set colour metadata values in a DPX file. Currently these are
hardcoded to always be 2, aka Linear. Ticket #6023 is related to this, but
there have also been many mailing list posts about this issue:
https://ffmpeg.org/pipermail/ffmpeg-user/2015-March/025630.html
https://ffmpeg.org/pipermail/ffmpeg-user/2015-December/029456.html

I've kept the default values as 2 (Linear) as this is what was originally
in dpxenc, but I'm not sure of the value of this really. I think that
there's more value in a default of 0 (User-defined) which would just leave
the values unspecified. Or perhaps no value at all! The initial default of
2 for colorimetric was potentially useless as 2 is listed as 'Not
applicable' for colorimetric specification in SMPTE 268M-2003.

The values for each of these options are the integers listed in the SMPTE
standards doc:
https://web.archive.org/web/20050706060025/http://www.smpte.org/smpte_store/standards/pdf/s268m.pdf

Initially I just had one argument that set the Transfer Characteristic and
Colorimetric Specification to the same value, but perhaps some use cases
could require that these values  be different? I'm not sure if they ever
would. I have never seen real world files that suggest this but I can edit
this if it seems weird.

Some of the values from 0-12 are listed as 'Not applicable' for the
colorimetric specification, but I didn't know how to specify just those
numbers (0-1, 4-10) in the patch. Perhaps it's OK to leave it as is,
otherwise hopefully someone can point me to similar code that I can learn
from. Again, apologies for my ignorance.

I'm attaching the patch and pasting it here too:

>From 8ae63b8301e6822686a7885202938fd6e4cba6f2 Mon Sep 17 00:00:00 2001
From: Kieran O'Leary 
Date: Wed, 1 Feb 2017 12:06:38 +
Subject: [PATCH] avcodec/dpxenc: support colour metadata in DPX encoder,
fixes
 ticket #6023

---
 doc/encoders.texi   | 77
+
 libavcodec/dpxenc.c | 25 ++---
 2 files changed, 99 insertions(+), 3 deletions(-)

diff --git a/doc/encoders.texi b/doc/encoders.texi
index 8137465..d3d8eb2 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -1269,6 +1269,83 @@ disabled
 A description of some of the currently available video encoders
 follows.

+@section dpx
+
+DPX image encoder.
+
+@subsection Options
+
+@table @option
+@item trc @var{integer}
+Set the transfer characteristics as listed in Table 5A in SMPTE 268M-2003:
+
+@table @samp
+@item 0
+User Defined
+@item 1
+Printing Density
+@item 2
+Linear
+@item 3
+Logarithmic [to be defined by SMPTE I23 Technology Committee, sub-group on
“Transfer Characteristics”]
+@item 4
+Unspecified Video
+@item 5
+SMPTE 274M
+@item 6
+ITU-R 709-4
+@item 7
+ITU-R 601-5 system B or G (625)
+@item 8
+ITU-R 601-5 system M (525)
+@item 9
+Composite video (NTSC); see SMPTE 170M
+@item 10
+Composite video (PAL); see ITU-R 624-4
+@item 11
+Z (depth) – linear
+@item 12
+Z (depth) – homogeneous (distance to screen and angle of view must also be
specified in user-defined section)
+@end table
+
+Default value is @var{2}.
+
+@item clr @var{integer}
+Set the Colorimetric Specification as listed in Table 5B in SMPTE
268M-2003:
+
+@table @samp
+@item 0
+User Defined
+@item 1
+Printing Density
+@item 2
+Not applicable
+@item 3
+Not Applicable
+@item 4
+Unspecified Video
+@item 5
+SMPTE 274M
+@item 6
+ITU-R 709-4
+@item 7
+ITU-R 601-5 system B or G (625)
+@item 8
+ITU-R 601-5 system M (525)
+@item 9
+Composite video (NTSC); see SMPTE 170M
+@item 10
+Composite video (PAL); see ITU-R 624-4
+@item 11
+Not applicable
+@item 12
+Not applicable
+@end table
+
+Default value is @var{2}.
+
+@end table
+
 @section Hap

 Vidvox Hap video encoder.
diff --git a/libavcodec/dpxenc.c b/libavcodec/dpxenc.c
index a596033..3b0e890 100644
--- a/libavcodec/dpxenc.c
+++ b/libavcodec/dpxenc.c
@@ -24,15 +24,20 @@
 #include "libavutil/imgutils.h"
 #include "avcodec.h"
 #include "internal.h"
+#include "libavutil/opt.h"

 typedef struct DPXContext {
+AVClass *class;
 int big_endian;
 int bits_per_component;
 int num_components;
 int descriptor;
 int planar;
+int transfer_characteristic;
+int colorimetric_specification;
 } DPXContext;

+
 static av_cold int encode_init(AVCodecContext *avctx)
 {
 

[FFmpeg-devel] [PATCH] doc/filters: adds recently added -vf colorspace options

[Kieran O Leary]

Hi,

I've never submitted a patch for anything before, so hopefully this is OK.
I noticed that the recent commits by Vittorio Giovara were not reflected in
the filter documentation.

I'm attaching the output of git format-patch -1 as well as copy/pasting it
in this email.

>From c52eededc4a0e865a842fb9fb7c6057830429ef4 Mon Sep 17 00:00:00 2001
From: kieranjol 
Date: Wed, 16 Nov 2016 00:03:43 +
Subject: [PATCH] doc/filters: adds recently added -vf colorspace options

---
 doc/filters.texi | 36 
 1 file changed, 36 insertions(+)

diff --git a/doc/filters.texi b/doc/filters.texi
index 974febd..208be42 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -5335,6 +5335,9 @@ SMPTE-170M or BT.601-6 525
 @item smpte240m
 SMPTE-240M

+@item ycgco
+YCgCo
+
 @item bt2020ncl
 BT.2020 with non-constant luminance

@@ -5349,6 +5352,12 @@ The accepted values are:
 @item bt709
 BT.709

+@item bt470m
+BT.470M
+
+@item bt470bg
+BT.470BG
+
 @item gamma22
 Constant gamma of 2.2

@@ -5361,6 +5370,18 @@ SMPTE-170M, BT.601-6 625 or BT.601-6 525
 @item smpte240m
 SMPTE-240M

+@item srgb
+SRGB
+
+@item iec61966-2-1
+iec61966-2-1
+
+@item iec61966-2-4
+iec61966-2-4
+
+@item xvycc
+xvycc
+
 @item bt2020-10
 BT.2020 for 10-bits content

@@ -5390,6 +5411,15 @@ SMPTE-170M or BT.601-6 525
 @item smpte240m
 SMPTE-240M

+@item film
+film
+
+@item smpte431
+SMPTE-431
+
+@item smpte432
+SMPTE-432
+
 @item bt2020
 BT.2020

@@ -5401,9 +5431,15 @@ Specify output color range.

 The accepted values are:
 @table @samp
+@item tv
+TV (restricted) range
+
 @item mpeg
 MPEG (restricted) range

+@item pc
+PC (full) range
+
 @item jpeg
 JPEG (full) range

-- 
2.9.2.windows.1


0001-doc-filters-adds-recently-added-vf-colorspace-option.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavc/dpx: Support gray12

[Kieran O Leary]

Hi Carl,


On Fri, Nov 11, 2016 at 1:31 PM, Michael Niedermayer  wrote:

> On Thu, Nov 10, 2016 at 11:08:23PM +0100, Carl Eugen Hoyos wrote:
> > Hi!
> >
> > Not sure how useful this is but we also support gprp12.
> >
> > Please comment, Carl Eugen
>

I'm sure that this could be useful for film archives. I have never seen
12-bit GRAY DPX files in the wild. Would it be possible to share any test
files that you used to test this decoder?

Thanks,

Kieran.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/matroskaenc: use display aspect ratio for DisplayWidth and DisplayHeight when possible

[Kieran O Leary]

Hi

On 2 Nov 2016 10:15 p.m., "Carl Eugen Hoyos"  wrote:
>

> >
> > This fixes ticket #5743, implementing the suggestion from ticket #5903.
>
> Thank you for fixing this!
>
> Carl Eugen
>

+1 Thanks James!
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/3] vf_colorspace: Add support for smpte 431/432 (dci/display p3) primaries

[Kieran O Leary]

Hi,

On Sun, Oct 30, 2016 at 7:07 AM, Vittorio Giovara <
vittorio.giov...@gmail.com> wrote:

> Signed-off-by: Vittorio Giovara 
> ---
> I couldn't find any reference to the name of the whitepoint used for 431,
> so I came up with DCI, since it looks like it is only used there.
> Please CC.
>

Could this patch be used to convert XYZ Digital Cinema Packages to Rec.709?
I've found that converting a DCP to a YUV format in ffmpeg results in
colours and contrast that look different to how the image displays in
EasyDCP player or a cinema screen. IIRC, -vf colorspace doesn't accept XYZ
input, so is there some intermediate step that I could take to achieve this
kind of transformation, or have I just misunderstood the patch?

Best,

Kieran.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] avformat/matroskaenc: write a DisplayUnit element when aspect ratio is unknown

[Kieran O Leary]

Hi,

On Sat, Oct 15, 2016 at 11:09 PM, James Almer  wrote:

>
> -#sar 0: 1/1
> +#sar 0: 0/1
>

This commit looks very useful. A few archivists (including myself)
encountered this issue, so this is a wonderful contribution! Thanks James!

-Kieran.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] added expr evaluation to drawtext - fontsize

[Kieran O Leary]

Hi,

On Fri, Aug 26, 2016 at 10:37 PM, Brett Harrison
 wrote:
> Allows expr evaluation in the fontsize parameter for drawtext.

Thanks for making this. I regularly use drawtext to create
watermarked/timecoded access copies in a moving image archive and I
have to use workarounds in scripts in order to make relative font
sizes.

I'm not sure if this kind of 'thanks' email is against ffmpeg-devel
rules as I didn't see it listed here:
https://ffmpeg.org/contact.html#MailingLists

-Kieran.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] next Outreachy & GSoC ideas braindump [RFC]

[Kieran O Leary]

Hi

On 3 Aug 2016 6:58 p.m., "Michael Niedermayer" 
wrote:
>
> Hi all

>
> we need ideas for Outreachy, the page is EMPTY:
> https://trac.ffmpeg.org/wiki/SponsoringPrograms/Outreachy/2016-12
>

How about EBU-STL subtitle decoding? It's currently unsupported. It's a non
text based  subtitle format that is used in a broadcast environment. I'm
not sure if that is too specific to be of interest.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] Developer required for EBU-STL subtitle decoding support

[Kieran O Leary]

Hello,

I am looking for a time/money quote for someone to add EBU-STL
subtitle decoding to ffmpeg. I saw the list of available developers on
the ffmpeg website, but I wasn't sure who was best to contact.

I work for the IFI Irish Film Archive, and we receive EBU-STL
subtitles for AS-11 UKDPP broadcast deliverables. It would aid us
greatly if we had a CLI option to make access copies with burnt in
subtitles.

Best,

Kieran.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel