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 Cent
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
_
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/Feature-Test-Ma
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
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
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 Whe
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 coded
default
avformat/movenc: Add an automatic timescale comp
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
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 to
smpte_concat_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, inste
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 -mo
smpte_concat_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 c
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
number
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, { 0.630
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 ou
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.
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
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
http://ffmpeg.org/mailman/lis
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
htt
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 tries
to use it, the
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 figured
Sep 17 00:00:00 2001
From: Kevin Wheatley
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.
This adds a flag to check for
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 valu
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.
Kev
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
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
0001-libavcodec-exr-Fix-blank-output-when-data-window
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
__
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 wikipedia
> page is c
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 won't merge cleanly now a
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/
http://dpp-assets.s3.amazonaws.com/wp-
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}, -1, ZIMG_RANGE_FUL
Kevin
From 91515aec2e964e0fb499378e31cd7782bf93482a Mon Sep 17 00:00:00 2001
From: Kevin Wheatley
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
---
libavformat/isom.h |1 +
libav
On Fri, Sep 4, 2015 at 4:18 PM, wm4 wrote:
> On Fri, 4 Sep 2015 14:38:54 +0100
> Kevin Wheatley wrote:
>
>> Hi,
>>
>> as part of adding support for non-string data types to .mov metadata,
>> I wondered about adding the following helper functions for storing
>
at all.
Kevin
From 34fedb67d58402b519a7c91bff7623469802c4c4 Mon Sep 17 00:00:00 2001
From: Kevin Wheatley
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
---
libavu
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 was fishing for a ge
tage/
Thanks
Kevin
From 57feef09b636d8d80d3afe7dca20175ddb51 Mon Sep 17 00:00:00 2001
From: Kevin Wheatley
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
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 add
, Sep 1, 2015 at 1:03 PM, wm4 wrote:
> On Tue, 1 Sep 2015 12:55:49 +0100
> Kevin Wheatley wrote:
>
>> 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 differen
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 just
leaving off the und
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
wrote:
> This adds the actual usage and allows for command lines similar to this:
>
> ffmpeg -apply_trc bt709 -i linear.exr bt709.png
> ffmpe
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
wrote:
> As a starting point for my work, I'm wondering about the naming of
> these opt
On Tue, Sep 1, 2015 at 12:33 PM, Ronald S. Bultje wrote:
> Hi,
>
> On Tue, Sep 1, 2015 at 7:02 AM, Kevin Wheatley
> wrote:
>
>> Following on from my previous email, this adds some functions to
>> actually convert from linear to non-linear encoding. I have another
will
generate the appropriate file.
Kevin
From 25aedae9dc873abcba3a6db3dff503c64cd9e066 Mon Sep 17 00:00:00 2001
From: Kevin Wheatley
Date: Tue, 1 Sep 2015 11:02:53 +0100
Subject: [PATCH 5/5] Add support for applying a transfer characteristic curve to OpenEXR inputs.
Signed-off-by: Kevin Wheatley
Following on from my previous email, this adds some functions to
actually convert from linear to non-linear encoding. I have another
that changes the OpenEXR codec to actually use these.
Kevin
From 59299c23489fadeb11330b51f83b152194f0810e Mon Sep 17 00:00:00 2001
From: Kevin Wheatley
Date: Tue
underscore...
Thoughts
Kevin
From 6190c0ee42fd2cb4ea1370111b46e03ea55459af Mon Sep 17 00:00:00 2001
From: Kevin Wheatley
Date: Fri, 28 Aug 2015 15:20:22 +0100
Subject: [PATCH] Add additional primaries and transfer characteristic enumerations from ITU-T Rec H.265
Signed-off-by: Kevi
On Fri, Aug 28, 2015 at 3:54 PM, Paul B Mahol wrote:
> On 8/28/15, Kevin Wheatley 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 of it.
Absolutely, most of the t
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 s
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
http://ffmpeg.org/mailman/listinfo/ffmpeg-de
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
ffmpeg-dev
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
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
Date: Thu, 5 Mar 2015 10:37:51 +
Su
Updated to use lrint()
On Mon, Mar 2, 2015 at 12:54 PM, Kevin Wheatley
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
Date: Mon, 2 Mar 2015 12:50
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
Date: Mon, 2 Mar 2015 12:50:53 +
Subject: [PATCH] Add 'gama' atom for .mov only, reuses pngenc.c gamma
On Mon, Mar 2, 2015 at 12:17 PM, Michael Niedermayer 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 reaching the
On Sat, Feb 28, 2015 at 1:50 AM, Niklas Haas 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 AVCOL_TRC_SMPTE240M:
> +
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
Date: Tue, 24 Feb 2015 10:00:07 +
Subject: [PATCH] Using the copy codec ACLR atoms are incorrectly written
On Fri, Feb 20, 2015 at 11:36 AM, Michael Niedermayer 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 issues with F
On Fri, Feb 20, 2015 at 2:14 PM, Michael Niedermayer wrote:
> On Fri, Feb 20, 2015 at 01:48:55PM +0000, 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
On Fri, Feb 20, 2015 at 1:30 PM, Robert Krüger 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
> this standard atom
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 wrote:
> On Fri, Feb 20, 2015 at 12:35:59PM +0000, Kevin Wheatley wrote:
>> Please excuse my newbie knowledge of the code base BTW...
>>
>
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
On Fri, Feb 20, 2015 at 11:44 AM, Michael Niedermayer 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
> bitstream/packets of dnxhd
Sent on the go...
> On 19 Feb 2015, at 18:35, Michael Niedermayer wrote:
>
> theres no encoder, the data could instead come from another mov
> file or a binary encoder used by some user application with
> libavformat
Michael,
Thanks for your response, I must be confused then. What I thought
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 d
Thanks, just a reminder that reading ffmpeg generated DNxHD in .mov
won't work without a variant of my other patch, which correctly places
the padding in the stsd atom, I'll pull the latest master and rebase
to make sure it still holds.
Kevin
___
ffmpeg-
se files
to test with.
Thanks for any comments,
Kevin
From fe6216aec8592baaf40edaa61a73321161548009 Mon Sep 17 00:00:00 2001
From: Kevin Wheatley
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&#x
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 di
On Tue, Feb 17, 2015 at 12:25 PM, Michael Niedermayer 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 I have or
the
From c48f8f2d74562e0e3ee9e6d496fc6a1c4320db14 Mon Sep 17 00:00:00 2001
From: Kevin Wheatley
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 for memo
pt'
files.
From 561db6b347bed1f60131c3eb2bebe890a402ad63 Mon Sep 17 00:00:00 2001
From: Kevin Wheatley
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 proprietar
This time with patch...
On Mon, Feb 16, 2015 at 4:58 PM, Kevin Wheatley
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' undeclar
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
liba
From b67ca5347a26227621054c82a688cc0ca44c11a1 Mon Sep 17 00:00:00 2001
From: Kevin Wheatley
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 atoms in the
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
___
ffmp
OK I'll proceed with that.
Thanks
Kevin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On Fri, Feb 13, 2015 at 3:06 PM, Michael Niedermayer wrote:
> On Fri, Feb 13, 2015 at 02:43:13PM +0000, 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
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 at
From 533523210ae02b80d4450793fd9e3865e716e858 Mon Sep 17 00:00:00 2001
From: Kevin Wheatley
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 brings
ffmpeg into line
On Tue, Feb 10, 2015 at 10:34 AM, Michael Niedermayer wrote:
> if theres no way to store unknown range then your suggestion sounds
> reasonable, can you send a patch?
I'm not aware of a value to specify in the ACLR atom for unspecified -
I could guess at a value of 0 but that is pure speculation,
Hi,
Just looking through the FATE tests and the changes I wanted to make
on reading ACLR atoms and I came across an issue. I wondered what the
expected encoding range is for Y'CbCr during the FATE test runs as
well as more generally.
It would appear that the assumption that the range should be
AV
On Thu, Feb 5, 2015 at 4:24 PM, Carl Eugen Hoyos wrote:
> Kevin Wheatley 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
On Thu, Feb 5, 2015 at 3:55 PM, wm4 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 .mp4 with both 'RGB' a
Hi,
so I had a quick go at this but I'm still not sure on the preferred
way of reading this, should I read the atom directly and not put the
data in extradata?
Obviously this doesn't include fixing up the fate data
Thanks
Kevin
On Wed, Feb 4, 2015 at 11:51 AM, Kevin Wheatley
w
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
mo
On Tue, Jan 27, 2015 at 9:27 PM, Michael Niedermayer wrote:
> On Tue, Jan 27, 2015 at 11:15:40AM -0800, jon morley wrote:
>> movenc.c |9 ++---
>> 1 file changed, 6 insertions(+), 3 deletions(-)
>> 6317011578bca8bf065f5bd4de2dfce803557e81
>> 0001-libavformat-movenc.c-Correct-color-range
85 matches
Mail list logo
