Closed ben-xo closed 4 years ago
I notice the uuid code was only added recently, it has a note from 2019-Oct-31 in the code.
Are you sure you're using the most recent version, with the more-recent changes from https://github.com/JamesHeinrich/getID3/commit/ed22a3edc4fcf4c80ed00d9f60d191dcbb2d7881 ? The current line 1648 does not have any unpack, and the symptom you describe is far more likely from prior to the changes made in https://github.com/JamesHeinrich/getID3/commit/ed22a3edc4fcf4c80ed00d9f60d191dcbb2d7881
Hey @JamesHeinrich i rebased on latest and the bug is still there. It's actually a container parsing bug!
I have a patch. PR incoming
This patch fixes the bug and guards against similar parsing errors. It's also possible that it may be an underlying off-by-some bug with the data passed to the atom-parsing code, though. But I didn't find one, and in any case this patch contains a reasonable safety check.
FYI what was happening was that the uuid
atom was being encountered (but 0 length) whilst still parsing moov
atom. But as you can see from AtomicParsely it's not a subatom of moov
.
By the way, http://fileformats.archiveteam.org/wiki/Boxes/atoms_format has a shortlist of "known" UUIDs - which of course it's impossible to enumerate, as they're essentially app-specific.
But it would seem the right way to identify "360Fly Sensor Data" or otherwise may be to match on the UUID, rather than the content of the atom?
360fly and XMP are now parsed when their matching UUID is found, other recognized UUIDs from the shortlist are included but have no special parsing. https://github.com/JamesHeinrich/getID3/commit/dee9eb7858518f6285f854b19100246e3c31201e
The full error is
The file in question is 2.5Gb in size and AtomicParsely shows the following structure (uuid near the bottom):
I get the same output with php 7.1.32 and php 7.4.1
I'll see if I can debug any further.