mirror of
https://github.com/morgan9e/UxPlay
synced 2026-04-15 00:34:05 +09:00
edits to READE (remove RPiPlay changelogh)
This commit is contained in:
fduncanh
18
README.html
18
README.html
@@ -99,7 +99,7 @@
|
||||
<p>All the resources in this repository are written using only freely available information from the internet. The code and related resources are meant for educational purposes only. It is the responsibility of the user to make sure all local laws are adhered to.</p>
|
||||
<p>This project makes use of a third-party GPL library for handling FairPlay. The legal status of that library is unclear. Should you be a representative of Apple and have any objections against the legality of the library and its use in this project, please contact me and I’ll take the appropriate steps.</p>
|
||||
<p>Given the large number of third-party AirPlay receivers (mostly closed-source) available for purchase, it is my understanding that an open source implementation of the same functionality wouldn’t violate any of Apple’s rights either.</p>
|
||||
<h1 id="rpiplay-authors-notes-by-fdraschbacher-rpiplay-creator.">RPiPlay Authors (Notes by fdraschbacher, RPiPlay creator.)</h1>
|
||||
<h1 id="rpiplay-authors-notes-by-florian-draschbacher-rpiplay-creator.">RPiPlay Authors (Notes by Florian Draschbacher, RPiPlay creator.)</h1>
|
||||
<p>(From the https://github.com/FD-/RPiPlay.git repository.)</p>
|
||||
<p>The code in this repository accumulated from various sources over time. Here is my (<strong>fdrachbacher</strong>) attempt at listing the various authors and the components they created:</p>
|
||||
<ul>
|
||||
@@ -110,22 +110,6 @@
|
||||
<li><strong>Team XBMC</strong>: Managed to show a black background for OpenMAX video rendering. This code is used in the video renderer. License: GNU GPL</li>
|
||||
<li><strong>Alex Izvorski and contributors</strong>: Wrote <a href="https://github.com/aizvorski/h264bitstream">h264bitstream</a>, a library for manipulation h264 streams. Used for reducing delay in the Raspberry Pi video pipeline. Located in the <code>renderers/h264-bitstream</code> folder. License: GNU LGPLv2.1</li>
|
||||
</ul>
|
||||
<h1 id="rpiplay-changelog">RPiPlay Changelog</h1>
|
||||
<h3 id="version-1.2">Version 1.2</h3>
|
||||
<ul>
|
||||
<li>Blank screen after connection stopped</li>
|
||||
</ul>
|
||||
<h3 id="version-1.1">Version 1.1</h3>
|
||||
<ul>
|
||||
<li>Now audio and video work on Raspberry Pi Zero. I don’t know what exactly did the trick, but static compilation seems to have helped.</li>
|
||||
<li>Smoother video due to clock syncing</li>
|
||||
<li>Correct lip-sync due to clock syncing</li>
|
||||
<li>Lower latency due to injecting max_dec_frame_buffering into SPS NAL</li>
|
||||
<li>Disabled debug logging by default</li>
|
||||
<li>Added command line flag for debug logging</li>
|
||||
<li>Added command line flag for unsynchronized low-latency mode</li>
|
||||
<li>Bug fixes</li>
|
||||
</ul>
|
||||
<h1 id="airplay-protocol-versions">AirPlay protocol versions</h1>
|
||||
<p>For multiple reasons, it’s very difficult to clearly define the protocol names and versions of the components that make up the AirPlay streaming system. In fact, it seems like the AirPlay version number used for marketing differs from that used in the actual implementation. In order to tidy up this whole mess a bit, I did a little research that I’d like to summarize here:</p>
|
||||
<p>The very origin of the AirPlay protocol suite was launched as AirTunes sometime around 2004. It allowed to stream audio from iTunes to an AirPort Express station. Internally, the name of the protocol that was used was RAOP, or Remote Audio Output Protocol. It seems already back then, the protocol involved AES encryption. A public key was needed for encrypting the audio sent to an AirPort Express, and the private key was needed for receiving the protocol (ie used in the AirPort Express to decrypt the stream). Already in 2004, the public key was reverse-engineered, so that <a href="http://nanocr.eu/2004/08/11/reversing-airtunes/">third-party sender applications</a> were developed.</p>
|
||||
|
||||
20
README.md
20
README.md
@@ -435,7 +435,7 @@ This project makes use of a third-party GPL library for handling FairPlay. The l
|
||||
Given the large number of third-party AirPlay receivers (mostly closed-source) available for purchase, it is my understanding that an open source implementation of the same functionality wouldn't violate any of Apple's rights either.
|
||||
|
||||
|
||||
# RPiPlay Authors (Notes by fdraschbacher, RPiPlay creator.)
|
||||
# RPiPlay Authors (Notes by Florian Draschbacher, RPiPlay creator.)
|
||||
|
||||
(From the https://github.com/FD-/RPiPlay.git repository.)
|
||||
|
||||
@@ -449,24 +449,6 @@ is my (__fdrachbacher__) attempt at listing the various authors and the componen
|
||||
* **Team XBMC**: Managed to show a black background for OpenMAX video rendering. This code is used in the video renderer. License: GNU GPL
|
||||
* **Alex Izvorski and contributors**: Wrote [h264bitstream](https://github.com/aizvorski/h264bitstream), a library for manipulation h264 streams. Used for reducing delay in the Raspberry Pi video pipeline. Located in the `renderers/h264-bitstream` folder. License: GNU LGPLv2.1
|
||||
|
||||
# RPiPlay Changelog
|
||||
|
||||
### Version 1.2
|
||||
|
||||
* Blank screen after connection stopped
|
||||
|
||||
### Version 1.1
|
||||
|
||||
* Now audio and video work on Raspberry Pi Zero. I don't know what exactly did the trick, but static compilation seems to have helped.
|
||||
* Smoother video due to clock syncing
|
||||
* Correct lip-sync due to clock syncing
|
||||
* Lower latency due to injecting max_dec_frame_buffering into SPS NAL
|
||||
* Disabled debug logging by default
|
||||
* Added command line flag for debug logging
|
||||
* Added command line flag for unsynchronized low-latency mode
|
||||
* Bug fixes
|
||||
|
||||
|
||||
# AirPlay protocol versions
|
||||
|
||||
For multiple reasons, it's very difficult to clearly define the protocol names and versions of the components that make up the AirPlay streaming system. In fact, it seems like the AirPlay version number used for marketing differs from that used in the actual implementation. In order to tidy up this whole mess a bit, I did a little research that I'd like to summarize here:
|
||||
|
||||
24
README.txt
24
README.txt
@@ -533,8 +533,8 @@ closed-source) available for purchase, it is my understanding that an
|
||||
open source implementation of the same functionality wouldn't violate
|
||||
any of Apple's rights either.
|
||||
|
||||
RPiPlay Authors (Notes by fdraschbacher, RPiPlay creator.)
|
||||
==========================================================
|
||||
RPiPlay Authors (Notes by Florian Draschbacher, RPiPlay creator.)
|
||||
=================================================================
|
||||
|
||||
(From the https://github.com/FD-/RPiPlay.git repository.)
|
||||
|
||||
@@ -566,26 +566,6 @@ the components they created:
|
||||
the Raspberry Pi video pipeline. Located in the
|
||||
`renderers/h264-bitstream` folder. License: GNU LGPLv2.1
|
||||
|
||||
RPiPlay Changelog
|
||||
=================
|
||||
|
||||
### Version 1.2
|
||||
|
||||
- Blank screen after connection stopped
|
||||
|
||||
### Version 1.1
|
||||
|
||||
- Now audio and video work on Raspberry Pi Zero. I don't know what
|
||||
exactly did the trick, but static compilation seems to have helped.
|
||||
- Smoother video due to clock syncing
|
||||
- Correct lip-sync due to clock syncing
|
||||
- Lower latency due to injecting max\_dec\_frame\_buffering into SPS
|
||||
NAL
|
||||
- Disabled debug logging by default
|
||||
- Added command line flag for debug logging
|
||||
- Added command line flag for unsynchronized low-latency mode
|
||||
- Bug fixes
|
||||
|
||||
AirPlay protocol versions
|
||||
=========================
|
||||
|
||||
|
||||
Reference in New Issue
Block a user