Captions video not saved with the post and are lost on attachment page

[rianrietveld]

At the moment you can add srt-captions and a poster image to a video, entering them while embedding a video in a post.

When you add a video via Add Media in a post the output will be something like:
[video poster="url-here/image.jpg" width="400" height="224" mp4="url-here/video.mp4"]<track srclang="en" label="English"kind="subtitles" src="url-here/captions.srt" />[/video]

This means that the poster and the captions are not stored with the attachment itself, so on attachment this data is lost pages and it is impossible to add a caption or a poster image via the image library.

It would be useful to save srt-captions and the poster with the attachment data itself, like the description and the caption now are.

[rianrietveld]

Adding video details with a post

[rianrietveld]

Would be useful to add cations and poster here

[rianrietveld]

Text correction:
This means that the poster and the captions are not stored with the attachment itself, so on attachment pages this data is lost and it is impossible to add a caption or a poster image via the image library.

[pavelevap]

Related #27891?

[wonderboymusic]

Yeah, this is hard at the moment, will look at it

[GrahamArmfield]

Here is my proposal for an ideal solution to this issue:

1. When a user adds a video through the Add Media functionality, they should be allowed to also upload a caption file to accompany the video, or, to reference a previously uploaded caption file. An input field would be required for that.
2. The URL of the caption file should be stored in the database against the video attachment - so in the post meta for the attachment.
3. When user adds video that is already in the media library to page/post the URL of the caption for the video should be retrieved and presented to the user. Typically they would not change this, but they could. This URL will pass through into the HTML within the page/post.
4. If user is within a page/post and wants to upload video they should also be able to upload or associate caption file with the video. As before, the URL for the caption file should be stored against the attachment rather than the page/post (as at present).

[afercia]

Makes perfectly sense, the caption file should be treated as video meta-data and be permanently stored and associated with the video. About the point 4. I think this is implemented right now but just for videos rendered with MediaelementJS.

[rianrietveld]

Working on this at WordCamp London and discussing this with @emirpprime, we should also take into account that the captions could be in more languages, so a kind of repeater field should be useful, and there should be a field to assign a language to a .srt file.

[postphotos]

a) My biggest frustration is that at any kind of scale it's hard to manage this kind of media. Even having but more than 1 video or 1 subtitle means it's possible to get the wrong video and wrong subtitle to line up.

Currently, videos in WordPress can use captions or subtitles only on output: While writing a shortcode (for Classic Editor) it must be contained and listed in the output:

[video width="320" height="176" mp4="http://example.com/wp-content/uploads/2017/12/jellies.mp4"]
<track srclang="en" label="English" kind="subtitles" src="http://example.com/wp-content/uploads/2017/12/jellies.srt" />
[/video]

This feels very messy and error-prone.

A better use (in shortcode) would look like:
[video width="320" height="176" mp4="http://example.com/wp-content/uploads/2017/12/jellies.mp4" subtitle="yes" /]
or
[video width="320" height="176" mp4="http://example.com/wp-content/uploads/2017/12/jellies.mp4" subtitles="en ES-mx" /]
or
[video width="320" height="176" mp4="http://example.com/wp-content/uploads/2017/12/jellies.mp4" caption="no" /]
Depending on usage, of course. I've used subtitle, caption and subtitles interchangeably here because that's how people talk about the synced moving words to video and they're almost the same thing, and are, for our purposes.

b) A standard way using the above examples to make it easier for content authors would be to use file name matching. If the video is called jellies.mp4, make it so that, by default (and if uploaded together), jellies.srt or jellies.vtt is associated with that video.

Further, if it has a language suffix - jellies-en.srt or jellies-es-mx.srt - and it's uploaded at the same time, associate them all together.

c) It goes without saying this would also affect Gutenberg's output of videos, too.

d) I think we can solve this with data architecture. I think the problem that the roadblocks to reusing a gallery - like "Mark and Diane get Married, 2014" - have almost the data concept here. In any case, we have associated media files who belong to each other and we should have some central way to relate them to each other, through meta or some other means.

Further, if you upload multiple video formats (webm, mp4, etc.) or audio formats for that matter (aac, mp3, wav, etc.) or images (think srcset but with manually defined files) as outlined above in b), a media object could have multiple URLs for different purposes, but they'd all be that object and it wouldn't have to be so messy. The only way I see a) happening elegantly is for this shift.

I would love to hear what @joemcgill thinks on this, and to see if it's even possible. While my primary objective here is to make video subtitles more useful, but I see this a deeper problem that could be solved with a architecture adjustment, especially as Gutenberg starts to introduce a wider concept of "Reusable Blocks" than can solve this. If not, content downstream is only going to get messier when it doesn't have to be anymore.

[rianrietveld]

Hey @postphotos
Thanks for picking this up! I'll assign the ticket to you.

A few years a go I wrote a small plugin for this, for a client. Using Advanced Custom Fields.
maybe you can steal ideas from it.

Note: it's 3 years old code, so don't shoot me for the quality of it:
​https://github.com/RRWD/acf-accessible-video

In production (Dutch example):
​http://iacobien.nl/artikelen/toegankelijke-pdf/

It support captions and also translations, plus different download formats