[
https://issues.apache.org/jira/browse/TIKA-4869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18110666#comment-18110666
]
ASF GitHub Bot commented on TIKA-4869:
--------------------------------------
dschmidt commented on PR #3115:
URL: https://github.com/apache/tika/pull/3115#issuecomment-5510771958
Thank you, and all of it is in, pushed just now.
On 1., I agree, and I did not add the video requirement. The recursion is
closed at its source instead: the branch below an emitted trailer is not
searched for a trailer of its own. A PDF behind an image is still emitted, an
image behind an image too, but it cannot chain. The new test builds the nesting
your bot measured and asserts two documents where it got three.
Worth its own ticket, maybe: what made this reachable at all is that
`ParseRecord.maxEmbeddedDepth` defaults to -1, so `/tika`, tika-app and the
facade have no depth guard, only the `RecursiveParserWrapper` path does. Our
chain is closed now, but any parser that emits something derived from its own
input has the same shape.
On 2., the reason for preferring the declaration is that detection cannot
tell these apart: an MP4 with the `isom` brand types as `video/quicktime` (that
is TIKA-3646), so the extension from detection would be `.mov` on a file whose
container says `video/mp4`, and MicroVideo declares no type at all, where
detection would guess one. So the declaration still wins, but only within the
same top level type. Where the two disagree about the kind of file it is, as
with your text trailer, the bytes win and `RESOURCE_NAME_EXTENSION_INFERRED` is
set, since that is the case the property describes.
On 3., `Files.size`, the detection and the region stream are inside the
guard now: locating the trailer is one step that yields nothing rather than
throwing, and so is opening it.
On the hygiene list: the declared `Item:Mime` stays a string and is only
looked up for an extension through `EmbeddedDocumentUtil`, so neither
`MediaType.parse` nor `MimeTypes.forName` sees it. `MediaType.parse` on main
still caches into `SIMPLE_TYPES`, capped at 10000, and `MimeTypes.forName`
still registers what it does not know, which is TIKA-4826. CHANGES.txt now says
"not recognized", the embedded parse writes its own div like EMFParser and
RawTiffParser, and the tests read the declared length from the fixture.
> 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)
