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 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
