by Marina Glancy.
Thank you very much Sam for a long and descriptive post, you outlined very well how existing filter API could work with media embedding.
One more argument for improved filter API: Not all url-to-embed converters are about media (video or audio). For example embedding websites previews, display equations, chemical formulas, flowcharts and many others. There are sites that provide you with embed code to use on your website and there are filters that convert URLs to such websites into their embed code (remember that students can not use <embed> or <iframe> tags by default). It acts exactly like youtube converter in core but it is neither video nor audio.
I think we need just one filter_media that will act as abstraction layer between media html content (<video>, <audio>, legacy <a>) and Media API
If we do so how do we decide what is media and what is not, what should be implemented as media plugin and what should remain as filter? Or should we just rename "Multimedia plugin" into "Multimedia / embed plugin" ?
By the way, Sam, you said: "Marina's preferred filter option". This is not exactly true
I personally initially supported
new plugin type and later heard other opinion from Justin Hunt and
started doubting. Then I searched Plugins directory and found many
existing filters that convert link to different file types into specific
embedded code. So I thought that enhancing filter API will be easier
for developers and their existing plugins. I also think it will be easier for admins to configure everything in one place. I still do not see anything that the new plugin type can support that is not possible in filter API.