[
https://issues.apache.org/jira/browse/TIKA-3646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18110433#comment-18110433
]
ASF GitHub Bot commented on TIKA-3646:
--------------------------------------
dschmidt opened a new pull request, #3114:
URL: https://github.com/apache/tika/pull/3114
Tika's own fixtures show the problem: `testMP4Video.mp4` and
`testMP4AudioOnly.mp4` both carry the `isom` brand, and both are detected as
`video/quicktime`, because the mime magic for `video/mp4` only matches the
brands `mp41` and `mp42`. Adding `isom` to that magic would type the audio-only
file as video, so the brand cannot answer this; the tracks have to.
`MP4TrackDetector` walks the top level boxes by their size fields, which
steps over the media data rather than reading it, finds the movie box and reads
the handler type of each `moov/trak/mdia/hdlr`: a video track makes it
`video/mp4`, otherwise an audio track makes it `audio/mp4`, otherwise
`application/mp4`, as RFC 4337 describes. Brands that name a format of their
own (M4A, 3GP, HEIC, AVIF, CR3, ...) are left to their own magic, and so is a
file whose movie box cannot be reached.
The box primitives are shared rather than written again: `boxEnd`, `findBox`
and the FourCC readers move from `Mp4SampleEntries` (TIKA-4838) into
`Mp4Boxes`, which now also handles the 64 bit largesize and the size 0 form;
the sample entry walker and the two sample handlers use it.
Bounds, since a detector reads whatever arrives: sizes are checked as longs
before any cast, the walk stops at the first box that does not fit what
encloses it, the number of boxes and tracks and the size of the movie box read
into memory are capped, and without a file to seek in only a movie box within
the first 256 KB is found. Tests cover every truncation of a well formed file
and random bytes behind a valid header.
Verified on a server built from this branch: `testMP4AudioOnly.mp4` now
detects as audio/mp4 and `testMP4Video.mp4` as video/mp4, where both used to be
video/quicktime; HEIC, AVIF and M4A files are unchanged.
This closes TIKA-3646 and, for plain MP4, the question in TIKA-2935.
https://issues.apache.org/jira/browse/TIKA-3646
> MP4 files have their mime type detected as video/quicktime
> ----------------------------------------------------------
>
> Key: TIKA-3646
> URL: https://issues.apache.org/jira/browse/TIKA-3646
> Project: Tika
> Issue Type: Bug
> Components: detector
> Reporter: Apachae Tika User
> Priority: Major
> Attachments: Video.mp4
>
>
> I was using ScreenToGif tool which allos to record screen and create gifs or
> MP4 files (with ffmpeg). I've tried to use Tika Detector for such files but
> the file is being detected as video/quicktime with .qt extension. How is
> that?
> Attaching small video for example which was generated with ScreenToGif and
> saved as mp4.
> I see some other people complaining for same thing here
> [https://stackoverflow.com/questions/48021617/use-apache-tika-get-mp4-file-contenttype-got-video-quicktime]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
