Quicktime/MP4 UUID atom issue #219
Comments
|
Can you provide a small (preferably blank) sample video from After Effects that uses 'uusd' to store XMP data that I can test with? |
#219 Attempt to parse Quicktime 'uuid' atoms more appropriately. Currently includes special handling for XML and 360fly data. Note that [quicktime][uuid] is now returned as an array and may contain multiple entries.
|
I have made some changes to 'uuid' atom handling in ed22a3e A blank sample file with XML uuid data would still be appreciated if it's easily created. |
|
I attempted using version 1.9.19-201912241213 and the error persisted. After I analysed more deeply the code I've realized that the problem comes from having an empty UUID atom. The parser for UUID attempts to I've noticed that it comes empty from inside the MOOV atom, which was odd because it doesn't belong inside the MOOV and after looking a bit more to the code I think I've discovered the problem. When parsing the atoms it read 8 bytes from the file to read the header, take the atom size from the header and then reads that amount of bytes. Here's the problem: it attempts to read the amount of bytes that is said in the header, but it doesn't take into account the 8 bytes already read for the header. This results in reading an additional 8 bytes, these are the header of the next atom in the file (in my specific case it's the UUID). In the while ($offset < $info['avdataend']) {
if (!getid3_lib::intValueSupported($offset)) {
$this->error('Unable to parse atom at offset '.$offset.' because beyond '.round(PHP_INT_MAX / 1073741824).'GB limit of PHP filesystem functions');
break;
}
$this->fseek($offset);
// header size to reduce from the atomsize to read the file
$atomHeaderSize = 8;
$AtomHeader = $this->fread(8);
$atomsize = getid3_lib::BigEndian2Int(substr($AtomHeader, 0, 4));
$atomname = substr($AtomHeader, 4, 4);
// 64-bit MOV patch by jlegateØktnc*com
if ($atomsize == 1) {
// additional 8 bytes read
$atomHeaderSize += 8;
$atomsize = getid3_lib::BigEndian2Int($this->fread(8));
}
if (($offset + $atomsize) > $info['avdataend']) {
$info['quicktime'][$atomname]['name'] = $atomname;
$info['quicktime'][$atomname]['size'] = $atomsize;
$info['quicktime'][$atomname]['offset'] = $offset;
$this->error('Atom at offset '.$offset.' claims to go beyond end-of-file (length: '.$atomsize.' bytes)');
return false;
}
if ($atomsize == 0) {
// Furthermore, for historical reasons the list of atoms is optionally
// terminated by a 32-bit integer set to 0. If you are writing a program
// to read user data atoms, you should allow for the terminating 0.
$info['quicktime'][$atomname]['name'] = $atomname;
$info['quicktime'][$atomname]['size'] = $atomsize;
$info['quicktime'][$atomname]['offset'] = $offset;
break;
}
$atomHierarchy = array();
// since 8 (16 in case of 64-bit MOV) bytes were already read from the file for the header
// those have to be reduced from the atomsize to read only the data of the atom
// and to prevent reading the header of the next atom
$parsedAtomData = $this->QuicktimeParseAtom($atomname, $atomsize, $this->fread(min($atomsize - $atomHeaderSize, $atom_data_read_buffer_size)), $offset, $atomHierarchy, $this->ParseAllPossibleAtoms);
$parsedAtomData['name'] = $atomname;
$parsedAtomData['size'] = $atomsize;
$parsedAtomData['offset'] = $offset;
if (in_array($atomname, array('uuid'))) {
@$info['quicktime'][$atomname][] = $parsedAtomData;
} else {
$info['quicktime'][$atomname] = $parsedAtomData;
}
$offset += $atomsize;
$atomcounter++;
}After these changes it's working fine. Also, here's a sample .mp4 file that can reproduce the error: |
After this lastest update (version: 1.9.19-201912131005) we're experiencing errors in the analyse function.
After looking through the changes in the lastest release and the stack trace it seems to be related to the UUID atom unpack.
The videos that are causing problems were exported from Adobe After Effects, which uses the UUID atom to store XMP data in MP4 files. Since this last update the UUID atom started being analysed for 360Fly Sensor Data without any checks if the data is actually valid for 360Fly. As such, it crashes on the first unpack because the data is not as expected.
Error: unpack(): Type H: not enough input, need 4, have 0
File: module.audio-video.quicktime
Line: 1657
Is there any reason to assume that whenever there's an UUID atom it's related to 360Fly in a Quicktime audio-video file type?
Could there be a way to check that the data is related to 360Fly before running this new code?
Stack trace:
More detailed stack trace in the HTML file in the following ZIP file:
stack-trace.zip
The text was updated successfully, but these errors were encountered: