[TYPO3-core] [TYPO3-dev] MULTIMEDIA

[Patrick Broens]

Hi Martin

Martin Kutschker wrote:
> Hi!
> 
> Here are my thoughts on the topic:
> 
> The current implementation of the MULTIMEDIA cObject type and the 
> accompanying content element is a very simple one. Unfortunately it 
> relies also on the EMBED and the APPLET element which are not part of 
> any W3C standard and has a set of questionable default attributes. OTOH 
> it is easy to use and doesn't require much knowledge from the editor.
> 
> So I suggest to modify the code such that the generated HTML code uses 
> the OBJECT element (with a possible fallback to EMBED or an image).
Yes, please
> 
> Adding support for user defined width/height and alt/title text is easy 
> enough. More of a problem is the fact that the OBJECT element requires a 
> type attribute with a mime type unless you specify a classid attribute 
> which is Windows specific and requires a certain browser plugin. So we 
> need (for convenience) a file extension to mime type mapping (with a 
> manual override option). The mime type must be a DB field so it can be 
> accessed by TypoScript!
Off course there are some ways to do this with PHP itself, but these 
options require PHP extensions like using the configuration switch 
--with-mime-magic and the function mime_content_type(), or the prefered 
PECL extension fileinfo, which offers mime recognition.

stream_get_meta_data also extracts the mime type of the file, but I'm 
uncertain if this works in all cases, server configurations etc. This 
does not need any PHP extension

It's always safer and better to get the mime type of the file itself and 
compare it with the file extension then taking the file extension, and 
add a mime type to it manually.
> 
> Another point is that we may want to set the width/height attributes 
> automatically. IMHO we should incorporate the getID3 library (or an 
> equivalent) into typo3/contrib. We could use this lib also for download 
> elements to display meta data for media files (eg play length, bitrates, 
> etc).
That would be a nice feature, but not necessary
> 
> The current parameter field can easily be changed to output PARAM 
> elements instead of attributes for EMBED/APPLET.
> 
> But a problem might be real compatibility. Does anyone need the old 
> EMBED tag? Will sites break if we just move on to OBJECT? Perhaps if the 
> make use of the parameter field (not all attributes may map directly 
> onto PARAM tags).  We could redefine the syntax that a line may look 
> like this "name=value[|tag]". So all params are duplicated (when we have 
> both OBJECT and EMBED) unless a tag name is appended.
> 
> As for using OBJECT and EMBED/APPLET: for xhtml 1.0 strict and xhtml 1.1 
> no EMBED/APPLET should ever be created. For other DTDs I see the option 
> to use both elements or only EMBED/APPLET. The latter option is for 
> strict backward TYPO3 compatibility only. The TypoScript compatibility 
> flag will provide a default: a setting of < 4.2 will get you 
> EMBED/APPLET by default, otherwise its OBJECT. A site admin may choose 
> both elements by an appropriate TS configuration.
We are already violating the W3C standards by using the EMBED/APPLET 
tags. So, in my opinion we should change it all to OBJECT/PARAM. The 
only compatibility thing there could be is that people used CSS to style 
their EMBED tags. Could there be more?
> 
> Examples:
> 
> # mime type and size auto-detection, tag defined by default
> movie = MULTIMEDIA
> movie.file = movie.mpeg
> movie.altText = last christmas
> 
> # width auto-detection, tag set to OBJECT and EMBED
> movie = MULTIMEDIA
> movie.file = movie.mpeg
> movie.width = 200
> movie.mimeType = video/mpeg
> movie.tag = objectEmbed
> 
> Masi
> 
> PS: For a set of know mime types we could even create a flex form sheet 
> with additional parameters for well-known plugins (eg autostart, 
> show/hide UI, etc). But maybe such stuff is better suited in an extension.
No need if you can extract the mime type from the file itself.

Patrick