- Feb 02, 2018
-
-
Jonathan Yap authored
-
- Jan 30, 2018
- Jan 26, 2018
-
-
Jonathan Yap authored
-
- Jan 19, 2018
-
-
Oz Linden authored
-
- Jan 18, 2018
-
-
Jonathan Yap authored
-
Jonathan Yap authored
-
Jonathan Yap authored
-
Oz Linden authored
-
- Jan 19, 2018
-
-
Oz Linden authored
-
- Jan 16, 2018
-
-
Jonathan Yap authored
-
Oz Linden authored
-
Oz Linden authored
-
Oz Linden authored
-
Jonathan Yap authored
-
- Jan 15, 2018
-
-
Jonathan Yap authored
-
Jonathan Yap authored
-
- Jan 14, 2018
-
-
Jonathan Yap authored
-
- Jan 13, 2018
-
-
Jonathan Yap authored
-
- Jan 12, 2018
-
-
Jonathan Yap authored
-
- Jan 11, 2018
-
-
Jonathan Yap authored
-
- Jan 05, 2018
-
-
callum_linden authored
Fix for MAINT-8119 - this bug morphed from a packaging issue to being all about audio not playing when a media stream started. There is some as yet, unknown interaction between the volume catcher code in the CEF plugin and the VLC volume controls. The fix for now is to add a Windows call to the VLC code that sets the process volume explicitly. Later we will address the volume catcher code, move it to a common spot so both CEF and LibVLC can use the same bytes
-
callum_linden authored
Fix for MAINT-8148 - AVI fails to play. For Windows, the x-msvideo MIME type was pointed at CEF which is unable to play it. Switching that to LibVLC made it work as expected. It was already switched on macOS
-
- Jan 04, 2018
-
-
Nat Goodspeed authored
-
Nat Goodspeed authored
-
- Jan 03, 2018
-
-
callum_linden authored
-
Nat Goodspeed authored
-
- Jan 02, 2018
-
-
Nat Goodspeed authored
-
- Dec 21, 2017
-
-
callum_linden authored
-
callum_linden authored
MAINT-8119 Fix. A change elsewhere in the viewer_manifest.py script that copies files into the right place after a build impacted the fragment of code that copies over the VLC runtime files (Libvlc.dll, libvlccore.dll and the VLC plugins dir) and they never made it to the right place. This change restores that copy
-
callum_linden authored
A change elsewhere in the viewer_manifest.py script that copies files into the right place after a build impacted the fragment of code that copies over the VLC runtime files (Libvlc.dll, libvlccore.dll and the VLC plugins dir) and they never made it to the right place. This change restores that copy
-
Nat Goodspeed authored
-
- Dec 20, 2017
-
-
Nat Goodspeed authored
On Windows, when logged in with a non-ASCII username, every one of the three documented APIs -- SHGetSpecialFolderPath(), SHGetFolderPath() and SHGetKnownFolderPath() -- fails to retrieve any pathname at all. We cannot account for the fact that the oldest of these continues to work with the release viewer and within a Python script (though not, curiously, from a Python interactive session). With a non-ASCII username, they consistently fail when called from an Alex Ivy viewer build: "The filename, directory name, or volume label syntax is incorrect." Empirically, with a non-ASCII username, the preset APPDATA and LOCALAPPDATA environment variables are also useless, e.g. c:\Users\??????\AppData\Roaming where those are, yup, actual question marks. Empirically, the VMP is able to successfully call SHGetFolderPath() to retrieve both AppData\Roaming and AppData\Local. Therefore, we make the VMP set the APPDATA and LOCALAPPDATA environment variables to the UTF-8 encoded correct pathnames. Instead of calling SHGetSomethingFolderPath() at all, make LLDir_Win32 retrieve those environment variables. Make LLFile::mkdir() treat "directory already exists" as a success case. Every single call fell into one of two categories: either it didn't check success at all, or it tested specially to exempt errno == EEXIST. Migrate that test into mkdir(); eliminate it from call sites. Make LLDir::append() and add() convenience functions accept variadic arguments. Replace add(add()...) constructs, as well as clumsy concatenations of directory names and getDirDelimiter(), with simple variadic add() calls.
-
Nat Goodspeed authored
-
Nat Goodspeed authored
-
Oz Linden authored
-