The PDF specification allows embedding a video or an audio file into a PDF document using rich media annotations. This annotation type is supported in our iOS, Android, and Web SDKs and can be created with Adobe Acrobat and other similar tools.
In PSPDFKit for Web, the video or audio file embedded in a document is displayed in a
<video> HTML element. According to the MDN guides, this
<video> HTML element embeds a media player that supports video playback in the browser. The newest version of HTML is HTML5, and currently, HTML5 video is the only widely supported video playback technology in modern browsers, especially since Adobe no longer supports Flash Player.
<video> element is particularly nifty. Similar to audio and image elements, it takes a path to the media element you want to display, and thanks to the
controls attribute, you can decide if you want the browser’s default video controls to show. If you’re interested, you can read the full list of attributes the
<video> element can receive.
PSPDFKit for Web introduced support for media annotations in version 2022.4. The problem the Web team faced with this task was that video and audio format support varies among browsers. The
<video> element doesn’t specify which video or audio format a browser should support, and so we decided to be as agnostic as possible by accepting any MIME type. This left us with the possibility that a certain video or audio file embedded in a media annotation might not be supported by the browser.
We had three possible solutions to address this:
Letting the browser show an error message if it can’t play a video.
Browser sniffing means to check if the current browser supports the provided media format by looking it up in a list that maps browsers to media MIME types. This approach is error prone, as any current knowledge about browser support will inevitably be incomplete and/or not up-to-date at some point. Moreover, the MIME type information may not always be available for checking, even for supported media types.
Another option is to use
HTMLVideoElement.prototype.canPlayType by including it in the file used for checking if a media file can be played:
This function returns a string that tells you how likely a media type is to play on a specific browser. The three possible results are:
""— An empty string that means the media cannot be played on the current browser.
probably— The media is likely playable.
maybe— There isn’t enough information to determine whether the media can play (until playback is actually attempted).
Showing an Error
The final option is to let the browser show an error if the MIME type isn’t supported.
This is what we used for PSPDFKit for Web, and it was the best solution for two reasons:
It aligns to the video experience a user can get in other environments on the browser; adding an ad-hoc UI could potentially be a misleading experience for end users who expect something else.
There are edge cases where the MIME type information may not be present, so
canPlayType()wouldn’t cover all situations and could potentially fail to reproduce a video even when the browser would’ve supported the format.
Video Poster Attribute
In the event of a video not being supported by the browser, you can define fallback logic to show an image that says the video format isn’t supported. This is done by using the
// If (canPlayType('my-video-type') === '' || canPlayType('my-video-type') === 'maybe') <video controls width="250" poster="/videoFormat-not-supported-fallback-image.png" > <source src="/my-video.mp4" type="video/mp4" /> Sorry, this browser doesn't support the video element. </video>
The content inside the opening and closing
<video></video> tags will be the fallback in browsers that don’t support the element, although almost all browsers (and at least all predominant browsers) support
Developing a web product always poses unexpected challenges due to the browser, and in this blog post, we wanted to give a glimpse of how we approach these kinds of issues.