Hi Kevin, Michael,
I appreciate your replies. I have been having a really hard time finding
a definitive reference on the matter. So far all I have are a handful of
customer sample files created from various sources including some Avid
products. The reason I finally made the patch was because the (dead)
libquicktime and (dying/dead) Apple's QuicktTime 7 libraries have the
opposite interpretation. My plan was to continue searching for a
reference on the matter before replying.
If you have a way to ask Avid that would obviously be the best. Though
it seems like their QuickTime component for QuickTime 7 is making files
with the opposite values of ffmpeg at the moment. I will continue my
testing/searching as well.
Thanks guys!
On 1/28/15 12:44 AM, Kevin Wheatley wrote:
On Tue, Jan 27, 2015 at 9:27 PM, Michael Niedermayer <michae...@gmx.at> 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-when-writin.patch
From 0097277471810ab1d9d737c64a57c2278a039153 Mon Sep 17 00:00:00 2001
From: Jon Morley <j...@tweaksoftware.com>
Date: Tue, 27 Jan 2015 11:10:27 -0800
Subject: [PATCH] libavformat/movenc.c: Correct color range when writing DNxHD
atoms
The meaning of the color range values in the AVdn.ACLR atom was swapped.
This change makes the selection explicit and correctly mapped.
---
libavformat/movenc.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
breaks "make fate"
you need to update the checksums
also please explain in the commit message what referece you used to
know which is the correct value
Jon, Michael,
this may or may not be the correct setting, I've generated a few
different range encodings from different apps and found there is some
inconsistency (who'd have thought QuickTime could be ambiguous) in
what different apps do, I thought that the values might need to be
switched too, however files generated with an Avid appear to suggest
ffmpeg's current behavior might be correct (for encoding). I'm going
to try get some form of official statement/info direct from Avid, mean
while I'm going to go find a few more encoders from third parties and
see what they do.
Kevin
_______________________________________________
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
