Author Topic: WebM (.webm) container support  (Read 2487 times)

Patrick

  • Guest
WebM (.webm) container support
« on: 9 Aug '18 - 00:36 »
I get audio in .webm container format which has Opus or Vorbis audio without any video. Normally it would play without the container, but the container is a limiting factor.

Would it be easy to make a plugin to handle these containers?

Ian @ un4seen

  • Administrator
  • Posts: 22959
Re: WebM (.webm) container support
« Reply #1 on: 9 Aug '18 - 16:56 »
XMPlay doesn't currently have a container plugin system, so it unfortunately wouldn't be possible to have a plugin that just handles the WebM stuff; it would need to include Opus and Vorbis decoders too.

r

  • Posts: 200
Re: WebM (.webm) container support
« Reply #2 on: 1 Apr '20 - 23:22 »
I know this is a little old, but since BASSWEBM was released in 2019, any chance at a XMPlay WebM plugin, Ian?

Ian @ un4seen

  • Administrator
  • Posts: 22959
Re: WebM (.webm) container support
« Reply #3 on: 3 Apr '20 - 13:28 »
XMPlay still has the issue that a WebM plugin wouldn't currently be able to fully access the other decoders (BASSWEBM can access BASS/add-on decoders). I'll need to think of how to best overcome that, eg. either include Vorbis and Opus decoders in a WebM plugin, or add some way for a WebM plugin to access the existing Vorbis and Opus decoders. Another option could be to include WebM (and Vorbis) support in the Opus plugin.

r

  • Posts: 200
Re: WebM (.webm) container support
« Reply #4 on: 3 Apr '20 - 22:37 »
Most of the .webm audio streams are using Opus as their main codec anyway, so I think the option to add WebM and OGG support to the Opus plugin would be a great solution, Ian.

Ian @ un4seen

  • Administrator
  • Posts: 22959
Re: WebM (.webm) container support
« Reply #5 on: 13 Apr '20 - 15:24 »
I went ahead with adding WebM support to the existing Opus plugin, and I think it's almost ready now. There will probably be an update to try sometime this week.

r

  • Posts: 200
Re: WebM (.webm) container support
« Reply #6 on: 15 Apr '20 - 09:01 »
Awesomesauce. Looking forward to it!
Thanks Ian!

Ian @ un4seen

  • Administrator
  • Posts: 22959
Re: WebM (.webm) container support
« Reply #7 on: 15 Apr '20 - 15:35 »
Here's the updated Opus plugin, with support for WebM (also Matroska files with Opus or Vorbis audio):

   www.un4seen.com/stuff/xmp-opus.dll

Please report any problems. It seems to be working quite nicely so far but hasn't been tested a lot yet.

r

  • Posts: 200
Re: WebM (.webm) container support
« Reply #8 on: 15 Apr '20 - 23:27 »
I just tried some .webm files that I grabbed from YouTube and they all played just fine.

Thanks Ian!

saga

  • Posts: 2420
Re: WebM (.webm) container support
« Reply #9 on: 24 Apr '20 - 21:59 »
I tried the updated Opus plugin (from the main site) with a webm file and it crashed. I uploaded the webm file to the FTP (Johnny One.webm).

Ian @ un4seen

  • Administrator
  • Posts: 22959
Re: WebM (.webm) container support
« Reply #10 on: 27 Apr '20 - 15:02 »
Strange, the uploaded file seems to be OK here. Perhaps it's another plugin that's crashing with the file? For more info, please generate and upload a dump file from the crash. You can generate a dump file using the ProcDump tool. Run "procdump -e -ma -x . xmplay.exe", and then ZIP and upload the generated dump file to have a look at here:

   ftp.un4seen.com/incoming/

saga

  • Posts: 2420
Re: WebM (.webm) container support
« Reply #11 on: 27 Apr '20 - 17:32 »
I've uploaded the dump (xmplay.exe_200427_183016.dmp), the top stack frame points at xmp-opus.dll. Before crashing, XMPlay itself also says: "The "Opus and WebM (rev.7)" plugin crashed while attempting to scan the following file:"
The crash happens while scanning the file. The first time I ran procdump, XMPlay didn't crash for some reason, and then subsequent attempts at playing the file also didn't crash (even without procdump attached).

Ian @ un4seen

  • Administrator
  • Posts: 22959
Re: WebM (.webm) container support
« Reply #12 on: 27 Apr '20 - 17:49 »
Ah! I see it now, thanks. Was a silly tag scanning change just before release. An update (rev.7a) to fix that is up now on the XMPlay page.