> On Oct 27, 2021, at 7:10 PM, Jim Ham wrote:
>
> One of my testers replied as follows:
[…]
> "QuickTime Player cannot open because it does not recognize internet
> addresses starting with "rtsp"."
>
> Another one of my testers replied:
>
> "QuickTime Player doesn’t support mkv files
These
I left out the URL that my testers are useing:
"rtsp:://.mkv"
I have a small pipe, so I'm hesitant to put the real address on the list
server. If you'd like to try this yourself contact me back channel.
Jim
On 10/26/2021 10:56 PM, Ross Finlayson wrote:
On Oct 27, 2021, at 6:31 PM, Jim Ham
I have no personal experience here. One of my testers replied as follows:
"I couldn't open these in QuickTime Player. Got the following message.
Google search suggests this was supported in older versions, but can't
find anything that speaks to the current version. Maybe it works with QT
on wi
> On Oct 27, 2021, at 6:31 PM, Jim Ham wrote:
>
> I've been testing our (your) server with users, apparently Quick Time no
> longer supports .mkv files. VLC works fine on a Mac. What's up with Apple?
Can you clarify what you mean here?
When you say "Quick Time no longer supports .mkv files”,
I've been testing our (your) server with users, apparently Quick Time no
longer supports .mkv files. VLC works fine on a Mac. What's up with Apple?
If this is true you might want to update your web site.
Jim Ham
--
Porcine Associates LLC
244 O'Connor St.
Menlo Park, CA 94025
USA
+1(650)326-2669
> On Oct 27, 2021, at 5:29 AM, Jonathan Brady via live-devel
> wrote:
>
> • On Windows setlocale is not thread safe
> •
> https://social.msdn.microsoft.com/Forums/windowsserver/en-US/b46aa226-d337-43c3-8d15-135f6fca9b53/setlocale-behavior-in-multithreaded-applications?foru
--- Begin Message ---
Hello,
After spending 10 seconds googling "setlocale crash" I can inform you that:
* On Windows setlocale is not thread safe
o
https://social.msdn.microsoft.com/Forums/windowsserver/en-US/b46aa226-d337-43c3-8d15-135f6fca9b53/setlocale-behavior-in-multithreaded-applic
Hi Ross,
Yes, very familiar with the FAQs, we certainly fall into this category
during the single process test:
"Another possible way to access the code from multiple threads is to
have each thread use its own "UsageEnvironment" and "TaskScheduler"
objects, and thus its own event loop. The o
I didn’t really follow this. However, I was disturbed by the following:
> By default the NEWLOCALE_NOT_USED is defined and works great when we run up
> many streaming windows all in separate process's.
> If we use a single process (less memory consumed by NVIDIA graphics) we see
> an access vio
