On Thu, Apr 19, 2018 at 8:31 PM, James Almer <jamr...@gmail.com> wrote: > > > + film->sample_table[i].duration = AV_RB32(&scratch[12]); > > While for video tracks this field seems to report the same packet > durations that were being calculated pre patch, this field for audio > tracks is always 1. > > Before this patch a codec copy of the sample logo-capcom.cpk in the FATE > suite gave: > > 1, 0, 0, 22048, 44096, 0xafd250ae > 0, 2, 2, 2, 11080, 0xac3a462b > 0, 4, 4, 2, 11300, 0xd8ee7f3e > 0, 6, 6, 2, 21612, 0x73c3a3f9, F=0x0 > 0, 8, 8, 2, 21628, 0x00a5b4b9, F=0x0 > 0, 10, 10, 2, 14772, 0x1332b44f > 0, 12, 12, 2, 14744, 0x5ce5d59b > 0, 14, 14, 2, 14736, 0xd5ac2877 > 1, 22048, 22048, 11028, 22056, 0xe08a0f01 > > Whereas after applying it becomes: > > 1, 0, 0, 1, 44096, 0xafd250ae > 0, 2, 2, 2, 11080, 0xac3a462b > 0, 4, 4, 2, 11300, 0xd8ee7f3e > 0, 6, 6, 2, 21612, 0x73c3a3f9, F=0x0 > 0, 8, 8, 2, 21628, 0x00a5b4b9, F=0x0 > 0, 10, 10, 2, 14772, 0x1332b44f > 0, 12, 12, 2, 14744, 0x5ce5d59b > 0, 14, 14, 2, 14736, 0xd5ac2877 > 1, 22048, 22048, 1, 22056, 0xe08a0f01 > > For reference, decoding it always gives the following with or without > this patch: > > 0, 0, 0, 1, 215040, 0x067c5362 > 1, 0, 0, 22048, 88192, 0x23bb50ae > 0, 2, 2, 1, 215040, 0xd9eacb98 > 0, 4, 4, 1, 215040, 0x3c8a4cbd > 0, 6, 6, 1, 215040, 0xbdf996e1 > 0, 8, 8, 1, 215040, 0x1b7fa123 > 0, 10, 10, 1, 215040, 0x834b4a8d > 0, 12, 12, 1, 215040, 0xf4b1bebe > 0, 14, 14, 1, 215040, 0x088c3802 > 1, 22048, 22048, 11028, 44112, 0x79600f01 > > Is this change desired/intended?
This is actually intended; since that value is what's in the original container, it's what should get passed through, especially for stream copying back into a new FILM file. > > Also, unrelated to this patch, but as you can see decoding outputs one > extra video frame at the beginning that codec copy doesn't. this is > because packet keyframes are being set wrong: A 0 in the top bit of the > sample info dword on each sample table entry signals an Intra coded > frame, whereas 1 signals an Inter coded frame. The demuxer is assuming > the opposite. Here's a thread with context on the change to the intra setting: http://ffmpeg.org/pipermail/ffmpeg-devel/2018-March/227014.html The keyframe logic was intentionally inverted in cfe1a9d311de6c36641cf295004cdbc77d7b600c _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
