[FFmpeg-devel] [PATCH] avformat: Add simple ACLR atom reading to set the color range

[Michael Niedermayer]

On Wed, Feb 18, 2015 at 09:40:24AM +0000, Kevin Wheatley wrote:
> So reading through the comments in this thread, it looks to me like
> some of the problems come from the use of the mov_read_extradata()
> function, which has more logic than the name implies, in particular it
> will successfully return even if it did not read the atom into the
> extradata, so if i just directly read the atom, what will break? I
> could do the ugly thing of reading it and then filling the extradata
> (or modify the reading function to better communicate to the callers
> if the data was read correctly).
> 
> The atom could also not be in the extradata but does it have to be?

its probably best to leave it in extradata for codecs which
expect/use it.
Otherwise i think its best if the demuxer extracts the data and sets
the fields like color_range based on it and the muxer creates the
atom again from that. That is if no information is lost that way.
This should also allow some interoperability between mov and other
containers which would not produce for example mjpeg with
such atom


> 
> The movenc.c writer of the atom doesn't always use the extradata - for
> DNxHD relies on the colour_range of the track's encoder directly and
> doesn't appear to write the extradata (calls mov_write_avid_tag()),
> for other codecs it uses mov_write_extradata_tag() (for
> AV_CODEC_ID_AVU and AV_CODEC_ID_SVQ3).
> 
> This suggests that for DNxHD I don't need it in the extradata to
> preserve behaviour, or am I missing something in the code (something
> in the use as a library for instance)?
> 
> Thanks
> 
> Kevin
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

While the State exists there can be no freedom; when there is freedom there
will be no State. -- Vladimir Lenin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20150218/6e5ffd6c/attachment.asc>