-
Notifications
You must be signed in to change notification settings - Fork 414
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
miraclecast as source #4
Comments
If you have two laptops avaliable, sink can be too another miraclecast. Now with existing raspberry pi image #100 sink I can test it easily. Help wanted! |
When I follow your instructions above, I don't get any to my TV (tested with Samsung and LG). Connecting works fine, but usually after this, the source automatically starts sending the video-content to the TV. When I use the cvlc commend, nothing happenes. |
That description suppose that you control both sides (just to prove it can work) When using against a miracast device (as your tv) is needed to parse devices communication to see -at least- on which port your tv expect the stream. Run it with |
ok, I have a Samsung TV at the moment here and it's not possible to connect (maybe this is a new issue) wifid: miracle-wifid logs
and wifictl: miracle-wifictl logs
|
I tried with one of those Chinese receivers, but it doesnt maintain the connection until I send RTSP stream, even if I initialize it beforehand, I need the specific IP of the receiver to send my stream, so what it does is it successfully connects, then writes "Waiting for RTSP" at this moment it should start receiving, but meanwhile I need to get its IP address but apparently it doesnt wait too much and disconnects quickly.
|
I did a successful connection so that should be something related to devices configuration. |
Dear @albfan Log from Terminal#1
Log from Terminal#2
In another terminal I am trying to stream out my screen to the TV Streaming from Terminal#3 I keep below command ready, when I see the successful connection status in terminal#2, I just press return key here in terminal#3
I could learn protocol and port from my android phone through "Packet Capture" app. My android phone connects very well to the tv and renders the screen. Inference The desktop successfully connects to the TV but immediately disconnects.
Failure:
Later
Please kindly help. |
I dont think we can yet swnd an RTPS stream to the TV rn. I dont know if that's what's supposed to happen on normal conditions but for now this thread shows how to stream to a device but by using WiFi direct with a purpose of a local network instead of Display streaming. That's what explains the TV disconnectings also, it may be that the TV doesnt find any supported streaming capabilities in the connected device. |
@muqsith After succesfull connect there's no miracast protocol implemented. When you use miraclecast as sink (say from a phone) it starts a RTSP negotiation (one where port it is streaming, what features it implements...) and from miracle-wifictl that's not implemented. See last comments from @derekdai on https://gitter.im/albfan/miraclecast. Two get this implemented a first simple approach is to connect to miraclecast running on different devices (if you have a raspberry pi or two laptops should be easy) Controlling both sides is easy to fill whatever is left unimplemented on |
I can't connect with "unknown reason" message DEBUG: supplicant: terminating wpas (pid:25165) (supplicant_failed() in /home/mate/Downloads/miraclecast-master/src/wifi/wifid-supplicant.c:2330) DEBUG: supplicant: close supplicant of rename5 (supplicant_close() in /home/mate/Downloads/miraclecast-master/src/wifi/wifid-supplicant.c:2294) DEBUG: caught SIGCHLD for 25165, reaping child (manager_signal_fn() in /home/mate/Downloads/miraclecast-master/src/wifi/wifid.c:178) TRACE: wpa: raw message: <3>P2P-GO-NEG-SUCCESS role=GO freq=2437 ht40=0 peer_dev=92:d8:f3:bf:f5:89 peer_iface=92:d8:f3:bf:f5:89 wps_method=PBC DEBUG: supplicant: set STA-MAC for 92:d8:f3:bf:f5:89 from to 92:d8:f3:bf:f5:89 (via GO-NEG-SUCCESS) (supplicant_event_p2p_go_neg_success() in /home/mate/Downloads/miraclecast-master/src/wifi/wifid-supplicant.c:1195) TRACE: wpa: raw message: IFNAME=p2p-wlp2s0-0 <5>Failed to initialize driver interface DEBUG: supplicant: unhandled wpas-event: IFNAME=p2p-wlp2s0-0 <5>Failed to initialize driver interface (supplicant_event() in /home/mate/Downloads/miraclecast-master/src/wifi/wifid-supplicant.c:1483) TRACE: wpa: raw message: <3>P2P-GROUP-FORMATION-FAILURE DEBUG: supplicant: peer Mebox connection failed (supplicant_event_p2p_group_formation_failure() in /home/mate/Downloads/miraclecast-master/src/wifi/wifid-supplicant.c:1305) [FAIL] Peer: 92:d8:f3:bf:f5:89@3 Reason: unknown |
Here is another way to transmit your screen and audio from miracle-wifictl side to miracle-sinkctl side. After P2P groupt established (both peers have its own IP), runs gstplayer in sink side
And run gst-launch to send out screen and audio of your desktop
You have to replace the IP address, port and device name to make it work. If for some reason your gstreamer1.0-vaapi doesn't work, replace vaapiencode_h264 with x264enc. The device name of pulsesrc can check with command The time skew of pipeline above between peers is kind of high, can anyone help me reduce it? Thanks! |
complete migrate from cmake to meson some minor identation tweaks remove headers from source list replace add_global_arguments() with add_project_arguments() fix issues TingPing suggests # This is a combination of 5 commits. # This is the 1st commit message: mirage from cmake to meson # This is the commit message #2: complete migrate from cmake to meson # This is the commit message albfan#3: some minor identation tweaks # This is the commit message albfan#4: remove headers from source list # This is the commit message albfan#5: replace add_global_arguments() with add_project_arguments()
@derekdai I added your fork as a remote and start to review your changes. I think wip/source-impl is not valid anymore right? |
@albfan you are right. I moved files in |
Ok, I can deal with that changes from your repo. No problem |
Prevent issue duplication and manage user expectations by indicating up front that source is not yet implemented (see issue albfan#4).
Prevent issue duplication and manage user expectations by indicating up front that source is not yet implemented (see issue #4).
right now run as source work until the dhcp communication. So next step is to disable (maybe add a debug parameter) timeout on connect and open manually a miracle-dhcp server and client and use created interface to reach the connected signal. After that, same rstp as gnome-network-displays can be used to share screen |
Hi Albfan, I´m here again rsrs.. I´d like firt to thanks and glad you for making miraclecast work as WFD_Sink and mirroring WFD_Source as Windows 11 and many other new devices. Now I´m trying the inverse. We developed a Windows-App with works as WFD_Sink. Windows 11 already have it featore, but, our application will accept as Source Device ( Miracast and AirPlay) - Our AirPlay development was based on RPiPlay with the contribuitters mada successfull reverse engineering because it uses many proproetary plists, keys exchanging and sends video streammers encrypted. Well. I was trying to use miraclecast as WFD_Source. It can find our miracast WFD_Sink running and also Windows WFD_Sink running, but, when I tried to connect it looks like connecting, bot nothing happens on other side.[[ IMPORTANT:- I Didnt ran the long command you said for player. but, I Think RTSP exchannges should starts. Is it right? |
@OliveiraICTS by now the only option is to use the PR where there's a vala implementation. But I think it only will work on x11 server. |
Thanks!!! |
So if I read this correctly I cannot use this to connect my RPI4 to a wireless display. Correct? |
I got the following error after found peers and try to connect:
|
Our miracle-dhcp fails being GO and serving IPs. We need to force that or fix the miracle-dhcp implementation |
Albfran - I´m available to help you to fix it problem. Just let me know Okay? |
I thanks a test for miracle-dhcp should be enough. It is able to negotiate ips when is not GO but fails to do it when it is. I try to find any basic implementation to compare, but didn't find It. Force no GO is the easy fix (there's config on WiFi Direct for that) Find a dhcp implementation with test to verify miracle-dhcp is the hard/right way |
I´ll test and report it for you |
Any progress on the above? Or any better place to follow the progression? |
I also got the same fail [FAIL] Peer: xx:xx:xx:xx:xx:xx@3 Reason: group owner negotiation failed |
In My experience, normally the WFD Sink is set to be group owner, but, in some cases the WFD Source can be. The Group Owner act as DHCP Server sending an Ip Address to other side to connect on port RTSP(7236) used for control. rsrsrsr |
@OliveiraICTS did my message accidentally wake you up? 😂 |
I am still looking for a way to cast from Ubuntu and found this: Maybe something to look into? |
aethercast relays on networkmanager to create the wifi direct connection. Same as #114 covers. Until d-bus is implemented fix |
From #47 (comment)
Here is a Q&D (quick and dirty) for use laptop as source:
Start miracle-wifid as usual
Start miracle-wifictl
Now do something to make your device visible (like start screen mirroring)
Search on miracle-wifid output for a message like this
At this point you have your devices paired show they can see each other
Start a stream on laptop (using vlc for example)
On the other device use some viewer to reproduce that:( I've used vlc for android)
that stream can be viewed opening url: http://192.168.49.200:8554/myscreen
Develops needed:
The text was updated successfully, but these errors were encountered: