Thanks Armin, I was able to get Openh264 working and it keeps bandwidth down to
about 1mbps even with lots of screen updating.
CPU usage is a bit high when using VMs on my MAC, but the client/decoder end
only used about 6% CPU on my 7 year old i7 hypertheaded quadcore running
windows 7.
alf
On 8/9/18, 3:09 AM, "Armin Novak via FreeRDP-devel"
<freerdp-devel@lists.sourceforge.net> wrote:
CAUTION: This email originated from outside of the organization. Do not
click links or open attachments unless you recognize the sender and know the
content is safe.
Hi,
You're correct, the /gfx:avc444 parameter of the client announces that
capability to the server. (if the client is compiled with support)
The server is always free to send whatever it deems best.
As for the crash, the windows shadow server (as the whole windows port)
is in need of some testing.
What might be the reason is the H264 backend compiled in, you might want
to start with OpenH264 which is tested for various platforms and check
if it works with that.
The windows specific backend should work, but then again, that was some
time ago.
best
Armin
On 08/08/2018 08:26 PM, Alfred Eisenberg (aeisenbe) via FreeRDP-devel wrote:
> Hi, I’ve built freerdp (very recent master) with options -DWITH_SSE2=ON
-DWITH_SERVER=ON. On windows 10.
>
> I run the server with just the port:xxxx argument, and wfreerdp with just
/v:host:port.
>
> Bandwidth usage seems a bit high, but not much different than Microsoft
rdp client/server while watching a similar scrolling window.
>
> I assume that turning on H.264 would help with bandwidth usage.
>
> I've been poking around in code and debugger to figure out when H264 gets
used and found it does with /GFX-H264 on the client command line.
>
> When I use this setting, the server side crashes shortly after it sends a
few frames in some memcpy operation. Call stack doesn't help at that point
(different thread with memcpy as only frame)
>
> I also tried with /GFX-H264:AVC420 (which I think it used by default with
just GFX-H264) as well as :AVC444, but that also crashed. I did validate in
the debugger that it was actually calling the avc420_compress as well as
avc444_compress when I specified those options on the client.
>
> Anyone else have any luck with these options?
>
> Any hints to figure out what's going on?
>
> My setup is using 2 Windows 10 VMs running on VMWare fusion 10.1.2.
>
> alf
>
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
FreeRDP-devel mailing list
FreeRDP-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freerdp-devel
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
FreeRDP-devel mailing list
FreeRDP-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freerdp-devel
