RPiPlay
RPiPlay copied to clipboard
Casting videos doesn’t work
Youtube app / Website says that its mirroring, but there is nothing on the RPi screen.
Given your generally incomplete issue report, I'll assume you are using an iOS device. How did you connect to RPiPlay? Via the Screen Mirroring button in Control Center or via the Airplay button in the Youtube app / Website ?
Neither. It does not work from iOS Safari, iOS app, MacOS Safari with the Airplay button.
The only thing that worked is portray mode iOS Safari with Screen Mirror (Not full screen video)
Does it work from the iOS app or macOS Safari via Screen Mirroring? Just tested macOS Safari via Screen Mirroring, worked for me (Modification as per issue #6 needed).
MacOS Screen Mirroring doesnt work at all ( already opened a separate issue), with Extend Desktop it works in full screen and not full screen mode.
If you open the iOS app, and start a video while you are mirroring the screen it automatically tries to cast the video, which just hangs, the video doesn’t play and the mirroring continues, with the video not playing.
I already posted a potential fix for the macOS Screen Mirroring issue that I need you to confirm. The problem with Youtube is that it seems to only cast via AirPlay video (separate protocol different from AirPlay mirroring), which is not supported by RPiPlay.
AirPlay video (any video streaming that is not initiated via the dedicated AirPlay mirroring button in Control Center) uses a different protocol that has the iOS device relay the url and information of the (HLS) video it is currently playing to the AirPlay server. The server would then start streaming the video directly from the server (ie Youtube in this case), and the iOS device would act as a remote control for pausing, seeking and so on.
From the code base we have already, it shouldn't be too difficult to add the AirPlay video protocol, (the tricky parts are mostly the same as for AirPlay mirroring), it's rather a question of time. I personally don't need the feature, so I'm not going to invest the time to implement it. However, I'd gladly see someone else working on it! I'd readily help where I can and provide all information I already have about the protocol.
Until someone adds this protocol, you will have to resort to mirroring your screen while playing the video on your iOS device for the video to appear on RPiPlay. This doesn't work for the YT app, will not fill the TV screen and won't work 100% smooth though.
I'll leave this issue open for the case that someone wants to discuss how such a PR would work.
For anyone wanting to work on adding support for the AirPlay video protocol, VLC's implementation could be helpful: List of patches, Main patch, Short wiki
Hello again! Do you still not plan to add support for AirPlay video protocol? Maybe you know some alternatives?
Hi, First let me thank you for that tool it seems to be great like the one expected by rPlay but wasn't released yet. I have tried and build up the application on Buster version but on Raspberry 3B not 3B+ and I am using Mirroring from Control Center but nothing happen message "raop_ntp receive timeout" received within 5sec after connection but as seen in the debug there is info but with latency ~-5xxxx (which I believe is large value, right?). I have tried to change the resolution of the screen to different bigger ones as I set main to 800x400 for a 7inch screen in the car I have made the test with VNC connection on the RPI and using the iPhone as hot spot for the pi and mirroring using that connection. So, Is there anyway to get to work?
To add to everything other folks mentioned... I tried watching shows on the TV app of the new Apple TV+ service and it errored out as well.
@ThePyramid If the issue you see is unrelated to video playback, open a new issue. @rgelb I don't see how this adds anything. Video casting doesn't work, because the protocol is not implemented, so no surprise this also affects TV+.
Just asking is casting videos from quick time supposed to work ? because it doesn't in my case
Hey @FD-, I'm interested in tackling this issue.
I just need to understand: when we talk about HLS, we are talking about m3u8 streams, right? Are the streams URLs sent to the Airplay device? If they do, it means we can just implement an m3u8 handler that takes this URL as an input, right?
Hi @vinicyusmacedo, that'd be great! Yes, HLS is ts fragments in m3u8 playlists. AFAIK the iOS device sends the URL to the Airplay server. From there, we'd have to handle it and start playback, then also react to different control commands for play, pause, seek and so on. The rough concepts from https://nto.github.io/AirPlay.html#video should still be the same, though the protocol has evolved a bit.
@FD- great. Thanks for that. I know FFMpeg implements HLS streaming as well, maybe we can use it as the handler.
Is anyone actually going to do this? Has anyone already made a fork?
@FD- I found that instead of trying to implement AirPlay Video protocol, if you set the AirPlay feature bit field to exclude video support and HLS, it will play audio and video while mirroring rather than trying to switch to an AirPlay Video protocol making it possible to view videos from apps such as youtube. While it's not the best video experience, it is definitely usable.
@ysdoho Can you submit a Pull Request for that? Sounds like a great workaround for the time being.
@ysdoho will that allow apple tv+?
@FD- For sure!
@Suyashtnt I am not sure, I personally don't use apple tv+. I do know that Netflix doesn't work but Netflix killed Apple Airplay support awhile ago from what I remember
Apple TV+ does not work which really sucks. Audio goes through, but the image is frozen and my iPhone pauses it when I connect. Apple TV+ on my Mac also doesn't work. When I hit play on the show, the window for it stays black but auto still goes through. Cars 3 does work from my library, so I'd assume pirated content and bought content would work. Netflix flat out gives me an error. Disney+ says this:
YouTube works, and it's a little choppy. I'd also assume anything that's not DRM protected should work.
@bodenchristian If you're on a Mac, you should just try to use a different browser than Safari. I can't speak for disney+ but I know Netflix on Airplay with Chrome works. It's something to do with HDCP-compliance check on Safari which is not a thing with browsers like chrome or firefox
So if we knock out VideoHTTPLiveStreams from AIRPLAY_FEATURES, we're money? I'm not sure what the bit order is in this string.
I'm about to try 0x38e7, vs. 0x39f7, which I think disables HLS & rotation.
@pallas Not necessarily. Any iOS app that requires DRM protection via Airplay is still not working. When the server starts the airplay feature bit order is what tells the client what services the server offers. By disabling HLS and Airplay Video protocol, we are not letting the client choose AirPlay Video Protocol anymore. BTW HLS and Airplay Video protocol are very similar but they still need to be disabled, otherwise, it will try to switch to either of those protocols which are missing in this package.
Also, I believe you are getting those bit values by reading the unofficial AirPlay Protocol which is not very accurate. Originally, AirPlay v1 protocol accepted an 32-bit binary to define its features but now we have to use AirPlay v2 protocol which accepts a 64-bit binary to define its features. The new binary is defined by 32-bit lower bits, 32-bit higher bits. The higher 32-bit binary doesn't really matter too much as it is for a newer implementation of Airplay such as carplay and etc but I haven't checked if the lower 32-bits are the same as Airplay v1 vs Airplay v2
Yep, just realized I was using the wrong hex string. Can you send me the features string you're using? I'd like to test it on my setup.
Oh, I see it's in the latest commit! Thanks,
@pallas No worries! if you want to dig farther, I used https://emanuelecozzi.net/docs/airplay2/features and https://github.com/openairplay/airplay-spec
I finally got some time to take a look at it. Unfortunately, doesn't look so trivial. I don't see any of the http requests made here while testing Airplay on my Apple TV. Has it changed so much?
I can see a lot of RTSP, which is expected, TLS when I'm streaming content from QuickTime (this is cool, QuickTIme starts a server on port 7001 and the Apple TV makes a TLS handshake with it and streams content), PTP (I don't understand what is going on in there) and raw TCP (makes no sense as well, probably the payload is encrypted?).
Hey guys, maybe a good news that I found a repo can cast pic/video with AirPlay but mirror not working.
https://github.com/Titaye/AirplayServer-1