[FFmpeg-devel] What is the correct way to read Avid ACLR atom?

[Kevin Wheatley]

On Thu, Feb 5, 2015 at 4:24 PM, Carl Eugen Hoyos <cehoyos at ag.or.at> wrote:
> Kevin Wheatley <kevin.j.wheatley <at> 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 the atom in extradata would break
> remuxing.

ah, so the answer to my comment is quite clear now

> Did you test your patch? If it works, what
> advantage would the decoder patch(es) have?
> There would be a few iirc, no?


I assume there would need to be put in different files, as an example
of why I thought the mov decoder would be a good choice is that I am
not sure if DNxHD when wrapped in MXF has a similar choice of encoding
ranges - by default the typical Avid work flow is to use '709'
encoding range, but sometimes our clients want 'RGB'.

As to testing the patch, yes in a few ways, but not exhaustively -
mostly verifying ffprobe correctly outputs the encoding range on a
variety of files as well as outputting PNGs with the expected range
expansion on '709' content, but none on 'RGB' via ffmpeg -i
qt_dnxhd.mov blah.%04d.png.

I haven't looked at anything more fancy, although I did note that -c
copy does not propagate the colour_range but I've not looked at why.

Kevin