On Thu, Feb 5, 2015 at 4:24 PM, Carl Eugen Hoyos <ceho...@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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
