Feature #27391


Allow multiple formats/resolutions for media-content

Added by Stefan Neufeind almost 13 years ago. Updated about 3 years ago.

Should have
File Abstraction Layer (FAL)
Target version:
Start date:
Due date:
% Done:


Estimated time:
PHP Version:
Sprint Focus:


Would need to allow uploading more than one version for one media-element (maybe mp4 and webm). And if multiple formats exist that would be possible to use (like different resolutions) it would be great to be able to choose which one to display (like YouTube allows switchting resultions).

Having the possibility to handle multiple media-files for one element would also allow to offer different formats inside an HTML5-videoplayer to match the different browser-tastes (no MP4 for Mozilla, no WebM on iPad).

Related issues 4 (1 open3 closed)

Related to TYPO3 Core - Feature #27390: Needs HTML5-compatible media-player (video/audio)Closed2011-06-12

Related to TYPO3 Core - Feature #57417: ImageViewHelper responsive ImagesNew2014-03-28

Related to TYPO3 Core - Feature #70965: Responsive Image Rendering in fluid_styled_contentClosed2015-10-23

Related to TYPO3 Core - Story #75879: Add picture element to FSCRejectedRichard Haeser2016-04-23

Actions #1

Updated by Stefan Neufeind almost 12 years ago

Just checked that since 4.7 it's possible to give multiple video/audio-sources and so at least the "multiformat-feature" is already possible there.
With 4.7 also "videojs" was added as a contrib-library to the TYPO3-core.

Actions #2

Updated by Wouter Wolters over 9 years ago

  • Status changed from New to Needs Feedback


as this report is very old, is the handling in newer TYPO3 CMS Versions (6.2.9) more like you expect it?

Actions #3

Updated by Stefan Neufeind over 9 years ago

  • Category set to File Abstraction Layer (FAL)
  • Status changed from Needs Feedback to New

FAL still doesn't have a possibility for multiple files that belong to a certain master-file - like re-encoded versions of a video, specially cropped version of an image etc. We've discussed that occasionally with some folks and it would be nice to come up with a solution here. Maybe something that could be considered to discuss at the FAL-sprint? I'll ping Mathias.

Actions #4

Updated by Ingo Schmitt over 9 years ago

  • Target version set to 8 LTS
  • Complexity set to hard
Actions #5

Updated by Riccardo De Contardi about 7 years ago

  • Target version changed from 8 LTS to 9.0
Actions #6

Updated by Riccardo De Contardi about 6 years ago

About the "specially cropped version of an image" I think that this has been achieved in version 8 (in a different way) with the "multiple cropping variants" (

Actions #7

Updated by Susanne Moog about 6 years ago

  • Target version deleted (9.0)
Actions #8

Updated by Benni Mack over 4 years ago

  • Status changed from New to Needs Feedback

Hey Stefan,

with the current implementation of image variants / cropping variants, I do think the image issue is solved via FAL / Fluid and various cropping formats.

However, when it comes to video formats, can you elaborate what exactly you think Core should handle?

Is it that you can relate files to each other? And then, how would capabilities be defined?

Actions #9

Updated by Stefan Neufeind over 4 years ago

I was thinking of video-tags with multiple sources (separate files, but belonging together). Like here:
<video width="320" height="240" controls>
<source src="movie.mp4" type="video/mp4">
<source src="movie.ogg" type="video/ogg">
Your browser does not support the video tag.

Of course it could be rendered different in the frontend, if need be.

Actions #10

Updated by Riccardo De Contardi over 4 years ago

  • Status changed from Needs Feedback to New
Actions #11

Updated by Benny Bachmann about 3 years ago

What about creating a 1:n relation from sys_file_metadata to other sys_files. In sys_files a additional field for picking the resolution would be helpful and the mime_type and extension columns already provide the file format. Now one could choose variant files in the metadata once and would get those directly by choosing the base file in a media content element. Now things could be rendered with source tags like mentioned above or inserted with javascript or whatever else, because you get all of the data for all file variants passed into the fluid template.
I'm not so familiar with all the side effects that come with the relations, localization, workspaces, etc. but would this be a possible or good way to solve it?


Also available in: Atom PDF