Parse the creation date out of uploaded videos

[stevegrunwell]

When images are uploaded into the media library, wp_read_image_metadata() will read the images' EXIF data to determine the date the image was taken, which is returned in "created_timestamp". Other media types (audio and video) do not provide this information, but it's still useful metadata (especially on media-heavy sites).

This information is available through the getID3 library, however where it lives varies based on the type of media uploaded. I propose we add a "created_timestamp" key to wp_read_video_metadata() (and ideally wp_read_audio_metadata() as well) which parses out a timestamp corresponding to when the media was created (as we do with images).

[stevegrunwell]

First pass at wp_get_media_creation_timestamp()

[stevegrunwell]

Quicktime video used for testing

[stevegrunwell]

MPEG-4 video used for testing

[stevegrunwell]

MKV video used for testing

[stevegrunwell]

Note: the patch file attached references three video files, which are also attached. These short, 15 second clips in three different formats should live in tests/phpunit/data/videos/

[joemcgill]

Thanks @stevegrunwell for the work on this and sorry that it's taken so long to review. Let's take a look for 4.9.

[mikeschroder]

I like this. Let's get some testing on it with additional files.

[mikeschroder]

I dug into this a bit, and if I'm reading this correctly, it looks like we will need to do normalization on the values (or maybe grab from a different location/format for MOVs?).

The example MOV file, and one that I tested from a live photo, have creation dates that get stored as far in the future.

The one in the automated test, for example, is 3533823605 which looks to be 12/24/2081 @ 5:40pm (UTC).

[desrosj]

Looked into this and did some testing. Also noticed what @mikeschroder did. There is a creation_time_unix index for Quicktime/MP4 files. Is there any reason not to use that value for the created time instead of the creation_time one?

Incoming patch using that one instead, as well as updating the version in the inline documentation.

[stevegrunwell]

Totally on board with using creation_time_unix instead of creation_time, as long as it's consistent. ​The ID3 documentation has a nice warning about the "subatoms" node:

This is an undocumentably-complex recursive array, typically containing a huge amount of seemingly disorganized data. Avoid this like the plague.

A creation date in the far future doesn't do anybody any favors :)

[desrosj]

Related #42017

[joemcgill]

Reassigning to @mikeschroder for final decision, commit here.

[desrosj]

Add filter to wp_get_media_creation_timestamp()

[desrosj]

Per discussion in today's weekly component meeting, 35218.2.diff​ adds a filter to the function result. This will allow devs to hook in and parse the creation time for any file type that we do not decide to parse in Core.

[blobfolio]

Add WebM handling, extra Matroska check, and include unit test files

[blobfolio]

I updated the patch to include WebM. It also looks for Matroska creation times in a second place (an FFMPEG source file I tested with had it under [info] instead of [comments]). This patch also has binary data for some unit test files (all based off the existing small-video.mp4.

It would be nice to get some OGG love in here too, but getID3 doesn't seem to fully support Theora yet.

[blobfolio]

Merge desrosj's changes. :)

[mikeschroder]

Thanks, @desrosj @blobfolio!

Looking at this today for commit.

[blobfolio]

These are the quickie files used in the unit tests, meant to be placed in tests/phpunit/data/uploads

[blobfolio]

This is the same as 35218.4.diff, compiled without the --binary flag.

[mikeschroder]

Only create meta if there is a creation date and only rely on small* test media files.

[mikeschroder]

Place new data into video_meta array

[mikeschroder]

Place new data into video_meta array and add new video meta filter

[mikeschroder]

Chatted with @joemcgill about this tonight.
Three new patches, can commit one of them in the morning (or feel free to do it, @joemcgill if it needs to happen first thing, and you're working first).

I'm okay with all of these approaches, but prefer the last.

• 35218.6.diff​ is basically an update. Only create meta if there is a creation date and only rely on small* test media files.

• video_meta.diff​ places the new data (creation timestamp) into a video_meta array in meta, much like image_meta on images.

• video_meta_expanded_filter.diff​ like the diff above, but also swaps the proposed filter for wp_read_video_metadata, which closely matches wp_read_image_metadata.

[joemcgill]

I like the idea of putting the filter in wp_read_video_metadata() as in video_meta_expanded_filter.diff​, now with fresh eyes, I think putting creation time into a video_meta array seems unnecessary. In reality, everything returned by wp_read_video_metadata() is “video meta”, but we don’t want to change that storage at this point for back-compat reasons. Otherwise, this looks good for a commit today.

[mikeschroder]

Sure, @joemcgill, pick the one option I didn't leave a diff for!

I'm kidding, of course. Will work this up, thanks so much for the review!

Would appreciate any more eyes on the wp_read_video_metadata filter, since it had to be just enough different from the image one to make it not directly interchangable.

[mikeschroder]

Back to storing without image_meta array

[mikeschroder]

In 41746:

Media: Store video creation date in meta.

When able to be parsed, store the created date for a video file from meta,
since this is useful separately from the dates on the file itself.

Introduces wp_get_media_creation_timestamp() to read the timestamp from
getID3 and a wp_read_video_metadata filter analogous to
wp_read_image_metadata.

Fixes #35218.
Props stevegrunwell, joemcgill, desrosj, blobfolio, mikeschroder.