Hello everyone,
I need basic audio/video (e.g. mp3 and mp4) codecs on WebKit on Windows.
I know that Chromium supports only a few audio/video codecs (as stated here)
That said, from Xojo HTMLViewer documentation, I read:
"To make plugins available to WebKit on Windows, create a folder called WebKitPlugins within your Libs folder in your application folder and place the plugins you need there"
From a little research, the plugins avcodec-52.dll, avformat-52.dll, and avutil-50.dll (or later versions) should do the trick but I had no success.
I see that those files are already present in the Libs folder, so I tried to copy them also to Libs/WebKitPlugins. Again, no success.
This work-around allows us to play .mp3 sound, “floating” .mp4 video, and embedded .mp4 video in local HTML content using the WebKit HTML Viewer on Windows.
Note that if you are not running local content, it may be much simpler to use the native/IE HTML viewer. But we ran into many limitations with the local/IE HTML viewer when trying to display local content (existing on the local computer, not from a Web server.)
If you are running local content, you will probably need to modify that content, either in advance or while loading into the HTML viewer. And, for embedded .mp4 videos in the WebKit HTML viewer, I’m afraid your users will have to have QuickTime installed. ;-(
When using IE make sure you use the appropriate tags in the header to force it to use the latest version available on the machine instead of its normal compatibility mode
That does help with some things, but the main limitations we ran into related to IE security restriction when using local content. It seems that IE will do many things correctly when viewing Web/server-based content, but has enforces significant limitations when viewing local content. And local content is pretty important for a fair number of our users as we’re creating/delivering educational content for use in emerging markets–places where Internet connections are slow/rare or non-existent.
Safari literally has no handler for “file:///” - thats why it refuses - which is not the same as why IE refuses
IE does have a handler but mistrusts local content
There are hacks that let you add file:// url schemes to iOS but they require you to jailbreak your device
Or other browsers for iOS that do handle that scheme (goodbrowser etc)
The choice to not provide access to this URL scheme on iOS is one I dont agree with BUT I understand why they do it
It’s for the same reason you dont have direct access to the file system in the iOS UI
I use a ton of “file:///” urls in IE11 and they work fine. Edge, however, chokes on them (but for better or worse, the Edge browser engine is not available to HTMLViewers).
(I’m talking about “file:///” URLs inside a file with a .html extension that’s stored on the local hard drive - perhaps that’s not the same as what you are doing?)
