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? 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@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel