On Sun, 19 Feb 2012, Yusuke Nakamura wrote:
2012/2/19 Martin Storsjö <[email protected]>[mov,mp4,m4a,3gp,3g2,mj2 @ 03d22600] could not find corresponding track id 0 [mov,mp4,m4a,3gp,3g2,mj2 @ 03d22600] error reading header: -1094995529 This patch fails to open any ISOBMFF/QTFF with sdtp atom under stbl atom.
Ah, I'll fix that. Currently, this patch only uses this atom if it is within a traf, but it should just ignore it if it is found elsewhere. Can you share such a file?
sample_depends_on = 2 doesn't mean random accessible point (e.g. H.264 stream can contain non-RAP I-pictures).
Hmm, the spec says "2: this sample does not depend on others (I picture);" - doesn't that imply that it is randomly accessible as it doesn't depend on anything else?
How do you distinguish it from the issue for some ismv files?
The issue with the ismv files is that normally(?) keyframes in fragmented mp4 files are indicated via the sample flags.
For ismv files, the sample flags fields seem to follow some unwritten definition. Most ismv files have the sample flags 0x8002 for audio samples, 0x4002 for video keyframes and 0x4001 for non keyframes. (According to the specs, all these bits are part of sample_degradation_priority, but that really doesn't make any sense.) Some ismv files have the sample flags 0x4001 for all video samples, and some ismv files don't include sample flags at all.
All these files include sdtp atoms though, which seem to mark the keyframes just fine, where audio samples are marked as 0x28 (sample_depends_on=2, sample_is_depended_on=2), video keyframes as 0x24 (sample_depends_on=2, sample_is_depended_on=1) and video nonkeyframes as 0x14 (sample_depends_on=1, sample_is_depended_on=1).
Thus, setting the keyframe flag if sample_depends_on=2 seemed like a safe solution to me.
// Martin
_______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
