WordPress.org

Make WordPress Core

Opened 3 years ago

Last modified 4 weeks ago

#31177 assigned defect (bug)

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

Reported by: rianrietveld Owned by: postphotos
Milestone: Future Release Priority: normal
Severity: normal Version: 4.1
Component: Media Keywords: needs-patch
Focuses: ui, accessibility Cc:

Description

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.

Attachments (2)

Video details in edit post.png (74.7 KB) - added by rianrietveld 3 years ago.
Adding video details with a post
edit media in the library.png (298.9 KB) - added by rianrietveld 3 years ago.
Would be useful to add cations and poster here

Download all attachments as: .zip

Change History (17)

@rianrietveld
3 years ago

Adding video details with a post

@rianrietveld
3 years ago

Would be useful to add cations and poster here

#1 @rianrietveld
3 years ago

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.

#3 @SergeyBiryukov
3 years ago

  • Component changed from Administration to Media

#4 @wonderboymusic
3 years ago

  • Keywords needs-patch added
  • Milestone changed from Awaiting Review to Future Release

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

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


3 years ago

This ticket was mentioned in Slack in #accessibility by rianrietveld. View the logs.


3 years ago

#7 @GrahamArmfield
3 years ago

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).

#8 @afercia
3 years ago

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.

#9 @rianrietveld
3 years ago

  • Owner set to rianrietveld
  • Status changed from new to assigned

#10 @rianrietveld
23 months ago

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.

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


15 months ago

#12 @postphotos
2 months ago

  • Severity changed from normal to major

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.

This ticket was mentioned in Slack in #accessibility by postphotos. View the logs.


2 months ago

#14 @rianrietveld
2 months ago

  • Owner changed from rianrietveld to postphotos
  • Severity changed from major to normal

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

This ticket was mentioned in Slack in #accessibility by postphotos. View the logs.


4 weeks ago

Note: See TracTickets for help on using tickets.