[FFmpeg-devel] [PATCH v4] avformat/mxfdec: Read video range from PictureDescriptor

Harry Mallon harry.mallon at codex.online
Sun Aug 16 13:43:31 EEST 2020




> On 14 Aug 2020, at 22:33, Harry Mallon <harry.mallon at codex.online> wrote:
> 
> 
> 
> 
>> On 14 Aug 2020, at 11:53, Tomas Härdin <tjoppen at acc.umu.se> wrote:
>> 
>> tor 2020-08-13 klockan 22:21 +0200 skrev Marton Balint:
>>> 
>>> On Thu, 13 Aug 2020, Tomas Härdin wrote:
>>> 
>>>> tor 2020-08-13 klockan 11:04 +0100 skrev Harry Mallon:
>>>>> Here is an updated patch (now hopefully going with correct email headers).
>>>> 
>>>> It would be nice if in the future you either attach the patch or make
>>>> the entire email the patch itself. I've had to trim these first couple
>>>> of lines in each of the patches so far, after doing "git am" on the
>>>> .mbox from saving your messages
>>>> 
>>>>> From 5866d0dc5536a6ea3f6a899c3d09f19df083c16a Mon Sep 17 00:00:00 2001
>>>>> 
>>>>> From: Harry Mallon <harry.mallon at codex.online>
>>>>> Date: Wed, 12 Aug 2020 10:26:23 +0100
>>>>> Subject: [PATCH v4] avformat/mxfdec: Read video range from PictureDescriptor
>>>>> 
>>>>> * Capture black_ref, white_ref and color_range and recognise
>>>>> full and narrow range.
>>>>> 
>>>>> Signed-off-by: Harry Mallon <harry.mallon at codex.online>
>>>>> ---
>>>>> libavformat/mxfdec.c           | 29 +++++++++++++++++++++++++++++
>>>>> tests/ref/fate/mxf-probe-dnxhd |  2 +-
>>>>> tests/ref/fate/mxf-probe-dv25  |  2 +-
>>>>> 3 files changed, 31 insertions(+), 2 deletions(-)
>>>> 
>>>> Looks good to me. Running FATE atm, will push in a day if there are no
>>>> objections.
>>> 
>>> http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket4328/01_Bad_Frame_2.24.mxf 
>>> is not detected correctly for some reason.
>>> 
>>> The MXF specs seems ambigous:
>>> 
>>> Color Range is a Property, whose unsigned 32-bit integer value shall 
>>> specify the number of distinct values allowed for color difference 
>>> samples.
>>> 
>>> So probably 2^depth color range should also be accepted as full range.
>> 
>> This sounds correct. Do we have any sample using 2^depth-1? If not then
>> we should just go with 2^depth until such a sample emerges.
>> 
>> /Tomas
> 
> I based it on what mxfenc.c already did, I can try to find some other samples.
> 
> Harry
> 
>> 

OK, I have checked back with the docs. 

* I agree that 2^depth is correct for mxf color_range 
* 2^depth-1 has been used in FFMPEG since n4.1 (avformat/mxfenc: add white/black ref /color range 6d0339096e10f6753049f2a5cbfd7ba69e5f8bcd) so maybe we should keep the off-by-one case, I don't mind either way.

I was checking some other MXF files I have here and one is full-range RGB J2K, rather than YUV. There are separate range metadata in RGBAEssenceDescriptor compared to CDCIEssenceDescriptor. Is there a way to get the stream component depth from this area of code (as RGBA only has component_max and component_min, no component_depth like CDCI) or somehow to pass the min/max to the codec to parse?

e.g in my file (RGB J2K with RGBAEssenceDesc) component_max is 4095 and component_min is 0, but I don't think the pixel format has been set to 12bit yet so it would seem premature to set the range to full.

Harry




More information about the ffmpeg-devel mailing list