Have you tried to embed the YouTube video player in your EPUB book only to find it doesn’t work anywhere except maybe in the overly-loose browser-based Readium?
Felt the urge to rail against the EPUB working group for saying that audio and video can live outside the container only to get snagged on this problem?
You wouldn’t be the first, but opening EPUB to web-based audio and video players, as opposed to just files, is risky, and more complicated than just making an exception for “online players”.
In or Out
The reason for allowing audio and video files to be hosted outside the container is pretty obvious: they can quickly bloat the download size of your book.
But once you allow some things to live outside the container, where do you stop? There were a lot of calls for fonts to also be exempt, too, for example. (They were left as required in the container because there were potential rendering problems if the fonts had to be separately downloaded as the reader was trying to access the content, as I recall.)
It’s kind of the existential crisis of EPUB: if it’s built on the open web, why doesn’t the web integrate more seamlessly?
But being built on open web technologies doesn’t radically change that an EPUB is designed to be a self-contained package that can be read whether the reader is online or not. Moving content out to the web changes that.
In the case of audio and video, breaking from self-containment was a necessary evil. But once you move from single resources to bringing entire web pages into the EPUB, the dynamic changes considerably (no pun intended).
The difference between an audio/video player in the EPUB referencing a remote file versus referencing a remote web page that contains a player that references a remotely hosted audio-video file is magnitudes of order big.
In the first case, you can be reasonably assured of the nature of the content coming into the EPUB, since it can only be referenced/played from
video elements. In the other, you’re opening EPUB to all web pages anywhere, whether they contain media players or not, whether they are malicious or not.
Oh, by can’t you just make a little exception for YouTube… or Google Drive … or …
And that’s the problem. No you can’t. Or not in any sane way. Who’s going to maintain this list of “acceptable” web sites, how many reading system developers are going to want to deal with the bother of opening and restricting access to certain site, and what’s to say that the content hosted at those sites is what is claimed?
If you’re going to open EPUB to embedding web content, it has to be done in a broad and secure manner.
I’m not suggesting that it can never happen, but I’m sceptical, and not only because it raises the spectre of phishing and other social engineering attempts.
It’s also not in the spirit of walled gardens, either, to allow any web content to be injected into ebooks, so I wouldn’t expect broad consensus that it’s a needed feature. You might be able to slip bookstore access in that way, and no one would want that convenience! [sarcasm intended]
The solution to embedding a remote player is give up that dream for now and hyperlink out to it, at least if you want consistency. The reading system will spawn a browser window wth the video, and while it’s not seamless it’s not nothing, either. If you can’t host the files, can’t afford to host the files, or whatever the motivation for using a third-party service, it’s simply the limitation you have to work with.
I can’t get terribly worked up that we need to solve web content embedding in EPUB for audio/video service embedding (or other primary content uses cases), since there’s another layer to the problem in terms of the reliability of these services. The content you pay for becomes less complete and prone to disappear over time, unless you believe video hosting services of today will be around forever. (And I don’t like remote hosting of any resources much, for that matter.)
But then ownership and persistence seem to be dying concepts… but a rant for another day.