[FFmpeg-devel] libavformat/movenc.c: Correct color range when writing DNxHD atoms

[jon morley]

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 <michaelni at 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 <jon at 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 at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>