[fritsch]

I am not sure what apple would do with xbmc when they see that an application used by some million(!) people can do cracked airplay video and audio ...

[Memphiz]

Well alot of assumptions here. I just wanted to repeat it officially here. I am assuming that apple now enforces fairplay encryption. Since i have not updated to ios8 yet i didn't verify that assumption. But i plan to investigate of course (other projects first).

Also i already talked to the MythTV airplay dev and he somewhat confirmed my assumption. But as long as i formyself didn't investigate the network traffic i still handle it as an assumption (only trust yourself you know? ).

But i don't want to hold up the hopes too much - its likely that iOS7 was the last version which airplay video to xbmc.

[DBMandrake]

Apple doesn't license AirPlay to open source groups, because then anyone could see how to use AirPlay without paying for a license. So far Apple has only licensed audio AirPlay, but has not licensed the video parts of AirPlay to anyone.

Indeed.

It's very easy to hate on Apple for their failure to open up AirPlay, and from an end user and techy perspective it does frustrate me that they haven't done so, but let me offer some possible explanations from Apple's side of the fence.

1) Apple has traditionally always released new functionality in Mac OS and iOS using Private API's and only later converted them to public API's. Apple don't like to publicly release or document new API's until they're fully baked, because they don't want the burden of supporting immature API's or features years into the future. They'd rather wait until they think they've got it "right", then release it publicly.

I think they probably apply the same thinking to AirTunes and AirPlay video support at the network/protocol level. As you point out AirTunes has been licensed to hardware vendors (A/V receiver manufacturers etc) for a number of years now, although there is no official open documentation or official open source support, and it does rely on a not publicly disclosed (but now hacked and known) private key...

My feeling is that Apple don't yet think the Airplay video protocol has sufficiently matured, and therefore don't want the burden of supporting the network/protocol API with 3rd party vendors yet, hence Airplay video has not been licensed to anybody at all yet. As long as the Apple TV is the only device to act as an Airplay receiver Apple controls both the client and server end and are able push the Airplay protocol development forward rapidly (dropping support for older versions of the protocol along the way) until they're happy with it.

The fact that the protocol has changed so much with every major iOS release I think proves that it has not yet matured and stabilised. I believe that eventually Airplay video will be licensed to 3rd party hardware vendors once Apple feels like they can lock down the protocol - at that point they'll be stuck supporting that initial (3rd party capable) release far into the future - how many TV's or A/V receivers do you think will receive timely firmware updates to keep up with major iOS releases ? Not many I'd suspect. So Apple will have to have backward compatibility with that initial public version of the Airplay protocol for years and years even as they try to push the protocol forward...

It's very doubtful that Apple would sue people for cracking their encryption. Apple's smart enough to know when the genie is let out of the bottle, and they haven't sued anyone for AirPlay audio (AirTunes) being cracked a few years back. Nor have they sued anyone regarding AirPlay mirroring encryption being cracked (however, no open source AirPlay mirroring method currently exists).

2) DRM. Early versions of Airplay didn't require Encryption, but "rights holders" were unhappy about that. Apple provided "opt out" support in the iOS API's so that an app developer such as Netflix could set a flag to prevent their app being sent by Airplay at all. To this day there are still a few apps that simply don't allow Airplay use and it's always stupid rights related issues. Later on Apple added Encrypted Airplay support and now the API allowed apps to set a flag for "Encrypted Airplay only". A lot of apps that previously disallowed Airplay altogether now started to allow Encrypted Airplay.

You can tell which apps required Encrypted Airplay by connecting an HDMI-VGA adaptor to the output of an Apple TV and attempting to use it - many Apps will work, but as soon as you use an app that demands DRM support, (such as the Youtube app, regardless of whether the video you're playing is copyrighted) it will display a message saying HDCP support is not present...

You can blame Encryption requirements of Airplay (which look to be mandatory now on iOS 8) squarely on the video rights holders who more or less demand that Apple provide end to end DRM support, with Encrypted Airplay being part of that equation. If Apple don't provide it those vendors will simply stop their app from allowing Airplay at all.

For this reason I don't think you'll ever see an officially endorsed Unencrypted open source client or spec for Airplay - it would be like expecting Sony to make a Blu-Ray player that will play DRM'ed discs without requiring HDCP support over the HDMI connection - it's just not going to happen.

Technically it would be possible to allow an Unencrypted Airplay session for non-DRM content but I don't think it would make for a good user experience - as I discovered when trying a VGA adaptor on an Apple TV so many apps demand DRM protection that there's not a lot you can usefully do without it.

[DBMandrake]

I am not sure what apple would do with xbmc when they see that an application used by some million(!) people can do cracked airplay video and audio ...

I don't quite understand how the likes of Reflector get away with selling a commercial application that includes cracked Airplay mirroring support and yet don't get sued by Apple...(yes, Reflector still works fine in iOS 8)

Surely a commercial entity profiting from selling software based on reverse engineering Apple's protocol is a bigger target to sue than the public release and use of code/keys in software like XBMC that is provided free of charge ?

I have to wonder whether there is a gentleman's agreement between Apple and Reflector/Air Server etc not to sue them as long as they don't release the code or keys publicly...

[DBMandrake]

Moved from the iOS 7 thread....

The last statment of mine doesn't change until ios8 is released and jailbroken (because i will not install ios8 on my dev device before i would be able to also debug XBMC on it - which needs the jailbreak as you know).

Beside that - the first frame thingy from camera role is normal behaviour (the first "thumbnail" is transfered as picture - which means pictures will continue to work on iOS8 ...)

Just stumbled onto something that may show a glimmer of hope...

iOS 8.0 running on my iPad 3 - like most other people XBMC (13.2) seems to show up only as an audio device now. Speculation has been cast about that iOS 8 no longer supports unencrypted Airplay video - this would appear to be untrue!

Today I've been testing Reflector 1.4.0 (which does work with iOS 8 and also supports mirroring) on my Windows 7 PC at work to see whether I could get them working together - eg Reflector takes over the full screen during airplay then goes into the background revealing XBMC when not in use...

During my testing I forgot to disable Airplay within XBMC. I also set a passcode of 12345 for Airplay within Reflector to prevent other people at work accidentally connecting while testing.. (yes it happens...)

I then connected to my PC using Airplay from the iPad - deliberately left the mirroring option off (even though it is visible to be selected as it normally is with Reflector) and imagine my surprise when the video appeared not using Reflector, but within XBMC!

Youtube doesn't work of course, but I've tested it with video from the built in photos app and Instacast and both worked perfectly as they did pre-iOS8.

So does this mean it is an announcement problem, not an encryption problem ? Somehow Reflector is making the right announcements to make the iPad happy but it is connecting to XBMC instead of Reflector when they are both running on the same PC.

This puzzles me a little bit because I thought the Airplay announcements also advertise the port numbers that the Airplay receiver is listening for connections on ? Also why was it asking me to enter the pin when reflector was configured to require a pin but XBMC wasn't, yet the video then played through XBMC ?

One other thing I noticed - if I run XBMC only I see an audio only airplay device called XBMC (PCNAME) if I run Reflector only it is simply called PCNAME but always shows as a video device, and when both applications are running it is named XBMC (PCNAME) but always shows as a Video device. So some announcement that Reflector is sending is causing it to reliably show as a (mirroring capable) video device but it is NOT overriding the name that XBMC is advertising...

Not sure how to extract any more information out of my test setup but at least it does seem to show that XBMC can still receive unencrypted streamed video from an iOS device, it's possibly just an issue with the advertisements or initial handshake. (Perhaps Reflector is performing the initial handshake but the video stream is somehow being sent to XBMC)

[Memphiz]

Please post debug log (wiki) once with reflector enabled (working) and without (non-working).

[DBMandrake]

Here is a log of Airplay video from Instacast working with Reflector loaded in the background:

http://xbmclogs.com/show.php?id=301077

After waiting a while with only XBMC running the icon does eventually change from audio to video (took about a minute) but when attempting to airplay video to XBMC it only sends audio. Here is the log file from that session:

http://xbmclogs.com/show.php?id=301080

Even after playing audio only the Airplay icon still shows ticked as a video source.

When reflector is running the video mirroring toggle also appears but I am deliberately leaving it unselected.

[DBMandrake]

Not sure if it's helpful but here are the bonjour announcements coming from both Reflector and XBMC simultaneously:

Code:

Browsing for _airplay._tcp.
Timestamp     A/R Flags if Domain                    Service Type              Instance Name
13:12:44.449  Add     3 11 local.                    _airplay._tcp.            XBMC (ITSUPPORT)
13:12:44.449  Add     310000001 local.                    _airplay._tcp.            XBMC (ITSUPPORT)
13:12:44.449  Add     3 11 local.                    _airplay._tcp.            ITSUPPORT
13:12:44.449  Add     210000001 local.                    _airplay._tcp.            ITSUPPORT

Code:

Lookup ITSUPPORT._airplay._tcp..local
13:20:51.299  ITSUPPORT._airplay._tcp.local. can be reached at ITSUPPORT.local.:7000 (interface 11) Flags: 1
deviceid=74D4355700E5 features=0x100029FF model=AppleTV3,1 pw=1 rmodel=PC1,1 srcvers=150.33
13:20:51.299  ITSUPPORT._airplay._tcp.local. can be reached at ITSUPPORT.local.:7000 (interface 10000001)
deviceid=74D4355700E5 features=0x100029FF model=AppleTV3,1 pw=1 rmodel=PC1,1 srcvers=150.33

Code:

Lookup XBMC (ITSUPPORT)._airplay._tcp..local
13:21:15.065  XBMC\032(ITSUPPORT)._airplay._tcp.local. can be reached at ITSUPPORT.local.:36667 (interface 11) Flags: 1
deviceid=74:D4:35:57:00:E5 features=0x77 model=Xbmc,1 srcvers=101.28 xbmcdummy=evendummy
13:21:15.065  XBMC\032(ITSUPPORT)._airplay._tcp.local. can be reached at ITSUPPORT.local.:36667 (interface 10000001)
deviceid=74:D4:35:57:00:E5 features=0x77 model=Xbmc,1 srcvers=101.28 xbmcdummy=evendummy

Code:

Browsing for _raop._tcp.
Timestamp     A/R Flags if Domain                    Service Type              Instance Name
13:23:34.447  Add     3 11 local.                    _raop._tcp.               74D4355700E5@XBMC (ITSUPPORT)
13:23:34.447  Add     310000001 local.                    _raop._tcp.               74D4355700E5@XBMC (ITSUPPORT)
13:23:34.447  Add     3 11 local.                    _raop._tcp.               74D4355700E5@ITSUPPORT
13:23:34.447  Add     210000001 local.                    _raop._tcp.               74D4355700E5@ITSUPPORT

Code:

Lookup 74D4355700E5@ITSUPPORT._raop._tcp..local
13:25:32.741  74D4355700E5@ITSUPPORT._raop._tcp.local. can be reached at ITSUPPORT.local.:47000 (interface 11) Flags: 1
txtvers=1 ch=2 cn=0,1,2,3 da=true et=0,3,5 md=0,1,2 pw=true sv=false sr=44100 ss=16 tp=UDP vs=150.33 vn=65537 am=AppleTV3,1 sf=0x4 rmodel=PC1,1
13:25:32.741  74D4355700E5@ITSUPPORT._raop._tcp.local. can be reached at ITSUPPORT.local.:47000 (interface 10000001)
txtvers=1 ch=2 cn=0,1,2,3 da=true et=0,3,5 md=0,1,2 pw=true sv=false sr=44100 ss=16 tp=UDP vs=150.33 vn=65537 am=AppleTV3,1 sf=0x4 rmodel=PC1,1

Code:

Lookup 74D4355700E5@XBMC (ITSUPPORT)._raop._tcp..local
13:25:24.442  74D4355700E5@XBMC\032(ITSUPPORT)._raop._tcp.local. can be reached at ITSUPPORT.local.:36666 (interface 11) Flags: 1
txtvers=1 cn=0,1 ch=2 ek=1 et=0,1 sv=false tp=UDP sm=false ss=16 sr=44100 pw=false vn=3 da=true vs=130.14 md=0,1,2 am=Xbmc,1
13:25:24.442  74D4355700E5@XBMC\032(ITSUPPORT)._raop._tcp.local. can be reached at ITSUPPORT.local.:36666 (interface 10000001)
txtvers=1 cn=0,1 ch=2 ek=1 et=0,1 sv=false tp=UDP sm=false ss=16 sr=44100 pw=false vn=3 da=true vs=130.14 md=0,1,2 am=Xbmc,1

[Memphiz]

I see. Well the iOS device normally "probes" any video airplay by initiating an audio only/airtunes connection first and switching to video airplay (meaning sending the video url) afterwards. In your working example this probing is not visible. Maybe its probing to reflector instead or its something with the announced protocol versions.

If its really only about the annonucement you can announce the 1:1 reflector settings via "dns-sd.exe" without letting reflector run in the background.

Fact is that the ios device somehow mixes the announcements (which are sent out with the same mac address) and it might be random which airtunes announcement it mixes whith which airplay annonucement ...

[DBMandrake]

Thanks - makes sense. The iOS device is definitely mixing up the two sets of announcements in some way because the name of the Airplay device is coming from the XBMC announcement (although perhaps only because it is periodically updated thanks to the iOS 7 workaround) yet the mirroring toggle option is coming from the Reflector announcement..

It's almost as if the iOS client is not programmed to understand the concept of two Airplay services running on the same device with the same MAC/IP address, even though the announcements do publish different listening ports.

I'll see if I can use dns-sd.exe to send reflectors announcements and see what happens. I'll try both airplay and airtunes announcements and also airplay on its own. Any advice on how to do this ?

[DBMandrake]

Ok I tried the following to announce only the airplay (not airtunes) part of reflectors announcement:

Code:

dns-sd -R ITSUPPORT _airplay._tcp local 7000 deviceid=74D4355700E5 features=0x100029FF model=AppleTV3,1 pw=1 rmodel=PC1,1 srcvers=150.33

Registering Service ITSUPPORT._airplay._tcp.local port 7000 TXT deviceid=74D4355700E5 features=0x100029FF model=AppleTV3,1 pw=1 rmodel=PC1,1 srcvers=150.3314:30:38.167  Got a reply for service ITSUPPORT._airplay._tcp.local.: Name now registered and active

It worked! Reflector was definitely not running in the background.

Here is the debug log of this session:

http://xbmclogs.com/show.php?id=301165

Obviously this is a massive kluge but it may be useful as a starting point to understand exactly what the client is looking for...

[DBMandrake]

Is there some way to disable XBMC's internally generated bonjour Airplay announcements whilst still leaving the Airplay service enabled, so that custom external annoucements can be sent with dns-sd for testing without clashing with the built in ones ? (In particular with the iOS 7 periodic update hack)

I'm seeing some unusual behaviour that looks like a tug of war between the two competing announcements (the name sometimes changes back and forth etc) so I'd like to try some fully custom announcements on their own without the built in ones interfering and confusing the issue.

Specifying the same port number as the real service (36667 instead of 7000) works a bit better:

Code:

dns-sd -R ITSUPPORT _airplay._tcp local 36667 deviceid=74D4355700E5 features=0x100029FF model=AppleTV3,1 pw=0 rmodel=PC1,1 srcvers=150.33

In this case when the name randomly flips over for a short time although the mirroring switch disappears airplay video continues to work, whereas with the wrong port number specified it would fail to connect when the name flipped over to just ITSUPPORT instead of XBMC (ITSUPPORT).

Setting the name exactly the same as XBMC's announcement doesn't seem to work at all however.

Edit: anyone else running windows who wants to try the above - open a command prompt window to run it in, change the name ITSUPPORT to a name that is similar to but different to the name that XBMC normally appears as on your iOS device, and change deviceid to the MAC address of your PC. I'd be interested to see if this works for anyone else on iOS 8.

When trying it make sure you don't turn on the screen mirroring toggle even though it will be available as screen mirroring is not supported.

[wgstarks]

Hope ya'll don't mind a quick question. I've seen a few references to audio Airplay working with XBMC but not video. How do I get the audio to work? My iPhone no longer shows my HTPC at all.

[DBMandrake]

Is there some way to disable XBMC's internally generated bonjour Airplay announcements whilst still leaving the Airplay service enabled, so that custom external annoucements can be sent with dns-sd for testing without clashing with the built in ones ? (In particular with the iOS 7 periodic update hack)

I'm seeing some unusual behaviour that looks like a tug of war between the two competing announcements (the name sometimes changes back and forth etc) so I'd like to try some fully custom announcements on their own without the built in ones interfering and confusing the issue.

Specifying the same port number as the real service (36667 instead of 7000) works a bit better:

Code:

dns-sd -R ITSUPPORT _airplay._tcp local 36667 deviceid=74D4355700E5 features=0x100029FF model=AppleTV3,1 pw=0 rmodel=PC1,1 srcvers=150.33

Just tried a variation of the above line (appropriate host name and MAC address) on my Mac Mini at home and it worked straight away on Mac OS too.

Before hand the Mac was displayed as an audio only device for 10 seconds then displayed as a video device (as before with iOS 7) however attempts to Airplay video would only send Audio.

After running the above it was immediately seen as a video device and in fact the 10 second period after turning on wifi of being detected as only an audio device is eliminated as well - it shows up immediately and always as a video device.

There is still a minor conflict between the two sets of announcements though that causes the occasional attempt to connect to fail while the name is changing from one to the other. (But it then works when retrying the connection)

Memphiz: Is it possible to get a build of XBMC to test with the built in Airplay announcements disabled so I can do further investigation and testing ? Or if you can tell me a simple code change to apply I am able to compile Gotham for both Mac and Windows. (I don't think I have suitable build environments for Helix though)

[edrikk]

I would argue that Memphiz' code changes to pull the flags from the XML file (which he used back in the iOS 7 issues with AirPlay days) should be a part of XBMC.. At least as override values...
Just MHO...

Before anyone asks: That build is long gone / doesn't exist any more... That code (to allow for setting the flags via XML file) is NOT in current XBMC.