[
https://issues.apache.org/jira/browse/TIKA-4869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18110449#comment-18110449
]
ASF GitHub Bot commented on TIKA-4869:
--------------------------------------
dschmidt opened a new pull request, #3115:
URL: https://github.com/apache/tika/pull/3115
A motion photo carries a short video after the image, and Tika already reads
the XMP that says where it is, but not the video itself.
Two formats, one arithmetic: a Motion Photo lists its parts in
`Container:Directory`, the primary image first and the rest tightly packed
after it, each with an `Item:Length` and an optional `Item:Padding`; the older
MicroVideo gives `Camera:MicroVideoOffset`, the number of bytes from the end of
the file to the start of the video. Either way the video ends at the end of the
file, so its start follows from its length.
The image parsers emit it as an ATTACHMENT embedded document named
`motion-photo.<ext>`, parsed like any other embedded document. Since the same
XMP goes through the same extractor for HEIC and AVIF motion photos, and their
video sits in a trailing `mpvd` box whose 8 byte header is the primary item's
padding, the same computation covers those too; I have no sample file to prove
it with.
What is at the computed offset is typed by content, without the declared
`Item:Mime` as a hint: a hint would let a wrong length pass as a video, since
the mime magic returns the hint when it recognizes nothing. Nothing is emitted
when the length does not fit the file or when detection recognizes nothing
there, and the image records why. That case is not exotic: sharing a motion
photo out of the Android gallery leaves the flag and takes the video, which the
tests cover with a file that Google Photos would produce.
The name comes from the declared `Item:Mime` where the format has one. A
MicroVideo does not, so its video is named from detection, which today makes it
`motion-photo.qt`: Tika's magic for video/mp4 only matches the brands mp41 and
mp42, and a phone writes isom. #3114 fixes that detection, and with it in place
both formats name the video `motion-photo.mp4`. The two changes are independent
otherwise.
The two test files declared a video in their XMP without carrying one; they
now hold a small real MP4, and a third one covers the shared-without-video case.
Verified on a server built from this branch: both files answer with the
video as an embedded document, `/unpack` returns its bytes unchanged, a plain
JPEG is untouched, and a truncated file yields no embedded document but a
warning.
https://issues.apache.org/jira/browse/TIKA-4869
> Emit the video of a motion photo as an embedded document
> --------------------------------------------------------
>
> Key: TIKA-4869
> URL: https://issues.apache.org/jira/browse/TIKA-4869
> Project: Tika
> Issue Type: Improvement
> Reporter: Dominik Schmidt
> Priority: Major
>
> Tika exposes the Motion Photo and MicroVideo XMP of Google/Android motion
> photos, but not the video itself, although both formats say where it is and
> every byte of it is already in the file.
> The MP4 is appended after the JPEG:
> - Motion Photo (Camera:MotionPhoto): Container:Directory lists the items in
> file order, the primary image first, the rest tightly packed after it, each
> with an Item:Length and an optional Item:Padding. The video starts at
> fileLength minus the lengths of the items from the video to the end; in
> practice it is the last one, also in Ultra HDR files, where the spec puts the
> gain map before it.
> - MicroVideo (the older Camera:MicroVideo / GCamera): Camera:MicroVideoOffset
> is the number of bytes from the end of the file, so the video starts at
> fileLength minus that value.
> Proposal: the image parsers emit those bytes as an embedded document,
> ATTACHMENT, named motion-photo.<ext>. What is at the computed offset is
> detected by content, without the declared Item:Mime as a hint (a hint would
> make a wrong length pass as video/mp4 anyway), and nothing is emitted when
> detection finds no type: a wrong or hostile length then yields no embedded
> document rather than a bogus one. Extraction follows the usual embedded
> document limits; a client that does not want the video filters by type as
> usual.
> The same computation covers HEIC and AVIF motion photos, whose XMP goes
> through the same extractor: there the video sits in an mpvd box, but that box
> is last and its 8 byte header is the primary item's Padding, so the video
> still ends at the end of the file. Putting the extraction in the shared image
> parser base rather than in JpegParser therefore covers them too, untested for
> lack of a sample file.
> Apple Live Photos are a different thing and need nothing here: their video is
> a separate .MOV, paired by a content identifier, so a HEIC alone carries no
> video.
> The existing test files (testJPEG_MotionPhoto.jpg, testJPEG_MicroVideo.jpg)
> declare a video in their XMP but do not contain one; new fixtures with a
> small real MP4 appended are needed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
