Metadata: Flag Samsung/Google Motion Photos as Live Photos

[MEDumont]

1. What is not working as documented?

When importing Google Motion Photos of the format PXL_{Timestamp}.MP and PXL_{Timestamp}.MP.jpg, if the video is less than a second long, the stack is not marked as a Live photo, even though it is a live photo. This results in many manual edits to fix them.

2. How can we reproduce it?

Steps to reproduce the behavior:

1. Setup Photoprism with an originals folder containing many Google Motion Photos
2. Navigate to the Library Tab
3. Check Complete Re-Scan
4. Click Start and wait to finish
5. Navigate to Search tab and find any Google Motion Photo with a video length of less than 1 second.
6. It will be categorized as a video, not a live photo.

I have the default settings for thumbnail quality. I am using an NFS share for my originals folder. Photoprism is running a docker container that has that NFS share mounted directly to it.

3. What behavior do you expect?

I expect my Google Motion Photos to be categorized as Live if they are under 3 seconds in length.

4. What could be the cause of your problem?

I believe the cause of the problem could be a hard-coded rule regarding the length of video files under 1 second in the indexer.

5. Can you provide us with example files for testing, error logs, or screenshots?

6. Which software versions do you use?

(a) PhotoPrism Architecture & Build Number: Build [220901-f493607b0]

(b) Database Type & Version: MariaDB 10.8

(c) Operating System Types & Versions: Ubuntu 22.04

(d) Browser Types & Versions: Vivaldi 5.5

(e) Ad Blockers, Browser Plugins, and/or Firewall Software? PiHole DNS, Adblock Plus

7. On what kind of device is PhotoPrism installed?

Docker container running in an Ubuntu 22.04 Virtual Machine

8. Do you use a Reverse Proxy, Firewall, VPN, or CDN?

I use Nginx as a reverse proxy, but I am not having issues with that.

[kvalev]

Google motion photos are not supported, see #1739

[MEDumont]

I'm aware they are not supported natively, but Google Takeout splits the video and photo into two separate files and they are imported as live because they stack and have the same filename (which is awesome!). The only issue is: aren't videos that are stacked with photos under 3 seconds supposed to be categorized as live, not just standalone video?

[lastzero]

Due to a previous request, we have limited the display of videos as "Live Photos" to the MOV and HEIC formats used by Apple. If you do some research on GitHub Issues, you may find the relevant discussion. Changing this would not be a bug fix, but a feature request.

[lastzero]

It is very helpful to have file samples available for testing, see our contact page for details:

https://photoprism.app/contact

[MEDumont]

Wouldn't that mean that all of my photos should be automatically tagged as videos? They aren't. Only videos with a sub 1 second duration. And I've checked hundreds of these files and that trend is consistent. All other files with longer durations tag as Live. They are MP4s with the AVC/H.264 codec. I'll upload samples.

[lastzero]

MP4 is not identical with MOV. It will also depend on how the metadata is extracted. To give a specific example: If the duration of the video is not known, detection is not possible.

What we need is a) time / resources and b) sample files.

[MEDumont]

I sent a pair of sample files. These files specifically exhibited the behavior when I imported them. They are all from the same source and Google Takeout. Ah I see what are saying. It could be that for a video with a duration of less than 1 second (or 0:00 duration), that during indexing it gets treated as having unknown duration, which would explain the trend I am seeing.

[lastzero]

That's possible. AFAIK original Live Photos always have around 3 seconds of video. You are welcome to do a bit of research on the "specs" or how Google thinks it should be detected using common tools and standards.

[MEDumont]

Is it not a viable solution to enable detection on photos with zero duration that match the .MP naming scheme? This blog post mentions they trim the video portion of the motion photo to remove excessive motion, so a lot of their photos can end up with short durations. This GitHub issue also mentioned a header that allows for identification, if that route ends up being necessary.