[FFmpeg-devel] [PATCH] avformat: Add simple ACLR atom reading to set the color range
michaelni at gmx.at
Thu Feb 19 15:34:22 CET 2015
On Thu, Feb 19, 2015 at 11:25:34AM +0000, Kevin Wheatley wrote:
> V3 of the patch, I've attempted to include the general comments from the thread.
> New to this version, I've reworked the function that reads the atom
> into the extradata into one which calls 2 helper functions (one to
> realloc, one to read), I've then reused these functions to read the
> ACLR atom reliably.
> My ACLR reading function now calls these functions directly rather
> than via the mov_read_avid() function, this means that the atom will
> be used to set the range no matter which codec is used for the track
> (in the current code the mov_read_avid() function limits it to a
> restricted set pf codecs).
> I have not changed how the ACLR is used in the writer as it will still
> be found in the extradata buffer, this does mean that there maybe
> cases of 'none avid' codecs that now have the atom and when ouput
> could have modified behavior but I've never seen one of these files
> to test with.
> Thanks for any comments,
> mov.c | 108 +++++++++++++++++++++++++++++++++++++++++++++++++++---------------
> 1 file changed, 85 insertions(+), 23 deletions(-)
> 7bfa0af95a7485dfa468d94529b541847bd5177c 0001-Add-simple-ACLR-atom-reading-to-set-the-color-range-.patch
> From fe6216aec8592baaf40edaa61a73321161548009 Mon Sep 17 00:00:00 2001
> From: Kevin Wheatley <kevin.j.wheatley at gmail.com>
> Date: Thu, 19 Feb 2015 11:08:14 +0000
> 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.
> On input ACLR will be used to set colour range no matter which codec
> it is associated with.
> No change for when it will be output.
> Rework mov_read_extradata function to allow detection of truncated
> atom reads by callers.
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Awnsering whenever a program halts or runs forever is
On a turing machine, in general impossible (turings halting problem).
On any real computer, always possible as a real computer has a finite number
of states N, and will either halt in less than N cycles or never halt.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 181 bytes
Desc: Digital signature
More information about the ffmpeg-devel