search

Neos-Metaverse / NeosPublic

A public issue/wiki only repository for the NeosVR project
195 stars 9 forks source link

Switch to official libVLC library from UMP #660

Open sirkitree opened 4 years ago

sirkitree commented 4 years ago

Working with some new video textures on some mandala meshes, I've had multiple crashes since video handling was changed the other week.

Here are the logs from the last two consecutive crashes:

The general workflow of these sessions:

  1. open Neos
  2. navigate to Local from hand world tab orbs
  3. start a new world with space template
  4. import mesh from File Browser
  5. navigate to Local from hand world tab orbs
  6. open a local world that has previously imported video textures and start video player
  7. grab video texture from local world with material gun
  8. navigate to the newly started template world from hand world tab orbs
  9. apply video texture to imported mesh and drop the material orb in this world
  10. navigate back to local world that has previously imported video textures, start a new video player, grab it's texture
  11. take this back to the newly started template world from hand world tab orbs
  12. apply video texture
  13. wait for maybe 5 minutes and experience a full Neos freeze and then crash, losing any unsaved progress

Here is the video files I am using:

Here is the mesh I am using:

Here is a link to an uploaded world:

shiftyscales commented 4 years ago

Do you have the Player.log/error.log for these crashes? You should be able to find them at %USERPROFILE%\AppData\Local\Temp\Solirax\NeosVR\Crashes.

shiftyscales commented 4 years ago

I haven't been able to replicate it yet, but given what I am seeing, I think it's most likely just the standard libVLC crashing that's been an issue for a long time now. The Player.log/error.log would likely confirm this too if you have them.

sirkitree commented 4 years ago

Crashes.zip

Frooxius commented 4 years ago

Unfortunately these crashes are coming from the UMP libVLC wrapper library, so fixing it is out of our hands at the moment, as this library hasn't been updated in a really long while.

Currently I'm waiting on the official libVLCsharp library to get to usable state, so we can swap over to it as our general playback engine, but that's probably still going to take a while: https://code.videolan.org/videolan/vlc-unity

For the time being, I'd strongly recommend re-encoding the videos so the Unity Native playback can be used instead. Using MP4 with H.264 and AAC audio should work well for this.

sirkitree commented 4 years ago

Thanks! I've switched the engine in-world through the inspector and it seems to be stable.

TehTurk commented 4 years ago

Would it be possible to have Youtube Dl import perfer the Unity Playback meanwhile? This is an issue for some users currently.

shiftyscales commented 4 years ago

I believe it already does prefer Unity's playback engine where/when it can, @TehTurk. The issue is the Unity playback engine passes off decoding to system codecs, and if it's a file type it can't recognize/process, it'll actually crash Unity, or have other playback issues, e.g. screeching audio as it tries to process nonsense data. So Unity's playback engine can only be used for a very narrow range of codecs where support is near guaranteed. For everthing else, we need to rely on libVLC.

Frooxius commented 4 years ago

Just to update, I'm planning to switch to the official libVLCsharp library as soon as possible, but we're currently waiting on this fix to go live: https://code.videolan.org/videolan/vlc-unity/-/issues/84

Once that's out that should unblock the integration and I can do the swap (assuming no other problems arise).

Enverex commented 4 years ago

That would be good. It's reached the point where I've had to disable all video players in most my worlds now as I and anyone that joins will crash out in a few minutes at most. Oddly enough some worlds are completely unaffected so there seems to be some secondary action that triggers the crash, but nothing immediately stands out as being the cause. I have around 10 crash logs from incidents if they'd be of any use.

Frooxius commented 4 years ago

The crash logs unfortunately don't help in this case. The UMP library is a binary blob, so I can't make any fixes to it myself and the authors haven't updated it in well over a year, so I think the project is pretty much abandoned now.

From what I could guess, it happens when you have more than one video and with some special condition, the crashes/high CPU usage seems to come from some thread synchronization resources, so it's probably some kind of race condition on shared resources.

Race conditions can be heavily system/situation dependent too. E.g. there was one with UIX that wouldn't affect most people, but would reliably break UIX within seconds for a few users, so we might be dealing with similar case, but without access to source to fix it.

If that issue with the official libVLCsharp was fixed already we'd have swapped already, it's pretty high priority.

uyjulian commented 3 years ago

It looks like the libvlc fix was already merged upstream: https://code.videolan.org/videolan/vlc/-/commit/850c708678992a21c6111abb9c79135a4dc618cd

Maybe libvlc.dll and libvlccore.dll (and associated plugins) just needs to be replaced with the latest build? https://code.videolan.org/videolan/vlc/-/jobs/485768/artifacts/file/nightlies/vlc-4.0.0-dev-win64-2a988cc4.7z

Frooxius commented 3 years ago

I've tried updating the binaries manually before, but that didn't seem to resolve the issue.

sirkitree commented 3 years ago

I've noticed that this seems to happen when you try to mix both in one world. If they're all libvc or they're all unity then you last much longer (but do eventually crash).

Geenz commented 3 years ago

Taking this one on - some work has already been done, but there's still a good ways to go.

RoxyBoxxy commented 3 years ago

Is there any development on this, and will it support build in subtitles from a mkv file