Please excuse my newbie knowledge of the code base BTW... I've just done a simple test
ffmpeg -color_range mpeg -i test_charts/test_encoding.tif -c dnxhd -vb 115M /quicktimes/ffmpeg_test.mov During this the vos_data contains... 00 00 02 80 01 01 80 A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 04 38 07 80 00 04 38 00 00 38 88 ... Which looks to me like the start of the VC3/DNxHD bit stream and in this case the code puts valid data in the header atoms. If I then fmpeg -i quicktimes/ffmpeg_test.mov -c copy quicktimes/ffmpeg_test_copy.mov the vos_data instead contains 00 00 00 18 41 43 4C 52 41 43 4C 52 30 30 30 31 00 00 00 01 00 00 00 00 00 00 00 18 41 50 52 47 41 50 52 47 ... which is the start of the Avid atoms from the incomming Quicktime. So I could peak into the stream and 'guess' based on the content being 0x00, 0x00, 0x02, 0x80, 0x01 that we are encoding and can trust the contents, else I could search through looking for the atom via the string "ARESARES" and then having located it I could assume to use that. The only oddball case is if it is not found, at that point the code needs to know if it is interlaced as well as the avid codec identifier, or maybe that is the point at which we 'give up' and fail with unsupported? Kevin _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
