Hi Phil,
I’m investigating an issue when using ExifTool to edit the capture time or GPS location of Android Live Photos. The issue affects both dual-file Live Photos and single-file Motion Photos.
For a dual-file Live Photo consisting of a JPEG and a companion MP4, writing metadata to the MP4 causes the phone to stop recognizing the pair as a Live Photo. It is then displayed as a separate photo and video.
I compared the MP4 before and after editing:
QuickTime:MediaData has the same size and SHA-256 hash.
QuickTime:UUID-Unknown also has the same size and SHA-256 hash.
The audio and video streams are not re-encoded.
However, the top-level MP4 atom order changes from:
ftyp
moov
free
mdat
uuid
to:
ftyp
moov
free
uuid
uuid
mdat
The original vendor UUID is moved from after mdat to before mdat, and an additional UUID atom is added for XMP metadata. The MediaDataOffset also changes.
This happens when writing fields such as:
Keys:GPSCoordinates
Keys:CreationDate
QuickTime:CreateDate
XMP-xmp:CreateDate
As a control test, I edited only the JPEG and left the companion MP4 byte-for-byte unchanged. After downloading the files, the phone still recognized them correctly as a Live Photo. This suggests that rewriting the companion MP4, rather than editing the JPEG, causes the compatibility problem.
A similar issue exists with single-file Android Motion Photos, where a JPEG or HEIC contains an appended or embedded MP4. Rewriting the image metadata may affect Motion Photo metadata such as GCamera:MicroVideoOffset, the Google Container Directory, item lengths or padding, or vendor-specific trailer data.
Is there a way to avoid this issue when editing metadata with ExifTool, while preserving compatibility with both dual-file Live Photos and single-file Motion Photos?
Thank you.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This problem has been reported but will be difficult to track down. I hope it isn't an order dependency because these are really annoying to work around, but I haven't had time to look into this problem yet. It will be top of my list when i get a chance.
Phil
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I was able to reproduce this issue using a single-photo Samsung motion-photo HEIC file. The problem here was that the Samsung 'sefd' box must after both 'mdat' and 'mpvd'. This will be fixed in the next version, and affected files will be repaired if re-edited.
However, to solve the dual-file JPEG+MP4 issue I will need to be able to reproduce this. I don't know how to produce a dual-file live photo with my Samsung phone.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK. I have been unable to generate sample files or reproduce the problem with the MP4. Specifically, I need more details about the uuid box that comes after mdat in the original sample. An excerpt from a -v3 dump would help, but a sample would be better.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Phil,
I’m investigating an issue when using ExifTool to edit the capture time or GPS location of Android Live Photos. The issue affects both dual-file Live Photos and single-file Motion Photos.
For a dual-file Live Photo consisting of a JPEG and a companion MP4, writing metadata to the MP4 causes the phone to stop recognizing the pair as a Live Photo. It is then displayed as a separate photo and video.
I compared the MP4 before and after editing:
However, the top-level MP4 atom order changes from:
ftyp
moov
free
mdat
uuid
to:
ftyp
moov
free
uuid
uuid
mdat
The original vendor UUID is moved from after mdat to before mdat, and an additional UUID atom is added for XMP metadata. The MediaDataOffset also changes.
This happens when writing fields such as:
Keys:GPSCoordinates
Keys:CreationDate
QuickTime:CreateDate
XMP-xmp:CreateDate
As a control test, I edited only the JPEG and left the companion MP4 byte-for-byte unchanged. After downloading the files, the phone still recognized them correctly as a Live Photo. This suggests that rewriting the companion MP4, rather than editing the JPEG, causes the compatibility problem.
A similar issue exists with single-file Android Motion Photos, where a JPEG or HEIC contains an appended or embedded MP4. Rewriting the image metadata may affect Motion Photo metadata such as GCamera:MicroVideoOffset, the Google Container Directory, item lengths or padding, or vendor-specific trailer data.
Is there a way to avoid this issue when editing metadata with ExifTool, while preserving compatibility with both dual-file Live Photos and single-file Motion Photos?
Thank you.
This problem has been reported but will be difficult to track down. I hope it isn't an order dependency because these are really annoying to work around, but I haven't had time to look into this problem yet. It will be top of my list when i get a chance.
I was able to reproduce this issue using a single-photo Samsung motion-photo HEIC file. The problem here was that the Samsung 'sefd' box must after both 'mdat' and 'mpvd'. This will be fixed in the next version, and affected files will be repaired if re-edited.
However, to solve the dual-file JPEG+MP4 issue I will need to be able to reproduce this. I don't know how to produce a dual-file live photo with my Samsung phone.
It may help if you could upload the files for a dual-file live photo for me to test.
OK. I have been unable to generate sample files or reproduce the problem with the MP4. Specifically, I need more details about the uuid box that comes after mdat in the original sample. An excerpt from a -v3 dump would help, but a sample would be better.