Spicy Sources
← All posts

A media link is not a stream.

Written by scovillo

From a shared link through NewPipe and FFmpeg to local HTTP streaming: how PlayOnDLNA gets media onto a DLNA player.

  • Android
  • DLNA
  • UPnP
  • FFmpeg
  • Debugging

Updated on by scovillo

When you open a YouTube or SoundCloud link on your phone, you see a website or an app. A DLNA player, on the other hand, needs a directly accessible media file in a format it understands. Bridging that gap is where PlayOnDLNA does its work.

The short version is this: the Android app resolves the shared link, selects suitable video, audio and subtitle tracks, prepares a compatible file and makes it available on the local network. It then tells the player where that file is and asks it to start playback.

Shared media link
        |
        v
NewPipe Extractor: metadata and direct stream URLs
        |
        v
Selection: video + audio + optional subtitles
        |
        v
HTTP Range downloads and preparation with FFmpeg
        |
        v
Completed MP4, M4A or MP3 file in the app cache
        |
        +------------------ local HTTP data -------------------+
        |                                                      |
        v                                                      v
PlayOnDLNA -- UPnP/AVTransport control --> DLNA player fetches file

The diagram shows two separate connections to the player. PlayOnDLNA controls playback through UPnP AVTransport. The player fetches the actual media from the Android device over HTTP. One connection working therefore tells you nothing certain about the other.

A shared link does not usually point straight to an MP4 file. Its destination may use scripts, multiple quality levels, separate video and audio tracks or adaptive streaming formats.

PlayOnDLNA uses NewPipe Extractor to identify the supported service and retrieve the available information. This includes the title, duration, thumbnails and direct URLs for video, audio and subtitles. NewPipe neither plays the media nor performs the actual download; it gives the app the information needed for the next stages.

This stage explains why a link can work in a browser but fail in PlayOnDLNA. Content may have been removed, restricted by region or made available only after signing in. Platforms also change their websites and interfaces regularly. When that happens, extraction often needs to be updated first.

2. Compatibility matters more than the largest number

The highest resolution on offer is not automatically the best choice for a TV or Kodi. A container such as MP4 also does not tell you which video or audio codec it contains.

PlayOnDLNA respects the selected maximum video quality and prefers a combination understood by many renderers:

  • MP4 video with H.264/AVC
  • M4A/MP4 audio with AAC
  • the original audio track where possible, otherwise one matching the device language
  • SRT subtitles in the device language, falling back to English

If no preferred variant is available, the app uses a suitable fallback. That improves the chance of playing the content at all, although unusual codecs can still expose the limitations of an older player.

3. Why video and audio are often downloaded separately

Many platforms provide high-quality video without an audio track. Audio and video then live at different URLs. Some modern renderers can process separate tracks themselves through adaptive formats such as HLS or DASH. This is not a capability PlayOnDLNA can rely on across arbitrary DLNA players, however, so the app prepares a single, broadly compatible media file instead.

PlayOnDLNA downloads progressive sources in several parallel ranges. It determines the file size, requests clearly bounded byte ranges with the HTTP Range header and joins the parts in their original order. This can speed up large downloads, but it relies on the source handling range requests correctly.

Depending on the delivery method, FFmpeg can also read an audio track directly from the remote source. The important part is the result: before the media is marked ready to play, a complete local output file exists.

4. FFmpeg builds a renderer-friendly file

FFmpeg combines the selected parts. This operation is called muxing: video, audio and, optionally, subtitles are written into one container without needlessly re-encoding compatible H.264 video.

A compatible AAC audio track is copied as well. PlayOnDLNA converts incompatible audio to AAC instead. SRT subtitles can optionally be embedded into the MP4 file as mov_text; the external SRT file may also remain available separately. The faststart option moves the MP4 metadata needed to begin playback to the start of the file.

Audio-only media is stored as MP3 or M4A. The completed media, its metadata, thumbnail and possible subtitles then become an entry in the local library. This means previously prepared media does not need to be processed again for the next playback. The library and its files live in the app cache and share its lifecycle.

5. How PlayOnDLNA discovers the player

Device discovery uses SSDP, the discovery protocol in UPnP. The app sends an M-SEARCH request to the multicast address 239.255.255.250:1900. Devices respond with the URL of their XML device description.

PlayOnDLNA reads the visible device name and advertised services from that description. The control URL for the AVTransport service is particularly important. Only a device that can be found on the local network and contacted through this service can be started and controlled by the app.

Guest networks, VLANs and Wi-Fi networks with client isolation often block multicast. In that situation, both the phone and player can have internet access while still being unable to discover each other.

6. The phone becomes a local media server

For playback, PlayOnDLNA starts a small HTTP server on a randomly selected port. Its address contains the Android device’s local IPv4 address, for example:

http://192.168.1.42:49152/media-id/video.mp4

The app creates DIDL-Lite metadata alongside that URL. It includes the title, duration, media class, MIME type and protocolInfo, among other values. These details help the renderer decide how to handle the resource.

The HTTP server supports complete responses (200 OK) and byte ranges (206 Partial Content). Headers such as Content-Length, Content-Range and Accept-Ranges let the player seek without fetching the whole file again. DLNA-specific content features and the transfer mode further identify the response as a stream on the local network.

PlayOnDLNA therefore acts as the media source for the player, but it does not publish an external cloud service. The file leaves the phone only over the local network.

7. Control and data transfer remain separate

To begin playback, PlayOnDLNA sends two SOAP requests to the player’s AVTransport control URL:

  1. SetAVTransportURI passes the local HTTP URL and DIDL-Lite metadata.
  2. Play asks the player to begin at normal speed.

The player then connects to the phone and fetches the file over HTTP. PlayOnDLNA does not push the video bytes to the TV inside the SOAP request. Further commands such as pause, stop, next or previous travel over the control path again.

This separation is the most useful key to troubleshooting:

Observation Likely stage
The link is not recognized Service detection or NewPipe extraction
Download or preparation fails Source server, range support, storage or FFmpeg
The player does not appear SSDP, multicast or network isolation
The player appears but does not start AVTransport, metadata or format support
The player reacts to Play but loads nothing Local IP address, port, firewall or HTTP reachability
Playback starts and stops reproducibly Range behaviour, codec support or a network change

Local does not automatically mean offline

The path from the Android device to the player stays local. When media comes from an online platform, PlayOnDLNA still needs an internet connection for extraction and download. There is no PlayOnDLNA cloud relay and no additional server to configure.

This also explains the intentional use of unencrypted HTTP on the LAN. Many DLNA renderers expect this transport and would not know how to handle a self-signed HTTPS certificate. The public media source remains separate; the local player receives only the address of the prepared media on the phone.

A bug report you can work with

App version:
Android version and phone:
Player manufacturer and model:
Media source and content type:
Selected quality and subtitle setting:
Network setup, guest network or VLAN:

Last successful stage:
1. Link recognized
2. Download completed
3. Preparation completed
4. Player discovered
5. Playback started

Expected behavior:
Actual behavior:
Reproducible: always / sometimes / once

Do not publish private media links or unchecked full logs. Remove sensitive information while keeping the technical details needed to understand the problem.

The PlayOnDLNA project page summarizes its features. Source code, current prerequisites and existing bug reports are in the repository. 🌶️