moonlight-stream / moonlight-common-c Goto Github PK

First I'll let everyone know that I'm a junior dev at best, and I'm still in school. For the most part I don't really know what's going on, so expect some ignorance and such.

I've been trying to fix my Vita crashing when I stream from my computer, and so I forked vita-moonlight (right here) and I managed to get it to build.

To get it to build, I had to add
-DNO_MSGAPI
to the C flags as CMSG_FIRSTHDR and CMSG_NXTHDR don't seem to exist in the vita sdk.

From here, I can parse coredumps but that's about it.
Here's the Dissasembly around a few:

=== THREAD "ControlRecv" <0x4001019b> CRASHED (Data abort exception) ===

DISASSEMBLY AROUND PC: 0x8103c71c (ARM):

8102f70c <enet_protocol_dispatch_incoming_commands+0xf8>:

if (! enet_list_empty (& peer -> dispatchedCommands))
{
peer -> flags |= ENET_PEER_FLAG_NEEDS_DISPATCH;

enet_list_insert (enet_list_end (& host -> dispatchQueue), & peer -> dispatchList);
8102f70c:       4611            mov     r1, r2
8102f70e:       4618            mov     r0, r3
8102f710:       f7fe fbf0       bl      8102def4 <enet_list_insert>
}

return 1;
8102f714:       2301            movs    r3, #1
8102f716:       e009            b.n     8102f72c <enet_protocol_dispatch_incoming_commands+0x118>

default:
break;
8102f718:       bf00            nop
while (! enet_list_empty (& host -> dispatchQueue))
8102f71a:       687b            ldr     r3, [r7, #4]
!!!             f8d3 20b8       ldr.w   r2, [r3, #184]  ; 0xb8 !!!
8102f720:       687b            ldr     r3, [r7, #4]
8102f722:       33b8            adds    r3, #184        ; 0xb8
8102f724:       429a            cmp     r2, r3
8102f726:       f47f af7b       bne.w   8102f620 <enet_protocol_dispatch_incoming_commands+0xc>
}
}

return 0;
8102f72a:       2300            movs    r3, #0

coredump1.txt

Dump2:

DISASSEMBLY AROUND PC: 0x8123a2ec (ARM):

8121c2dc <_vfprintf_r+0x24>:
8121c2dc:       f1b9 0f00       cmp.w   r9, #0
8121c2e0:       d004            beq.n   8121c2ec <_vfprintf_r+0x34>
8121c2e2:       f8d9 3038       ldr.w   r3, [r9, #56]   ; 0x38
8121c2e6:       2b00            cmp     r3, #0
8121c2e8:       f000 81d5       beq.w   8121c696 <_vfprintf_r+0x3de>
!!!             f9bb 300c       ldrsh.w r3, [fp, #12] !!!
8121c2f0:       049e            lsls    r6, r3, #18
8121c2f2:       b29a            uxth    r2, r3
8121c2f4:       d40a            bmi.n   8121c30c <_vfprintf_r+0x54>
8121c2f6:       f443 5300       orr.w   r3, r3, #8192   ; 0x2000
8121c2fa:       b29a            uxth    r2, r3

coredump2.txt

Dump3:

=== THREAD "AudioRecv" <0x400101ad> CRASHED (Data abort exception) ===

DISASSEMBLY AROUND PC: 0x8104a6a4 (ARM):

81017694 <AudioReceiveThreadProc+0xac>:
ListenerCallbacks.connectionTerminated(-1);
break;
}
}

packet->header.size = recvUdpSocket(rtpSocket, &packet->data[0], MAX_PACKET_SIZE, useSelect);
81017694:       693c            ldr     r4, [r7, #16]
81017696:       f897 3027       ldrb.w  r3, [r7, #39]   ; 0x27
8101769a:       f44f 62af       mov.w   r2, #1400       ; 0x578
8101769e:       f009 fccb       bl      81021038 <recvUdpSocket>
810176a2:       4603            mov     r3, r0
!!!             60e3            str     r3, [r4, #12] !!!
if (packet->header.size < 0) {
810176a6:       693b            ldr     r3, [r7, #16]
810176a8:       68db            ldr     r3, [r3, #12]
810176aa:       2b00            cmp     r3, #0
810176ac:       da2a            bge.n   81017704 <AudioReceiveThreadProc+0x11c>
Limelog("Audio Receive: recvUdpSocket() failed: %d\n", (int)LastSocketError());
810176ae:       f64f 23a4       movw    r3, #64164      ; 0xfaa4
810176b2:       Address 0x00000000810176b2 is out of bounds.

coredump3.txt

I apologize for the long post but I wanted to include as much information as I could. I'll provide anything else that's needed.

Nowadays, almost all clients are using BT.709 and full color range, and the network usage should be acceptable.
Maybe compatibility of color range was a thing when the library was created, but now every modern tv is able to show contents with full RGB range.
I think it is time to change the defaults.

I believe that in AudioStream.c
#define RTP_RECV_BUFFER (64 * MAX_PACKET_SIZE)
should be
#define RTP_RECV_BUFFER (64 * 1024)
Much like moonlight-common

Changing this fixes issues when running Surround sound on the newer Gens of GFE, at least for Moonlight on RPi 1/2/3.

In vita-moonlight cases,

=== THREADS ===
    XYZZ00002
        ID: 0x40010003
        Stop reason: 0x0 (No reason)
        Status: 0x8 (Waiting)
        PC: 0x811ceca8 (moonlight.elf@1 + 0x18fca8)
    SceCommonDialogWorker
        ID: 0x40010073
        Stop reason: 0x0 (No reason)
        Status: 0x8 (Waiting)
        PC: 0xe000a154 (SceLibKernel@1 + 0x6304)
    
        ID: 0x4002009d
        Stop reason: 0x0 (No reason)
        Status: 0x8 (Waiting)
        PC: 0x811cebd8 (moonlight.elf@1 + 0x18fbd8)
    
        ID: 0x400200b1
        Stop reason: 0x0 (No reason)
        Status: 0x8 (Waiting)
        PC: 0xe0009f94 (SceLibKernel@1 + 0x6144)
    vitapower_thread
        ID: 0x400100b3
        Stop reason: 0x0 (No reason)
        Status: 0x8 (Waiting)
        PC: 0x811cebd8 (moonlight.elf@1 + 0x18fbd8)
    vitainput_thread
        ID: 0x400100b5
        Stop reason: 0x0 (No reason)
        Status: 0x8 (Waiting)
        PC: 0x811cebd8 (moonlight.elf@1 + 0x18fbd8)
    SceGxmDisplayQueue
        ID: 0x400100c5
        Stop reason: 0x0 (No reason)
        Status: 0x8 (Waiting)
        PC: 0xe000a564 (SceLibKernel@1 + 0x6714)
    
        ID: 0x400200f1
        Stop reason: 0x30004 (Data abort exception)
        Status: 0x1 (Running)
        PC: 0x81065102 (moonlight.elf@1 + 0x26102)
    
        ID: 0x400200f3
        Stop reason: 0x0 (No reason)
        Status: 0x8 (Waiting)
        PC: 0x811cebd8 (moonlight.elf@1 + 0x18fbd8)
    
        ID: 0x400200f5
        Stop reason: 0x0 (No reason)
        Status: 0x8 (Waiting)
        PC: 0x811cebd8 (moonlight.elf@1 + 0x18fbd8)
    
        ID: 0x400200f7
        Stop reason: 0x0 (No reason)
        Status: 0x8 (Waiting)
        PC: 0xe01db3c8 (SceNet@1 + 0xa148)
    
        ID: 0x400200f9
        Stop reason: 0x0 (No reason)
        Status: 0x8 (Waiting)
        PC: 0xe0009f94 (SceLibKernel@1 + 0x6144)

=== THREAD "" <0x400200f1> CRASHED (Data abort exception) ===

DISASSEMBLY AROUND PC: 0x81065102 (ARM):

000260f2 <reed_solomon_decode.isra.2+0x6>:
 * dec_fec_blocks[nr_fec_blocks][block_size]
 * fec_block_nos: fec pos number in original fec_blocks
 * erased_blocks: erased blocks in original data_blocks
 * nr_fec_blocks: the number of erased blocks
 * */
static int reed_solomon_decode(reed_solomon* rs, unsigned char **data_blocks, int block_size, unsigned char **dec_fec_blocks, unsigned int *fec_block_nos, unsigned int *erased_blocks, int nr_fec_blocks) {
   260f2:	3d83      	subs	r5, #131	; 0x83
   260f4:	b089      	sub	sp, #36	; 0x24
   260f6:	4692      	mov	sl, r2
   260f8:	f50d 3483 	add.w	r4, sp, #67072	; 0x10600
   260fc:	3454      	adds	r4, #84	; 0x54
   260fe:	f8d4 b000 	ldr.w	fp, [r4]
!!! 		9101      	str	r1, [sp, #4] !!!
   26104:	9305      	str	r3, [sp, #20]

    /* the erased_blocks should always sorted
     * if sorted, nr_fec_blocks times to check it
     * if not, sort it here
     * */
    for (i = 0; i < nr_fec_blocks; i++) {
   26106:	f1bb 0f00 	cmp.w	fp, #0
   2610a:	dd1f      	ble.n	2614c <reed_solomon_decode.isra.2+0x60>
   2610c:	f50d 3383 	add.w	r3, sp, #67072	; 0x10600
   26110:	2500      	movs	r5, #0


DISASSEMBLY AROUND LR: 0x81065aec (Thumb):

00026adc <reed_solomon_reconstruct+0xe0>:
                    pn++;
                }
            }

            if (dn == pn) {
                reed_solomon_decode(rs, data_blocks, block_size, dec_fec_blocks, fec_block_nos, erased_blocks, dn);
   26adc:	9702      	str	r7, [sp, #8]
   26ade:	f8cd 8004 	str.w	r8, [sp, #4]
   26ae2:	f8cd e000 	str.w	lr, [sp]
   26ae6:	9809      	ldr	r0, [sp, #36]	; 0x24
   26ae8:	f7ff fb00 	bl	260ec <reed_solomon_decode.isra.2>
!!! 		e7de      	b.n	26aac <reed_solomon_reconstruct+0xb0> !!!
    int err = 0;
   26aee:	2300      	movs	r3, #0
   26af0:	9308      	str	r3, [sp, #32]
        fec_blocks += ps;
        fec_marks += ps;
    }

    return err;
}
   26af2:	9808      	ldr	r0, [sp, #32]
   26af4:	f60d 4d24 	addw	sp, sp, #3108	; 0xc24
   26af8:	e8bd 8ff0 	ldmia.w	sp!, {r4, r5, r6, r7, r8, r9, sl, fp, pc}

REGISTERS:
    R0: 0x8147a830
    R1: 0x814eef50
    R2: 0x81464520
    R3: 0x410
    R4: 0x8348033c
    R5: 0x5
    R6: 0x81464580
    R7: 0x83480b54
    R8: 0x83480758
    R9: 0x8146c1df
    R10: 0x81464520
    R11: 0x1
    R12: 0x8348035c
    SP: 0x8346fce8
    PC: 0x81065102 (moonlight.elf@1 + 0x26102)
    LR: 0x81065aed (moonlight.elf@1 + 0x26aed)

STACK CONTENTS AROUND SP:

Moonlight Embedded 2.1.4 (EMBEDDED;PI)
Searching for server...
Connect to 192.168.1.2...
NVIDIA GeForce GTX 980, GFE 2.11.2.46 (protocol version 7)
Stream 1280 x 720, 60 fps, 10000 kbps
Initializing platform...done
Resolving host name...done
Starting RTSP handshake...RTSP SETUP streamid=audio request failed: 404
failed: 404
^CCleaning up platform...done

Mouse is too touchy while streaming - bug is probably in Common since it affects multiple clients.

To my surprise I discovered that unlike the moonlight-common repository their is no license included in the moonlight-common-c repository. While the usage in moonlight-chrome and moonlight-ios and the inclusion
of ported code from moonlight-common at least indicates its available under a GPLv3 (compatible) license it would probably be better if the license is clearly stated. Just in case someone wants to use it in a new port ;)

Greetings moonlighters, fantastic project.

Having this module in LGPLv3 would be interesting from my perspective and future projects. Would the moonlight contributors consider the switch ?

Kinda like what the folks at VLC did with libVLC while keeping their client GPLv2. I think it's a smart move in the long run.

It sees my games, but I get the error "cannot launch the game as its been started locally (error 526). No games are running locally.Reinstall GFE also didn't work, neither did turning off my firewall.
If I run it with only GFE alone it works perfectly.

hi, is there any documents or simple demo on howto use this library?

thank you!

Is there any way to run moonlight on a Samsung TV's built in OS without having to use any external device/computer connected to the TV? I am getting a new Samsung TV for my Game room and I wanted an easier way to connect my PC to my TV without HDMI Cables.

Found this issue in mariotaku/moonlight-tv#76, where moonlight-common-c has been updated from
122ce4a to b58930c. Not sure if it should be triaged to Sunshine or here.

Logs:

000086.061 [Limelight][INFO] Audio block size mismatch (got 84, expected 83)
000086.061 [Limelight][INFO] Audio block size mismatch (got 84, expected 83)
000086.061 [Limelight][INFO] Unable to recover audio data block 9608 to 9611 (2+0=2 received < 4 needed)
000086.062 [Limelight][INFO] Network dropped audio data (expected 9610, but received 9612)
000086.066 [Limelight][INFO] Audio block size mismatch (got 84, expected 82)
000086.066 [Limelight][INFO] Audio block size mismatch (got 83, expected 82)
000086.066 [Limelight][INFO] Audio block size mismatch (got 83, expected 82)
000086.066 [Limelight][INFO] Unable to recover audio data block 9612 to 9615 (1+0=1 received < 4 needed)
000086.086 [Limelight][INFO] Network dropped audio data (expected 9613, but received 9616)
000086.095 [Limelight][INFO] Audio block size mismatch (got 84, expected 83)
000086.095 [Limelight][INFO] Audio block size mismatch (got 85, expected 83)
000086.095 [Limelight][INFO] Unable to recover audio data block 9616 to 9619 (2+0=2 received < 4 needed)
000086.106 [Limelight][INFO] Network dropped audio data (expected 9618, but received 9620)
000086.106 [Limelight][INFO] Audio block size mismatch (got 83, expected 82)
000086.106 [Limelight][INFO] Audio block size mismatch (got 83, expected 82)
000086.106 [Limelight][INFO] Audio block size mismatch (got 88, expected 82)

I found that response.payload not include a string "sprop-parameter-sets=AAAAAU", so fail to set NegotiatedVideoFormat as h265, even if it is forced to set, but h264 is ok.

Duh, just figured out moonlight-stream/moonlight-common-android#23 was archived altogether.

So, to recap: there were some attempts here and there to reverse steam IHS, but nothing extraordinary.
To this day there's still no FOSS host solution (the half-backed switch-focused one is now dead)

As a matter of fact anyway, I just found out that another kind of native client exists
https://github.com/thestr4ng3r/chiaki

As the title means, does the protocol is free to use and open to public? I cannot find more infomation on NV web.

I've been having a multi platform issue with this app. For some reason the game stream won't go above 30 - 33 FPS. On my PC it's normal. I'm currently running the host off my gaming laptop (Asus, Ryzen 9, 3070, 16RAM). It's plugged into my Ethernet.

Let me know what other information I can give. I'm hoping to use Moonlight as it's way better than most streaming software.

Check out Valve's Steam Link app for Android. It would be cool to see the functionality offered by that app rolled into moonlight. What are the chances the moonlight client can be extended to not only connect to nvidia gamestream servers but also to computers set up to stream games via Steam's built-in game streaming functionality?

I'm not 100% sure why, but steam has stopped recognizing the virtual controller from both the switch app and the mobile app. In the device manager, an Xbox 360 controller for windows appears when I connect with moonlight, but with the following status:

This device cannot start. (Code 10)

STATUS_DEVICE_POWER_FAILURE

I think the cause might have something to do with steams extended feature support? Would love ideas.

Hosts with end-to-end (rather than NAT64) IPv6 connectivity issues with the client may attempt to use IPv6 for streaming. This causes the stream to fail because GFE isn't IPv6-ready. We should only allow IPv6 addresses if they're NAT64 or we have no IPv4 addresses for the host name.

See moonlight-stream/moonlight-embedded#352

Just spotted this when trying to compile moonlight-embedded for Raspberry Pi.
In LinkedBlockingQueue.h,

#include "platform.h"

should be

#include "Platform.h"

Cheers!

I believe this applies to all moonlight clients, so instead of duplicating multiple times, I'm putting here (apologies if this is not the right location).

Currently when using a gamepad, the way to exit a stream is by simultaneously pressing L1+L2+START+SELECT. This can present challenges with some gamepads that don't natively have these buttons and am requesting the ability to remap them.

Thanks in advance.

Is there any documentation or blog posts that cover the protocol itself?

PerformRTSPHandshake in RTSPConnection.c only returns -1; not useful for debugging errors.

@cgutman has a related issue here: moonlight-stream/moonlight-ios#100 but opening an issue in this repo so I remember to do it :)

I just commented the rationale behind why we're adding 4, for example, when really we should have a #define (though comments are good too :) )

This allows us to remove the need to select() before all packets received. Instead we should be in non-blocking mode and just try recv() first before going to select(). I'll investigate this after work on ENet is done (in case that complicates things).

Can someone port moonlight to 3ds?(sorry that this is not an issue but i don't know how to ask it)

Has anyone looked into the feasibility of a Nintendo Switch port yet? If so, what kinds of complications were ran into? I'm interested in seeing this port made, perhaps doing it myself if it's not in the works but I'm not sure where I'd start.

.LimeLog: Too much pending audio data: 40 ms
I/moonlight-common-c: Recovered 1 audio data shards from block 8804
D/BufferPoolAccessor2.0: bufferpool2 0xb400007d08f41628 : 4(6914048 size) total buffers - 4(6914048 size) used buffers - 0/4 (recycle/alloc) - 19/1085 (fetch/transfer)
A/libc: moonlight-common-c/src/AudioStream.c:219: void decodeInputData(PQUEUED_AUDIO_PACKET): assertion "decryptedOpusData[0] == opusHeaderByte" failed
A/libc: Fatal signal 6 (SIGABRT), code -1 (SI_QUEUE) in tid 21615 (Thread-158), pid 21195 (limelight)
I/moonlight-common-c: Audio packet queue overflow
D/PipelineWatcher: onInputBufferReleased: frameIndex not found (1101); ignored
I/moonlight-common-c: Audio packet queue overflow
I/moonlight-common-c: Audio packet queue overflow
I/moonlight-common-c: Audio packet queue overflow

Hi, thanks for your hard work! I'm developing a version of moonlight for nintendo switch and I have some problems related only to switch and I have no idea how to debug it, may be you could help me with it. Thanks in advance!

First of all this commit entirely broke nintendo switch support:
After LiStartConnection() called, streaming picture and sound appears but input immediately stuck, after a few seconds audio and video also stuck and app becomes unresponsive.

I hotfixed it here and moonlight becomes almost fully playable, with good wifi connection I could play for several hours with no problem. But with bad connection problems appears:

First, something one (audio, video, input) could stuck, after a few seconds it starts work fine, but something else stuck instead, and so on, something will always stuck until an entire app freezes. If I'll try to close connection when something already start to freeze, app will crash. These symptoms are similar to behaviour without my fix so may be it could be related.

I don't know how even debug that thing, I could provide anything you need to help me (logs, compiler defines, may be something else), but not stucktrace cause I don't know how to get it on switch.

Hello,
I want to integrate this into the iOS project. There it says its missing liblimelight-common.a. I have compiled this library and got a bunch of .obj and a .lib file. Now what do I have to do?

LiStopConnection() can cause exceptions to be raised on Windows because it closes handles underneath pending send() and recv() calls. It is generally most visible on Windows but affects all platforms. I think there may be issues with mutexes too.

I think we'll need to use non-blocking socket I/O to fix the socket part of this.

Hi,author, I am interested in developing a new software to facilitate people's life basing on this powerful source code you big-god contributed. Is this a free source-code and anyone can use it to do anything? If not what should I do?
Best wishes.

Not sure if it's possible.

It would be amazing if you could simultaneously stream to a couple of clients at once for playing multiplayer games remotely.

I do not have any drm content open when this happens, and I am trying to stream remotely

It would be nice to get Moonlight server. Can make a simple implementation (without GPU Nvidia feature) compatible with moonlight clients, and later someone can figure out (after reverse engineering) and make Nvidia feature (GPU support for streaming) and on AMD (feature off). However, in any case, we will have a good protocol for streaming games or apps without Nvidia GeForce Experience.

If simple implementation will load the CPU a little, then there is nothing to worry about. The main thing is that we can get a stable stream for mobile devices, TVs and other devices with Moonlight client.

Thanks.

UPD: Moonlight server - https://github.com/loki-47-6F-64/sunshine thanks Mirh for the info.
UPD2: Another moonlight server - https://open-stream.net/ & https://github.com/LS3solutions/openstream-server thanks Mirh for the info.

i'm investigating xyzz/vita-moonlight#66 issue.
(reporter uploaded debug log http://pastebin.com/6Den03pv)

actually log shown EAGAIN, but reporter said can work on ipad.
so i made simple tcp socket testing tool, and tested moonlight tcp connection steps.
but my result, vita socket looks working well. :(

so, my questions are 1. is exists any next check list? 2. can make newer modified GFE?