Problem/Motivation
At Drupal DevDays Milan, we discussed the implications of adding #1174892: File field formatters for rich media display with <video> and <audio> HTML5 elements. to provide audio and video players for local media. This would only be a small intermediate step in the overall media initiative, but it is a self-contained improvement we could add for 8.2.x.
Notes from the discussion:
- It's still worth exploring HTML5 audio and video formatters for file fields in core as an experimental module. The existing core issue is very out of date, but there are contrib modules we can look into for core experimental modules. #1174892: File field formatters for rich media display with <video> and <audio> HTML5 elements. We decided we did not want to go in the direction of adding separate field types in that issue, only new formatters for the existing file field type.
- It would also be useful to be able to fall back to the default file field formatter when a formatter is not relevant. (needs issue) NB: field formatter isApplicable() method
- Not directly the same, but in the related area of being able to use formatters for existing core media wherever it lives, there is an existing issue to allow image formatters to also work on file and entity reference fields. That issue is close to ready, so it is worth finishing because it makes sense and is straightforward, even though it is not the same pattern. #2568289: Not possible to reuse field formatters between entity_reference, file, and image fields
- Points 2 and 3 together raise a question for the long term: as @alexpott pointed out, it might not make sense for file and image entity types to be separate things in the long term. This gets into broader questions for the initiative (file entity, media entity, etc...) that are not in scope here but will be a part of the Media Initiative's future discussions.
- Another concern raised was that not all video file types can play on all devices -- in fact, there is not any one video type that will play in all browsers. (Thanks, internet!) So, in order for the "it just works" user story where a user uploads a video and it plays appropriately on each device, we would need some mechanism to at a minimum allow the user to upload a file of each encoding as part of the single field's data. That would allow the relevant video to eventually be selected for each device.
- We also discussed that remote videos (e.g. embedded Youtube videos) are actually more commonly used than HTML5 videos on the local site. While core does not need to necessarily provide remote media, we should keep remote media in mind for the longer term, and make sure that work we do allows that option at least in contrib. @alexpott also pointed out that having formatters that work with multiple different field or entity types in core can help with that by forcing us to be agnostic rather than tightly coupling our solutions to one special thing.
- Related to #5, we would ideally have a single widget for users to upload videos in the relevant format, rather than requiring a different field for each format. This could take the form of an entity reference (inline upload, browser, etc.) or just a video widget. We agreed to leave that out of scope here, since the experimental HTML formatters can go forward separately.
Proposed resolution
Start with points 1-3 above, then explore the rest in the ongoing media initiative (which should have a plan posted soon).
Remaining tasks
TBD
Comments
Comment #2
xjmComment #3
berdirI don't get this, did you maybe mean *field* types? image and file are the same entity type :)
The easiest way to do this is a link field + the field formatters provided by url_embed, either directly on entity/node or through media_entity, if you want to have a media library of used youtube URL's. Either way, I think this and similar points are IMHO not convincing arguments for making the audio/video formatters experimental as I commented there.
Yeah, what we did in our install profile is to have a file field and have a custom formatter that supports images and a few other options. To go all the way there and e.g. also allow youtube videos, galleries and so on in the same field, you need to work with media_entity. We have separate fields for those use cases.