Skip to content

TIKA-4777: Expose presentation start of delayed QuickTime timed metadata tracks#2936

Open
dschmidt wants to merge 1 commit into
apache:mainfrom
dschmidt:mp4-still-image-time
Open

TIKA-4777: Expose presentation start of delayed QuickTime timed metadata tracks#2936
dschmidt wants to merge 1 commit into
apache:mainfrom
dschmidt:mp4-still-image-time

Conversation

@dschmidt

@dschmidt dschmidt commented Jul 9, 2026

Copy link
Copy Markdown
Contributor

JIRA: https://issues.apache.org/jira/browse/TIKA-4777

Builds on the QuickTime metadata support from #2935 (TIKA-2861, now
merged); rebased onto main accordingly, a single commit.

QuickTime timed metadata tracks (mebx sample descriptions, ISO 14496-12
boxed metadata) declare their key names in the file, and a track's
presentation start is defined by its edit list: a leading empty edit
delays the media by its duration. This parses the mebx key declarations
(keys/keyd) and emits, for every declared key of a delayed track, the
presentation start in microseconds as <key name>.track-start-us.
Undelayed tracks are not reported, their start carries no information.

No key names are hardcoded. The main use case are Apple Live Photos,
which mark the moment the paired still image was captured as the single
one-tick sample of the com.apple.quicktime.still-image-time track,
shifted there by an empty edit. The sample value itself is a constant -1
marker, so the moov boxes alone are sufficient and mdat is never read.
Apple's own LivePhotosKit JS player derives its photoTime the same way
(it parses trak/elst/mebx client-side).

Verified against a real Live Photo video (iPhone 15 Pro, iOS 18.5):
com.apple.quicktime.still-image-time.track-start-us = 1233333 (1.2333s,
matching the empty edit of 740/600s), likewise the transform keys
declared by the same track; the undelayed video-orientation and
live-photo-info tracks are not reported.

Testing: the crafted testMP4_QuickTimeMetadata.mov fixture gains a
timed metadata track with a proper mebx keys/keyd declaration and an
empty edit; MP4ParserTest asserts the emitted track start.

…data tracks

QuickTime timed metadata tracks (mebx sample descriptions, ISO 14496-12
boxed metadata) declare their key names in the file, and the track's
presentation start is defined by its edit list: a leading empty edit
delays the media by its duration. Parse the mebx key declarations
(keys/keyd) and emit, for every declared key of a delayed track, the
presentation start in microseconds as <key name>.track-start-us.
Undelayed tracks (start 0) are not reported, their start carries no
information.

This is deliberately generic, no key names are hardcoded. The main use
case are Apple Live Photos, which mark the moment the paired still
image was captured as the single one-tick sample of the
still-image-time track, shifted to that moment by an empty edit. The
sample value itself is a constant -1 marker, so the moov boxes alone
are sufficient and mdat is never touched.

The handler stays active for timed metadata tracks (handler type
'meta') instead of switching to the extraction-free Mp4MetaHandler,
which would keep it from seeing the track's stsd.

Verified against a real Live Photo video (iPhone 15 Pro, iOS 18.5):
com.apple.quicktime.still-image-time.track-start-us = 1233333 (1.2333s,
matching the empty edit of 740/600s), likewise the transform keys of
the same track; the undelayed video-orientation and live-photo-info
tracks are not reported.
@dschmidt dschmidt marked this pull request as ready for review July 9, 2026 11:12
@dschmidt dschmidt force-pushed the mp4-still-image-time branch from 9ae502f to 3820b30 Compare July 9, 2026 11:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant