docs: add further docs (#338)

pages/guides/developing/player.en-US.mdx

@@ -175,23 +175,25 @@ The API will return a JSON payload which looks like:
 The format of this payload is [defined here](/reference/api/get-playback).
 The `url` field can be used as the playback URL.
 
-#### Short form playback URLs
+### Handling MP4 sources
 
-Short form playback URLs allow you to obtain alternative MP4 URLs for your video asset
-to enable mobile applications to cache short videos for instant playback of subsequent
+The playback info endpoint can return multiple sources in the response, as outlined above.
+These may include short form MP4 playback URLs, which allow you to obtain alternative
+URLs for your video asset to enable applications (and CDNs) to cache short videos for
+instant playback of subsequent
 videos. This means that viewers can experience instant time-to-first-frame (TTFF) when
 watching short videos.
 
 It is important to note that short form playback URLs are only available for
 video assets that are less than 2 minutes in duration. You can get the short
-form playback URLs by using the same endpoint format for the HLS playback URL, replacing
-PLAYBACK_ID with your asset's playbackId:
+form playback URLs by retrieving the playback info, replacing
+`PLAYBACK_ID` with your asset's playbackId:
 
 ```txt
 https://livepeer.studio/api/playback/{PLAYBACK_ID}
 ```
 
-The API will return a JSON payload which looks like:
+If there are MP4 renditions available, the API will return a JSON payload similar to:
 
 ```json
 {
@@ -226,13 +228,19 @@ The API will return a JSON payload which looks like:
 }
 ```
 
-<Callout type="warning">
+There are multiple renditions you can choose from, and it is up to you to decide how you want to prioritize
+each source for your custom player. See the [Player's technical
+details](/reference/livepeer-js/Player#technical-details) for more
+information on how livepeer.js handles this.
+
+<Callout>
   When you make a request for playback URLs, in the response MP4 URLs are always
   listed before HLS URLs. Additionally, each MP4 URL includes additional
   metadata about the video, such as its width, height, bitrate, and size. This
   metadata can be useful for mobile applications that want to optimize playback
   quality and size based on the viewer's device and network conditions. **The
-  Livepeer.js Player automatically handles this.**
+  Livepeer.js Player automatically handles this.** See the [Player
+  docs](/reference/livepeer-js/Player#technical-details) for more information.
 </Callout>
 
 ### Use the playback URL in a player

pages/reference/livepeer-js/Player.en-US.mdx

@@ -1037,3 +1037,24 @@ export const handleRequest = async (req, res) => {
   `);
 };
 ```
+
+## Technical Details
+
+The Player is opinionated about the ways it handles playback of media, specifically regarding HLS reconnect and playback URL choices.
+
+### HLS Reconnect
+
+The Player will perform a linear backoff strategy when it encounters any network/response errors. The reconnect will initially wait one second,
+and add one second every retry. This ensures that if there are any intermittent network/API errors, they are resolved as quickly as possible.
+Most open source players do not do this automatically, which results in a poor playback experience for the user.
+
+### MP4 Playback URLs
+
+When videos are uploaded which are shorter than two minutes, the Studio provider will automatically generate MP4 renditions alongside the
+usual HLS playback URL. This allows for rapid playback/caching at the CDN layer to enable your application to load video instantly.
+
+The MP4 renditions will be prioritized over HLS and are chosen with the following algorithm: the device screen width is multiplied by a
+static multiplier (currently set to `x2.5`). This value is then compared to the rendition widths, and the
+renditions are prioritized based on the distance between these values. This results in a choice of a rendition
+which is close to the screen size without visual quality issues. For instance, a device with a 1280 pixel width
+would compute `1280px * 2.5 = 3200px`, and then sort the MP4 renditions by which are closest to this value.