[FFmpeg-devel] What is the correct way to read Avid ACLR atom?

Hi, I've been looking at what the appropriate place and method to read in the ACLR atom placed in the Avid codecs so that we can automatically set the color_range. From my reading of the code the mov.c code the parse table shunts the reading of the atom to mov_read_avid(), which in turn calls

Re: [FFmpeg-devel] What is the correct way to read Avid ACLR atom?

On Thu, Feb 5, 2015 at 3:55 PM, wm4 nfx...@googlemail.com wrote: Seeing how the patch actually turned out, I'd say it should be in the decoder. It's not necessarily mp4 specific, or is it? In this case I'm exporting the QuickTimes from an Avid Media Composer so they are DNxHD in .mov, and in

Re: [FFmpeg-devel] What is the correct way to read Avid ACLR atom?

On Thu, Feb 5, 2015 at 4:24 PM, Carl Eugen Hoyos ceho...@ag.or.at wrote: Kevin Wheatley kevin.j.wheatley at gmail.com writes: +int ret = mov_read_avid(c, pb, atom); // should we do this or read the atom directly using avio_*() and not store it in extradata? Not storing the atom

[FFmpeg-devel] compile failure with -DDEBUG of HEAD

Whilst compiling with -DDEBUG I get the following... libavformat/rtpdec_h264.c: In function 'h264_handle_packet_stap_a': libavformat/rtpdec_h264.c:208: error: 'data' undeclared (first use in this function) libavformat/rtpdec_h264.c:208: error: (Each undeclared identifier is reported only once

Re: [FFmpeg-devel] compile failure with -DDEBUG of HEAD

This time with patch... On Mon, Feb 16, 2015 at 4:58 PM, Kevin Wheatley kevin.j.wheat...@gmail.com wrote: Whilst compiling with -DDEBUG I get the following... libavformat/rtpdec_h264.c: In function 'h264_handle_packet_stap_a': libavformat/rtpdec_h264.c:208: error: 'data' undeclared (first use

Re: [FFmpeg-devel] [PATCH] avformat: Add simple ACLR atom reading to set the color range

So reading through the comments in this thread, it looks to me like some of the problems come from the use of the mov_read_extradata() function, which has more logic than the name implies, in particular it will successfully return even if it did not read the atom into the extradata, so if i just

Re: [FFmpeg-devel] [PATCH] avformat: Add simple ACLR atom reading to set the color range

c48f8f2d74562e0e3ee9e6d496fc6a1c4320db14 Mon Sep 17 00:00:00 2001 From: Kevin Wheatley kevin.j.wheat...@gmail.com Date: Tue, 17 Feb 2015 11:47:47 + Subject: [PATCH] Add simple ACLR atom reading to set the color range of the incomming track for codec's like DNxHD that utilise AVID's proprietary atom. Added paranoia check

Re: [FFmpeg-devel] [PATCH] avformat: Add simple ACLR atom reading to set the color range

for any comments, Kevin From fe6216aec8592baaf40edaa61a73321161548009 Mon Sep 17 00:00:00 2001 From: Kevin Wheatley kevin.j.wheat...@gmail.com Date: Thu, 19 Feb 2015 11:08:14 + Subject: [PATCH] Add simple ACLR atom reading to set the color range of the incomming track for codec's like DNxHD

[FFmpeg-devel] Gaining access to a encoder context in avformat?

Hi, I realise this potentially breaks through lots of API boundaries/good taste, but I've noticed a case where the movenc.c code should really ask the specific encoder context (DNXHDEncContext) for some of it's fields to ensure that the atoms written have a consistent setting with what the codec

Re: [FFmpeg-devel] Gaining access to a encoder context in avformat?

On Fri, Feb 20, 2015 at 11:44 AM, Michael Niedermayer michae...@gmx.at wrote: If you start with a existing movie and copy the packets one by one there is no decoder and no encoder, so no dnxencoder structure if you want to put some value in the avid atom which are stored in the

Re: [FFmpeg-devel] Gaining access to a encoder context in avformat?

Please excuse my newbie knowledge of the code base BTW... I've just done a simple test ffmpeg -color_range mpeg -i test_charts/test_encoding.tif -c dnxhd -vb 115M /quicktimes/ffmpeg_test.mov During this the vos_data contains... 00 00 02 80 01 01 80 A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Re: [FFmpeg-devel] Gaining access to a encoder context in avformat?

Here is the kind of thing that this looks like... This is definitely NOT a patch :-) On Fri, Feb 20, 2015 at 1:22 PM, Michael Niedermayer michae...@gmx.at wrote: On Fri, Feb 20, 2015 at 12:35:59PM +, Kevin Wheatley wrote: Please excuse my newbie knowledge of the code base BTW... I've just

Re: [FFmpeg-devel] Why is writing the colr atom not the default in the mov muxer?

On Fri, Feb 20, 2015 at 1:30 PM, Robert Krüger krue...@lesspain.de wrote: if I read the code correctly, the colr atom is only written in the mov muxer if the flag write_colr is specified. Was that behaviour chosen to have better backward compatibility or is there another reason not to write

Re: [FFmpeg-devel] Gaining access to a encoder context in avformat?

On Fri, Feb 20, 2015 at 2:14 PM, Michael Niedermayer michae...@gmx.at wrote: On Fri, Feb 20, 2015 at 01:48:55PM +, Kevin Wheatley wrote: Here is the kind of thing that this looks like... This is definitely NOT a patch :-) i dont understand this patch there are at least two of us

[FFmpeg-devel] [PATCH] avformat: Add simple ACLR atom reading to set the color range

561db6b347bed1f60131c3eb2bebe890a402ad63 Mon Sep 17 00:00:00 2001 From: Kevin Wheatley kevin.j.wheat...@gmail.com Date: Tue, 17 Feb 2015 09:15:06 + Subject: [PATCH] Add simple ACLR atom reading to set the color range of the incomming track for codec's like DNxHD that utilise AVID's proprietary atom

Re: [FFmpeg-devel] [PATCH] avformat: Add simple ACLR atom reading to set the color range

On Tue, Feb 17, 2015 at 12:25 PM, Michael Niedermayer michae...@gmx.at wrote: if the codec id doesnt match the expected, mov_read_extradata will return 0 even without any truncation. In this case the error message would be incorrect So should I code the test against codec id against the files

[FFmpeg-devel] [PATCH] libavformat: DNxHD in .mov, switch unspecified color_range to mpeg

From 533523210ae02b80d4450793fd9e3865e716e858 Mon Sep 17 00:00:00 2001 From: Kevin Wheatley kevin.j.wheat...@gmail.com Date: Tue, 10 Feb 2015 11:37:00 + Subject: [PATCH] libavformat: DNxHD in .mov, switch unspecified color_range to mpeg Avid prefers mpeg range [16-235] by default this change

[FFmpeg-devel] avformat: QuickTime Sample Description Table 'corruption' with ACLR atom.

Hi, currently when writing ACLR atoms to .mov's there is a 'corruption' caused by the function mov_write_avid_tag() writing an additional 4 bytes of zero's. this is potentially then followed by other atoms colr and pasp. Looking at the specifications it appears this 4 bytes is supposed to occur

Re: [FFmpeg-devel] avformat: QuickTime Sample Description Table 'corruption' with ACLR atom.

OK I'll proceed with that. Thanks Kevin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] avformat: QuickTime Sample Description Table 'corruption' with ACLR atom.

On Fri, Feb 13, 2015 at 3:06 PM, Michael Niedermayer michae...@gmx.at wrote: On Fri, Feb 13, 2015 at 02:43:13PM +, Kevin Wheatley wrote: what difference does the terminator make ? does it improve compatibility with other software ? I believe there are some versions of Apple's Final Cut

Re: [FFmpeg-devel] avformat: QuickTime Sample Description Table 'corruption' with ACLR atom.

I've rebased the patch against current master, it is a lot of FATE changes due to the extra 4 bytes... It should now merge appropriately, see https://github.com/FFmpeg/FFmpeg/pull/110 Please let me know if anything needs tweaking Thanks Kevin ___

[FFmpeg-devel] [PATCH] avformat: Outputting DNxHD into .mov containers 'corrupts' following atoms until end of stsd

From b67ca5347a26227621054c82a688cc0ca44c11a1 Mon Sep 17 00:00:00 2001 From: Kevin Wheatley kevin.j.wheat...@gmail.com Date: Mon, 16 Feb 2015 10:40:36 + Subject: [PATCH] Outputting DNxHD into .mov containers 'corrupts' following atoms until end of stsd ffmpeg and qtdump could not decode pasp/colr

[FFmpeg-devel] [PATCH] optionally write QuickTime gama atom (was Re: Gamma function)

Updated to use lrint() On Mon, Mar 2, 2015 at 12:54 PM, Kevin Wheatley kevin.j.wheat...@gmail.com wrote: Something like this - note this adds no tests, but fate still passes for me. Kevin From 794c8c3cf1e8506393fbcb4ddf1360042b0fc82f Mon Sep 17 00:00:00 2001 From: Kevin Wheatley kevin.j.wheat

Re: [FFmpeg-devel] Gamma function (was Re: [PATCH] lavc/pngenc: Support writing colorspace tags.)

On Mon, Mar 2, 2015 at 12:17 PM, Michael Niedermayer michae...@gmx.at wrote: the various colorspace options should pass from decoder over the video filter chain to the encoder and then muxer its best to change them from the command line through a video filter, this also ensures that the value

Re: [FFmpeg-devel] Gamma function (was Re: [PATCH] lavc/pngenc: Support writing colorspace tags.)

Something like this - note this adds no tests, but fate still passes for me. Kevin From db02ae26c3c4278da4ed328e767bab98271da51e Mon Sep 17 00:00:00 2001 From: Kevin Wheatley kevin.j.wheat...@gmail.com Date: Mon, 2 Mar 2015 12:50:53 + Subject: [PATCH] Add 'gama' atom for .mov only, reuses

[FFmpeg-devel] Gamma function (was Re: [PATCH] lavc/pngenc: Support writing colorspace tags.)

On Sat, Feb 28, 2015 at 1:50 AM, Niklas Haas g...@nand.wakku.to wrote: +static int png_get_gama(enum AVColorTransferCharacteristic trc, uint8_t *buf) +{ +double gamma; +switch (trc) { +case AVCOL_TRC_BT709: +case AVCOL_TRC_SMPTE170M: +case

Re: [FFmpeg-devel] [PATCH] optionally write QuickTime gama atom (was Re: Gamma function)

Michael, wm4, Thank you for your feedback, I believe I've addressed your concerns, please let me know if there is anything else that needs fixing. Kevin From 079ff77a1885b5ef879a8cd3b4c032a3182e8e67 Mon Sep 17 00:00:00 2001 From: Kevin Wheatley kevin.j.wheat...@gmail.com Date: Thu, 5 Mar 2015 10

Re: [FFmpeg-devel] [PATCH] avformat: Outputting DNxHD into .mov containers 'corrupts' following atoms until end of stsd

On Fri, Feb 20, 2015 at 11:36 AM, Michael Niedermayer michae...@gmx.at wrote: applied the case for DNxHD, for the more general case, please explain which case(s) and software need them, and how to reproduce that My experience and by the looks of things other people using libquicktime have seen

Re: [FFmpeg-devel] Gaining access to a encoder context in avformat?

that appear to need the guard against overwriting, I'm attaching an updated patch for comments. Kevin From bd5543cd6a227e64e66eb5ac909e5efeddfeb3a8 Mon Sep 17 00:00:00 2001 From: Kevin Wheatley kevin.j.wheat...@gmail.com Date: Tue, 24 Feb 2015 10:00:07 + Subject: [PATCH] Using the copy codec ACLR atoms

Re: [FFmpeg-devel] [GSoC] Patch which adds support for gamma correct scaling

Pedro I understand the desire to 'degamma' images prior to scaling, I'd be interested in understanding how this could work with the colour_trc options rather than only assuming a simple gamma. Kevin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org

Re: [FFmpeg-devel] [GSoC] Patch which adds support for gamma correct scaling

I'll add that for some encodings filters with negative lobes will cause ringing no matter the direction up/down, especially true for higher dynamic range encodings like log and HDR options like SMPTE ST 2084 Kevin ___ ffmpeg-devel mailing list

Re: [FFmpeg-devel] [PATCH]Remove framerates from dnxhd encoder help

Though not definitive in terms of a specification: http://www.avid.com/static/resources/us/documents/dnxhd.pdf pages 9/10 has the table of options. Kevin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org

[FFmpeg-devel] Enhancing/extending OpenEXR 'gamma' feature

HI, I was wondering what others think about the option of extending the OpenEXR reader's gamma option to also include various transfer characteristic curves, potentially corresponding to the various AVCOL_TRC_* options, though I don't immediately have a need for all of them. In addition I could

Re: [FFmpeg-devel] Enhancing/extending OpenEXR 'gamma' feature

On Fri, Aug 28, 2015 at 3:54 PM, Paul B Mahol one...@gmail.com wrote: On 8/28/15, Kevin Wheatley kevin.j.wheat...@gmail.com wrote: Feel free to do it. Note however that those various curves really belong to avfilter once swscale supports float pixel format and exr decoder make use

[FFmpeg-devel] [PATCH] avutil: Add additional primaries and transfer characteristic enumerations from ITU-T Rec H.265

... Thoughts Kevin From 6190c0ee42fd2cb4ea1370111b46e03ea55459af Mon Sep 17 00:00:00 2001 From: Kevin Wheatley <kevin.j.wheat...@gmail.com> Date: Fri, 28 Aug 2015 15:20:22 +0100 Subject: [PATCH] Add additional primaries and transfer characteristic enumerations from ITU-T Rec H.265 Sign

Re: [FFmpeg-devel] [PATCH] avutil: Add additional primaries and transfer characteristic enumerations from ITU-T Rec H.265

I noticed that the output from actually tagging buffers with the new states needs patching as well, is there any other place I need to update? Kevin On Tue, Sep 1, 2015 at 9:39 AM, Kevin Wheatley <kevin.j.wheat...@gmail.com> wrote: > As a starting point for my work, I'm wonder

Re: [FFmpeg-devel] [PATCH] avutil: Add basic transfer functions for each AVColorTransferCharacteristic

On Tue, Sep 1, 2015 at 12:33 PM, Ronald S. Bultje <rsbul...@gmail.com> wrote: > Hi, > > On Tue, Sep 1, 2015 at 7:02 AM, Kevin Wheatley <kevin.j.wheat...@gmail.com> > wrote: > >> Following on from my previous email, this adds some functions to >> actually con

Re: [FFmpeg-devel] [PATCH] avutil: Add basic transfer functions for each AVColorTransferCharacteristic

On Tue, Sep 1, 2015 at 12:49 PM, wm4 wrote: > Identifiers starting with _ are reserved by the system on file scope. oh yes, switching between different programming languages never a good thing for my brain :-) Would the ffmpeg style be prefixing them up with anything, or

[FFmpeg-devel] [PATCH][RFC] libavformat/mov Extend metadata handling to read in the keys from the 'keys' atom

57feef09b636d8d80d3afe7dca20175ddb51 Mon Sep 17 00:00:00 2001 From: Kevin Wheatley <kevin.j.wheat...@gmail.com> Date: Thu, 3 Sep 2015 15:58:49 +0100 Subject: [PATCH] RFC: Extend metadata handling to read in the keys from the 'keys' atom --- libavformat/isom.h |1 + libavformat/mov.c

Re: [FFmpeg-devel] [PATCH][RFC] libavformat/mov Extend metadata handling to read in the keys from the 'keys' atom

On Thu, Sep 3, 2015 at 7:49 PM, Michael Niedermayer wrote: > missing checks for interger overflows of the addition and subtraction > > also the subject says "RFC", is there a reason not to push this to > git master once it otherwise looks good ? it is incomplete, basically I

[FFmpeg-devel] [PATCH] libavutil/dict: extend the list of convienience functions for storing different data types

34fedb67d58402b519a7c91bff7623469802c4c4 Mon Sep 17 00:00:00 2001 From: Kevin Wheatley <kevin.j.wheat...@gmail.com> Date: Fri, 4 Sep 2015 14:26:49 +0100 Subject: [PATCH] libavutil/dict: extend the list of convienience functions for storing different data types Signed-off-by: Kevin Wheatley <kevin.j.wheat...@

Re: [FFmpeg-devel] [PATCH] libavutil/dict: extend the list of convienience functions for storing different data types

On Fri, Sep 4, 2015 at 4:18 PM, wm4 <nfx...@googlemail.com> wrote: > On Fri, 4 Sep 2015 14:38:54 +0100 > Kevin Wheatley <kevin.j.wheat...@gmail.com> wrote: > >> Hi, >> >> as part of adding support for non-string data types to .mov metadata, >> I wondere

Re: [FFmpeg-devel] [PATCH][RFC] libavformat/mov Extend metadata handling to read in the keys from the 'keys' atom

91515aec2e964e0fb499378e31cd7782bf93482a Mon Sep 17 00:00:00 2001 From: Kevin Wheatley <kevin.j.wheat...@gmail.com> Date: Thu, 3 Sep 2015 15:58:49 +0100 Subject: [PATCH] avformat/mov: Extend metadata handling to read in the keys from the 'keys' atom Signed-off-by: Kevin Wheatley <kevin.j.wheat...@

Re: [FFmpeg-devel] [PATCH] avutil: Add basic transfer functions for each AVColorTransferCharacteristic

, Sep 1, 2015 at 1:03 PM, wm4 <nfx...@googlemail.com> wrote: > On Tue, 1 Sep 2015 12:55:49 +0100 > Kevin Wheatley <kevin.j.wheat...@gmail.com> wrote: > >> On Tue, Sep 1, 2015 at 12:49 PM, wm4 <nfx...@googlemail.com> wrote: >> > Identifiers starting with

[FFmpeg-devel] [PATCH] avcodec/exr/c Add support for applying a transfer characteristic curve to OpenEXR inputs.

will generate the appropriate file. Kevin From 25aedae9dc873abcba3a6db3dff503c64cd9e066 Mon Sep 17 00:00:00 2001 From: Kevin Wheatley <kevin.j.wheat...@gmail.com> Date: Tue, 1 Sep 2015 11:02:53 +0100 Subject: [PATCH 5/5] Add support for applying a transfer characteristic curve to OpenEXR

Re: [FFmpeg-devel] [PATCH] avcodec/exr/c Add support for applying a transfer characteristic curve to OpenEXR inputs.

This actually marks up the buffers as having the state given by the applied trc, Kevin On Tue, Sep 1, 2015 at 12:04 PM, Kevin Wheatley <kevin.j.wheat...@gmail.com> wrote: > This adds the actual usage and allows for command lines similar to this: > > ffmpeg -apply_trc bt709 -i l

[FFmpeg-devel] Support of QuickTime metadata atoms

Hi, I'm considering adding support for writing the QuickTime metadata atom structure to support arbitrary key value pairs, similar to those included by ARRI cameras see: https://developer.apple.com/library/prerelease/mac/documentation/QuickTime/QTFF/qtff.pdf p128 To start I was going to try

Re: [FFmpeg-devel] [PATCH] avfilter: add zscale filter

On Wed, Sep 30, 2015 at 9:49 AM, Paul B Mahol wrote: > +{ "range", "set color range", OFFSET(range), AV_OPT_TYPE_INT, > {.i64 = -1}, -1, ZIMG_RANGE_FULL, FLAGS, "range" }, > +{ "r", "set color range", OFFSET(range), AV_OPT_TYPE_INT, > {.i64 = -1},

Re: [FFmpeg-devel] avformat/mov: improve qt metadata reading and writing

On Thu, Jun 23, 2016 at 10:44 AM, Michael Niedermayer wrote: > that was maybe forgotten due to the rfc in the subject I never pushed for it as our internal requirement for the feature went away and I only try to push things we actually found useful :-) the patch probably

Re: [FFmpeg-devel] Avid DNxHR / UK DPP

On Tue, Jan 26, 2016 at 5:30 PM, John Warburton wrote: > I'm at DPP conference, in the room. Start of UHD delivery standards for UK > just announced. Now on website, we are told. https://www.digitalproductionpartnership.co.uk/what-we-do/technical-standards/

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

On Sun, Oct 30, 2016 at 1:18 PM, Ronald S. Bultje wrote: > Hmm... So, the wikipedia page https://en.wikipedia.org/wiki/DCI-P3 refers > to the two whitepoints here as DCI-P3 D65 and DCI-P3 Theater. Calling one > D65 and the other DCI seems confusing in that light (assuming the

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

I would really strongly suggest including DCI in the name at least - though nobody else would choose to use it for anything other than the reference calibration - most titles use a creative white different to that of the encoding reference (one that is less green). Kevin

Re: [FFmpeg-devel] [PATCH] libavcodec/exr: Fix blank output when data window != display window

No, just this kind. Behind the images when data = display window, the most common case OpenEXR file we have, is with a reduced data window that resides completely inside the display window, though this particular bug would impact any files where the value of ymax+1 is not equal to the height.

[FFmpeg-devel] [PATCH] libavcodec/exr: Fix blank output when data window != display window

included line rather than the line after the data window then the code sets the remaining lines to 0 and thus the whole image is over written. Fix by adjusting ptr to the correct line after decode_block returns Signed-off-by: Kevin Wheatley <kevin.j.wheat...@gmail.com> 0001-libavcodec-e

Re: [FFmpeg-devel] [PATCH] libavcodec/exr: Fix blank output when data window != display window

The following is a sample EXR that needs the patch to correctly process in FFmpeg. Kevin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/4] avformat/movenc: force colr atom for uncompressed yuv in mov

The guess work comes from this list: https://developer.apple.com/library/content/technotes/tn2162/_index.html#//apple_ref/doc/uid/DTS40013070-CH1-TNTAG10-SAMPLE__COLR__SETTINGS and I agree is the source of a lot of chaos, but it is what several tools have done in the absence of any specified

Re: [FFmpeg-devel] [PATCH] libavfilter/vf_libvmaf.c The libvmaf filter tried to join on an invalid thread id

Following up my own email with another question or so: Could somebody point me at a suitable method of testing this within the Fate framework? I've started to try unpick how the fate tests are run, etc What I need is a prototypical example which presumably would need to factor in (what I

[FFmpeg-devel] [PATCH] libavfilter/vf_libvmaf.c The libvmaf filter tried to join on an invalid thread id

Sep 17 00:00:00 2001 From: Kevin Wheatley <kevin.j.wheat...@gmail.com> Date: Mon, 30 Apr 2018 16:33:51 +0100 Subject: [PATCH] The libvmaf filter tried to join on an invalid thread id The thread id was invalid because it was not initialised during the calls to init_complex_filtergraph. Thi

Re: [FFmpeg-devel] [PATCH] libavfilter/vf_libvmaf.c The libvmaf filter tried to join on an invalid thread id

On Thu, May 3, 2018 at 12:38 PM, Ronald S. Bultje wrote: > Why? > > Your patch fixes a bug, I don't think we test bugs in fate, just features. I am perhaps making an incorrect assumption that the code has a bug because it is never tested and that by adding a test that simply

Re: [FFmpeg-devel] [PATCH] web/index: add news entry for release 4.1

On Wed, Nov 14, 2018 at 4:40 PM James Almer wrote: > +colorconstancy filter > +AVS2 video decoder via libdavs2 [snip] > +AVS2 video encoder via libxavs2 This line is in twice. Kevin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org

Re: [FFmpeg-devel] [PATCH] web/index: add news entry for release 4.1

OK, that makes sense I had wondered if it was a typo with d and x being close to each other on the keyboard. and might be better written as one line. Obviously not! Kevin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org

Re: [FFmpeg-devel] [RFC]lavc/mjpegenc_common: Fix aspect ratio

I came across a similar discussion here: https://github.com/OpenImageIO/oiio/pull/1412 Kevin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [RFC]lavc/mjpegenc_common: Fix aspect ratio

I guess it depends if you think that it is better to align with defacto behaviour (and maybe clarify/correct the specifications) or follow the specs and have users grumble about not matching the behaviour of 'applications X, Y and Z', I'm pretty certain Photoshop won't easily change its behaviour.

Re: [FFmpeg-devel] [PATCH] colorspace: Rename jedec-p22 to ebu3213

On Fri, Aug 9, 2019 at 12:40 PM Hendrik Leppkes wrote: > The enum and our values are aligned to the H.273 / ISO/IEC 23001-8 > standards, which documents this entry to correspond to the primaries > in use by vf_colorspace That makes sense, although I'm now interested to find out where those

Re: [FFmpeg-devel] [PATCH] colorspace: Rename jedec-p22 to ebu3213

Is there a change to include the EBU primaries? https://tech.ebu.ch/docs/tech/tech3213.pdf White 0.313 0.329 Red 0.64 0.33 Green 0.29 0.60 Blue 0.15 0.06 as the ones currently called AVCOL_PRI_JEDEC_P22 are not those ones at least in vf_colorspace.c [AVCOL_PRI_JEDEC_P22] = { WP_D65, {

Re: [FFmpeg-devel] avfilter/vf_ciescope: add DCI-P3

Just a query, but I note that the gamma says 'GAMMA_REC709', this is not the normal gamma I'd expect for a DCI P3 image, it would typically be 2.6, so for correct translation into chromaticities, you would need to use that to convert to linear RGB. It is also not the only option for encoding the

[FFmpeg-devel] [PATCH] avformat/movenc: Support for variable timescale in mov containers

at_600.mov ffprobe smpte_concat_600.mov The durations all line up, the stts table is smaller and no rounding issues occur. Kevin Wheatley (2): avformat/movenc: Add command line option to set base mov file timescale avformat/movenc: Use base container timescale, instead of hard coded d

[FFmpeg-devel] [PATCH v2 0/3] avformat/movenc: Support for variable timescale in mov containers

at_600.mov ffprobe smpte_concat_600.mov The durations all line up, the stts table is smaller and no rounding issues occur. Kevin Kevin Wheatley (3): avformat/movenc: Add command line option to set base mov file timescale avformat/movenc: Use base container timescale, instead of hard

Re: [FFmpeg-devel] [PATCH] avformat/movenc: Support for variable timescale in mov containers

On Tue, Nov 5, 2019 at 4:52 PM Michael Niedermayer wrote: > Assuming this doesnt violate any specifications and assuming that > it works with all players. > Then it would make sense to select this value automatically based > on the stream timestamps or timebases. > maybe there could be still a

Re: [FFmpeg-devel] [PATCH] avcodec/exr: add cineon lin2log trc

On Fri, Mar 6, 2020 at 10:19 AM Hendrik Leppkes wrote: > AVColorTransferCharacteristic should follow ISO/IEC 23001-8 and its > following standards (ISO/IEC 23091 I believe). Not sure we have a > solution for specialized variants, but adding one right there would > collide with the next addition

[FFmpeg-devel] [PATCH 3/3] avformat/movenc: Add an automatic timescale computation

and combines the video stream time bases to compute an accurate answer if possible. In cases when the first stream result falls outside MOV_MAX_AUTO_TIMESCALE or if a non-integer video stream is encounted, then the first stream's time_base will be used as the base. Signed-off-by: Kevin Wheatley

[FFmpeg-devel] [PATCH 2/3] avformat/movenc: Use base container timescale, instead of hard coded default

Signed-off-by: Kevin Wheatley --- libavformat/movenc.c | 22 +++--- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/libavformat/movenc.c b/libavformat/movenc.c index 7d79eca..508fa73 100644 --- a/libavformat/movenc.c +++ b/libavformat/movenc.c @@ -2879,7 +2879,7

[FFmpeg-devel] [PATCH v3 0/3] avformat/movenc: Support for variable timescale in mov containers

table is smaller and no rounding issues occur. Kevin Kevin Wheatley (3): avformat/movenc: Add command line option to set base mov file timescale avformat/movenc: Use base container timescale, instead of hard coded default avformat/movenc: Add an automatic timescale computation libav

[FFmpeg-devel] [PATCH 1/3] avformat/movenc: Add command line option to set base mov file timescale

Signed-off-by: Kevin Wheatley --- libavformat/movenc.c | 1 + libavformat/movenc.h | 1 + 2 files changed, 2 insertions(+) diff --git a/libavformat/movenc.c b/libavformat/movenc.c index 253cff8..7d79eca 100644 --- a/libavformat/movenc.c +++ b/libavformat/movenc.c @@ -91,6 +91,7 @@ static const

Re: [FFmpeg-devel] [PATCH] avfilter/vf_scale: set RGB to always be full range

On Wed, Sep 16, 2020 at 9:43 PM Jan Ekström wrote: > > On Wed, Sep 16, 2020 at 11:38 PM Michael Niedermayer > wrote: > > Does anything document the meaning of range or AVCOL_RANGE for RGB ? > > The enum is documented as "MPEG vs JPEG YUV range." > > > > What is limited range RGB ? what would the

Re: [FFmpeg-devel] [PATCH] libavutil/cpu: Fix definition of _GNU_SOURCE so it occurs before other includes

On Mon, Apr 12, 2021 at 12:22 PM wrote: > > From: Kevin Wheatley > > This fix moves the potential definition of _GNU_SOURCE prior to > any includes of system header files as required by the documentation > https://www.gnu.org/software/libc/manual/html_node/Featur

Re: [FFmpeg-devel] [PATCH] movenc: add movie_timescale option instead of hardcoding 1000

This is quite similar to my patch suggestion from last year: http://ffmpeg.org/pipermail/ffmpeg-devel/2020-April/261088.html mine was missing some docs updates, and I followed the existing naming scheme of prefixing the argument as 'mov_' rather than movie, but otherwise is quite similar Kevin

Re: [FFmpeg-devel] [PATCH 2/2] Require compilers to support C17.

On Fri, Feb 9, 2024 at 11:22 AM Dominik 'Rathann' Mierzejewski wrote: > Even so, a C17-supporting compiler (gcc 11.2.1) is available for CentOS 7 > in the devtoolset-11-gcc package (from > http://mirror.centos.org/centos/7/sclo/x86_64/rh/). As a 'User' of the FFmpeg project, we have a lot of