Hello, this is my first time in this Forum, I'm a very inexperienced user of Exiftool command line... :-[, usually using Exiftool Gui.
My OS: Windows 10 64 Bits
ExifTool version: 10.6.3.0
I'm trying to inject Xmp:TimeStamp metadata to a Spherical LG-360 Cam mp4 video.
The original Video has right date (Tag Xmp:TimeStamp), but the stitched video, injected with "Spherical Metadata Tool" has lost several metadata, including TimeStamp one.
If I export right original video metadata to xmp (using Exiftool GUI), the obtained file doesn't contains part of the metadata, including Xmp TimeStamp.
I'm trying to "reinject" these data with a command line,
exiftool.exe "-XMP-GSpherical:TimeStamp=2005:08:30 20:00:00" C:\20170829.mp4
but I always get the error:
Warning: Invalid date/time (use YYYY:mm:dd HH:MM:SS[.ss][+/-HH:MM|Z]) for XMP-GSpherical:TimeStamp
Nothing to do.
<-END-
This error appears also if I try to inject these metadata using Exiftool GUI.
Thanks,
This is a bug in ExifTool, but I don't think that fixing this bug will help because I believe that Google (for whatever reason) doesn't write the GSpherical XMP to the location specified by the XMP standard. ExifTool will write this to the standard XMP location.
I will fix this bug (the tag's Writable format should be "integer" instead of "date"), but I don't want to get your hopes up too much.
- Phil
Ok, I understand. ;)
Thanks for your impressive work.
Just a note: ExifTool 11.54 or later (July 2019) writes GSpherical tags to the GSphericalXML of the video track.
- Phil
Hi. Lately YouTube has stopped reading these tags correctly. I'm not sure if this is a change in YouTube or in newer versions of Exiftool. The only difference I can see between tags written by the Google python tool (
https://github.com/google/spatial-media ) is the capitalization of True (Google) vs true (Exiftool) in the Spherical and Stitched tags.
(This is what the Google tool prints)
Google tags:
Loaded file...
Track 0
Spherical = true
Stitched = true
StitchingSoftware = Spherical Metadata Tool
ProjectionType = equirectangular
Track 1
Exiftool tags:
Loaded file...
Track 0
ProjectionType = equirectangular
Spherical = True
Stitched = True
StitchingSoftware = Spherical Metadata Tool
Track 1
Re-writing the tags with the Google tool does not fix the problem, but writing them with the Google tool to a file that hasn't had the tags previously seems to work well.
I have tried multiple ways to write the true value in lowercase but nothing seems to work. Was this a change in a recent version? Is there a way to force the tags to be lowercase? (I know they are supposed to be booleans, but...)
Thanks
Edit. I can write the tags as lowercase with the -n option, but YouTube still does not recognise the file as a 360 video
Try extracting and comparing the raw XMP from each file using
exiftool -b -XMP /path/to/files/
If the formatting is different, you might try the -api Compact option (https://exiftool.org/ExifTool.html#Compact) to make exiftool format the XMP such that Google will recognize it. Though I think this is a long shot.
Quote from: StarGeek on September 02, 2023, 05:43:27 PMTry extracting and comparing the raw XMP from each file using
exiftool -b -XMP /path/to/files/
If the formatting is different, you might try the -api Compact option (https://exiftool.org/ExifTool.html#Compact) to make exiftool format the XMP such that Google will recognize it. Though I think this is a long shot.
Thanks.
-b -XMP doesn't print anything. This might be related:
QuoteXMP GSpherical Tags
Not actually XMP. These RDF/XML tags are used in Google spherical MP4 videos. These tags are written into the video track of MOV/MP4 files, and not at the top level like other XMP tags
Interestingly, if I add the tags with the Google tools the video is recognised as VR by YouTube. If I add ANY tag (even not related to spherical data) with ExifTool and the ALSO add the VR tags with the Google tool, YouTube fails to identify the video as VR.
Unfortunately, I can't really help on this. Try searching these forum deeper, as I know there have been posts on the subject before. Also search using Google search with Site:Exiftool.org as part of the querry.
Thanks anyway.
I'm just posting additional findings as I go, if that's ok. I'm comparing the data in the files, and files that work well seem to have the "XMP" data towards the end of the file:
https://imgur.com/a/880jiqi
While files that don't work have it at the beginning:
https://imgur.com/a/u0LPwVo
Also, the Google tool uses double quotes and exiftool uses single ones, plus google specifies the xml version at the beginning of the "XMP" data (<?xml version="1.0"?>). Although that does not seem to be the key of the problem.
Will try old versions of Exiftool next.
Old versions made no difference. What makes a difference is testing a very small file. Very small files are read correctly by YouTube. So my only hypothesis is this is a bug on YouTube's end, where the 360 metadata is only looked for within the last N bits of a file or stream. Since Exiftool writes the "XMP" data at the beginning, YouTube fails to find it in large files (obviously I could be completely wrong). Would there be a reason not to write the data at the end to work around this YouTube bug? I will report this to Google as well, but who knows if they will care enough
Should I post this as a separate feature request?
I don't think such a request will get much traction unless you can show that this is the actual problem.
Phil is away for a few weeks, so there wouldn't be an answer until then.
Here are samples to verify that, or to investigate the issue if the cause is different.
- Video with "XPM" tags injected with the Google tool: https://youtu.be/rENkZmz7nnQ (Plays in VR)
- Same video file with same "XMP" tags injected with Exiftool: https://youtu.be/hKekmx3jbk4 (Does not play in VR)
- Video processed with Exiftool AND with the "XMP" tags rewritten again with the Google tool: https://youtu.be/oC3qQf0CpIs (Does not play in VR)
Original files can be downloaded here: https://www.dropbox.com/scl/fi/oozbeljc3x6c8jmgpy8z5/clean_exiftool.zip?rlkey=ragpeaqe0iub0u2qfm6u32rff&dl=0
Differences I can see between Google and Exiftool versions:
1- Google has XML tag (<?xml version="1.0"?>)
2- Google uses double quotes vs single ones on Exiftool (xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#")
3- The "XMP" data is near the beginning of the file in Google's, but near the end in Exiftool's
Differences 1 and 2 are not present in the file that was processed with both tools, which does not play in VR, so difference number 3 seems to be the culprit.
Of course:
- It could be something else I'm not seeing
- There might be strong reasons why Exiftool is writing the data at the beginning
- This might be a bug on YouTube's end that Exiftool is not responsible for fixing.
- Etc.
So I'm just sharing my findings in case this all makes sense and helps solve the issue in future versions
I did find in my notes that I had this reddit page bookmarked. Maybe it can help
https://reddit.com/r/Insta360/comments/10ii9r3/how_to_upload_360_videos_to_google_street_video/
Quote from: StarGeek on September 08, 2023, 12:00:43 AMI did find in my notes that I had this reddit page bookmarked. Maybe it can help
https://reddit.com/r/Insta360/comments/10ii9r3/how_to_upload_360_videos_to_google_street_video/
It doesn't seem related. It shows a workflow for Google Street View, but no info on VR tags for YouTube
Sorry, my mistake.
Ok, so people at Google/YouTube looked into it and confirmed that this is related to where the data is written: https://github.com/google/spatial-media/issues/285
Using ffmpeg I was able to prepare my video files so ExifTool writes the data where needed, by using the -movflags faststart option. I wonder if this can be done directly in ExifTool, but the problem is solved for me now.
It will take some time before I can look at this in detail. Right now I'm trying to catch up so I can make a 12.66 release without too much delay.
- Phil