MRDLNA: DLNA casting from iOS in pure Objective-C

A casting library with no runtime dependencies to speak of

MRDLNA is a DLNA casting library for iOS, written in Objective-C, and the repository description calls it a pure Objective-C implementation of the iOS DLNA casting feature. The listed targets are the Chinese television brands that matter for the audience: Xiaomi, Huawei, LeTV, and the China Mobile set-top boxes, alongside the general claim of the major TV makers.

The overview in the readme is a single paragraph, and it describes the scope: media streaming from iOS devices to DLNA enabled devices such as smart televisions, set-top boxes, and media players. The features list below it is a checklist of what the library does.

Device discovery is automatic, finding the DLNA devices on the network. Media streaming covers video, audio, and images. Playback control covers play, pause, stop, seek, and volume. Multi-format support lists video in the MP4, AVI, and MKV containers, audio as MP3 and AAC, and images as JPG and PNG. There is custom metadata, so you can set a title and a creator for the item being played rather than letting the receiver show a file name. And the last two entries are the ones that describe engineering rather than features: thread safety, described as optimised for concurrent operations, and error handling with recovery.

The supported device list is broader than the marketing line suggests. Smart televisions from Samsung, LG, and Sony, set-top boxes, media players, and in principle anything that speaks DLNA or UPnP.

The licence is MIT, the last push was on 2026-08-17, and the current CocoaPods version is 0.3.0.

Discovery, the delegate, and the search window

The usage section starts with the import, and then shows a view controller that conforms to a delegate protocol and holds two properties, the manager and the array of devices it found.

#import <MRDLNA/MRDLNA.h>

The controller is initialised in a single line, because the manager is a shared instance.

self.dlnaManager = [MRDLNA sharedMRDLNAManager];
self.dlnaManager.delegate = self;
self.dlnaManager.searchTime = 10; // Search for 10 seconds

The search time is the discovery window, and the example sets it to ten seconds. The default, given in the configuration section, is five.

Then the search is started, and the results arrive at the delegate.

- (void)searchDLNAResult:(NSArray *)devicesArray {
    NSLog(@"Found %lu DLNA devices", (unsigned long)devicesArray.count);
    self.discoveredDevices = devicesArray;
    // Update your UI here | 在此更新UI
}

So the manager pushes the device list to the delegate rather than the delegate polling it, and the two callbacks in the example are the discovery result and a start-of-play notification, which is the point at which a UI would move from a spinner to a playback screen.

The delegate protocol is separate from the manager, so a screen can adopt it without knowing anything about the rest of the library, and the manager holds a weak reference to the delegate in the usual Cocoa fashion.

Streaming a URL, and the metadata path

Streaming is three steps: pick a device, set the URL, start.

CLUPnPDevice *selectedDevice = self.discoveredDevices.firstObject;
self.dlnaManager.device = selectedDevice;

NSString *mediaURL = @"http://example.com/video.mp4";
self.dlnaManager.playUrl = mediaURL;

[self.dlnaManager startDLNA];

The device type in that snippet is a UPnP device object rather than something the library defines, which tells you the library is working with a general UPnP device model underneath.

There is a second route, described as enhanced streaming with metadata, and it goes through a render object rather than through the play URL property.

[self.dlnaManager.render setAVTransportURL:mediaURL 
                                title:@"My Video Title" 
                              creator:@"Creator Name"];

That is the same call the AVTransport service would receive, and it is where the title and the creator go, which is what a television shows in its now playing screen.

The media type is detected from the URL extension, and the readme lists what that covers: video in the MP4, AVI, MKV, MOV, WMV, and FLV forms, audio in MP3, WAV, FLAC, AAC, and OGG, and images in JPG, JPEG, PNG, GIF, and BMP. Detection from the extension is a simple heuristic and it is worth knowing it is one, because a URL with a query string or an unusual extension may not be classified the way you expect.

Transport control, seeking, and volume

The playback controls are the part of a casting library that has to match the receiver, and the readme shows each command as a separate call on the manager.

- (IBAction)togglePlayPause:(id)sender {
    if (self.isPlaying) {
        [self.dlnaManager dlnaPause];
    } else {
        [self.dlnaManager dlnaPlay];
    }
    self.isPlaying = !self.isPlaying;
}

Volume is a number formatted into a string and passed to the manager, and the readme notes the range as zero to one hundred.

- (IBAction)volumeChanged:(UISlider *)sender {
    NSString *volume = [NSString stringWithFormat:@"%.0f", sender.value];
    [self.dlnaManager volumeChanged:volume];
}

Seeking is in seconds and is an integer, so the slider value is truncated rather than rounded.

- (IBAction)seekToPosition:(UISlider *)sender {
    NSInteger seconds = (NSInteger)sender.value;
    [self.dlnaManager seekChanged:seconds];
}

Stopping is a single call that ends the session, and there is a separate call for switching media without stopping first.

[self.dlnaManager endDLNA];
[self.dlnaManager playTheURL:nextVideoURL];

The interesting one is the alternate start method, which the readme describes as having error recovery, and the comment in the example says it stops the current session first. That is the difference between starting a session and restarting one, and the troubleshooting section points at it as the thing to try when a stream fails, which suggests the failure it is aimed at is a receiver left in a bad state by a previous attempt.

The network settings under the hood

The configuration section is short, and it is the part that tells you what the library is actually doing on the network.

The multicast address is the standard one for service discovery, 239.255.255.250, and the SSDP port is 1900. The HTTP timeout is ten seconds, and the search timeout is configurable, with a default of five seconds and the example raising it to fifteen.

self.dlnaManager.searchTime = 15; // Default is 5 seconds

That is SSDP, the discovery protocol that DLNA is built on, and it is worth understanding what it means in practice. Discovery is a multicast announcement on the local segment, so a device that does not appear is usually a device on a different network, or a device whose discovery is blocked, rather than a device that does not speak the protocol.

The HTTP timeout of ten seconds is the other number to know, because it is applied to the control requests that start and stop a session, and a receiver that is slow to answer will hit it.

The error handling in the library is the delegate callback for a failed search, with the error object giving the localized description, and the alternative start method as the recovery path. The combination of a multicast discovery with a configurable search window and a per-attempt HTTP timeout is the whole configuration surface, and it is small, which is what you want from a library that mostly has to work on the first try.

Installing it, the demo, and the troubleshooting list

Installation is through CocoaPods, with a pinned minor version range.

pod 'MRDLNA', '~> 0.3.0'

The manual route is the usual three steps: download the source, drag the folder for the library into the project, and add the frameworks it needs.

The requirements are iOS 12.0 or newer, Xcode 11.0 or newer, and the library can be used from Objective-C or from Swift.

There is a demo project, and the readme lists what it shows: a device discovery interface, the media streaming controls, the volume and seek controls, and examples of the error handling. To run it you change into the example directory, install the pods, and open the workspace.

cd Example
pod install
open MRDLNA.xcworkspace

The troubleshooting section is the most practically useful part of the document, and it is organised as three questions. The first is no devices found, with the answer that the devices have to be on the same WiFi network, that DLNA has to be enabled on the target device, and that the firewall settings have to be checked. The second is streaming failing, with the answer that the media URL has to be reachable, that the media format has to be compatible, and that the alternate start method is worth trying. The third is controls not working, with the answer that the device has to support transport controls, that the network connection has to be up, and that the streaming session has to be restarted.

Those answers are short because the failure modes of DLNA are short. It is a local network protocol with a well known discovery mechanism and a small control surface, and the library covers the surface. What it cannot cover is a television that does not implement the transport controls, and that is the first item in the third answer.

Editorial conclusion

MRDLNA fits an iOS application that plays video or audio on a television in the same room and needs the device discovery and the transport commands handled for it. It does not fit a project that needs to cast to a device outside the local network, because the discovery is multicast on the local segment, and it does not fit a codebase that wants a maintained, heavily used dependency, because the version history in the readme is a single entry. Verify first that the devices you target actually implement the transport controls you want, since the troubleshooting section lists that as the first cause of unresponsive buttons, and that the media URL is reachable from the television, which is a different network path from the phone.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. MQL9011/MRDLNA on GitHub
4. README