Differentiate between Media Renderers and Control Points

[SurfaceS]

From UPnP :
Control Point discover content (e.g. video, music, images, etc) on the MediaServer thru ContentDirectory service.
Each content item that is referenced by the ContentDirectory service includes various information about that content including the transfer protocol(s) and file format(s) that the MediaServer can use to transfer the content to the MediaRenderer.
After the desired content has been identified, the Control Point needs to determine which transfer protocol and data format should be used to transfer the content from the MediaServer to the MediaRenderer.

The actual transfer of the content is performed directly by the MediaServer and MediaRenderer.
The content transfer happens independently from the Control Point and does not involve UPnP itself at all.

In short :
Control Point discover content and give an URI to MediaRenderer.
MediaRenderer then ask for this URI to MediaServer.

Facts :
Most devices mix Control Point and MediaRenderer.
But sometime user have a device Control Point that send content to another device MediaRenderer.

Solution :
The URI from ContentDirectory should include everything the server will need to serve content back (without knowing the MediaRenderer).
That include the media asked, the user that created the link to check the right on media, the transcoder if any, all the transcoding settings if any.

Content item referenced by the ContentDirectory may (should) have multiple res with ideally :

• the original file format.
• if the Control Point is a MediaRenderer and it cannot play the original file format, the adapted file format.
• some common file format (eg for video : MPEG_TS_SD_(NA/EU/KO), MPEG_TS_HD_(NA/EU/KO), AVC_TS_MP_SD_AC3_T, AVC_TS_MP_HD_AC3_T)

[ik666]

Hi there,

I think this is the right idea. One addition to what is said, since we have at least two ecosystems:

• Video: Most devices with a user interface (like a television) implement the control point in the UPnP device. (2-box setup)
• Audio: Almost none of the audio renderer have a user interface. Therefore, vendors roll out an control point app for Android or iOS acting as an user interface (3-box setup).

The current solution UMS uses for doing the right transcoding by configuration is actually a pretty good idea. Otherwise, all control points must be as smart as UMS now is.

Another idea: The change wouldn't be that huge, if a control point get's always the raw resource (original file format). In a later step, when the MediaRenderer requests the resource from UMS (MediaServer), UMS decides how to serve the content by the configuration files. It's like picking automatically the right res, which is already being done by UMS.

The change would be to distinguish between MediaRenderer and control points. I'm not sure if we have direct access to the low-level UPnP process, but a control point send a CPUUID.UPNP.ORG property with it's own UUID in the unicast M-SEARCH telegram.

From UPnP Architectrure 2.0 docs:

CPUUID.UPNP.ORG
Allowed.uuid of the control point. When the control point is implemented in a UPnP device it is recommended
to use the UDN of the co-located UPnP device. When implemented, all specified requirements for uuid usage
in devices also apply for control points.See section 1.1.4. Note that when Device Protection is implemented
the CPUUID.UPNP.ORG shall be the same as the uuid used in Device Protection.

Another way to identify a control point is probably the abcense of any services on this device.

[SurfaceS]

About distinguish between MediaRenderer and control points.

we have direct access to the low-level UPnP process

Yes we can

CPUUID.UPNP.ORG

Most control point apps are not using this, and maybe some TV will. Hard do distinguish.

Another way to identify a control point is probably the absence of any services on this device.

Most control point apps are advising for other services. Or the apps is on a computer/device that will.

I think we should not care if the control point is the end-renderer or not.
Maybe just a renderer conf setting is better than everything.

The thing is that the user rights are done on the UUID, but it should be done on the control point, that may or not have an UUID, so we cannot rely on it. And IP address may change.

About the another idea :

Another idea: The change wouldn't be that huge, if a control point get's always the raw resource (original file format). In a later step, when the MediaRenderer requests the resource from UMS (MediaServer), UMS decides how to serve the content by the configuration files. It's like picking automatically the right res, which is already being done by UMS.

That what I propose, with an addition.
If we advertise only the raw format, some control point will not permit to send / show the media to the renderer as it is not readable.

• the original file format, with a DLNA.ORG_CI set as not converted (preferred format).
• if the Control Point is a MediaRenderer and it cannot play the original file format, the adapted file format (transcoded).
• some common file format transcoded if not the raw format (eg for video : MPEG_TS_SD_(NA/EU/KO), MPEG_TS_HD_(NA/EU/KO), AVC_TS_MP_SD_AC3_T, AVC_TS_MP_HD_AC3_T)

Then the control point (TV or not) will choose the right readable format for the renderer.

It may also be a good things for renderers that do not have any conf file, as it can take the raw format by itself.

[ik666]

CPUUID.UPNP.ORG

Most control point apps are not using this, and maybe some TV will. Hard do distinguish.

Are you sure? Maybe we can try to log some CPUUID (in debug mode) if available and share the results here. I can try a few control points that I use, just to see, what is send by the device. We can also check, if in a 2-box setup (television) a CPUUID is send by the internal CP of the TV, and if it differs from the UUID send by the embedded renderer device.

The thing is that the user rights are done on the UUID, but it should be done on the control point, that may or not have an UUID, so we cannot rely on it. And IP address may change.

I've tried another media server named serviio. It also implements "access rights", but by IP address. IMHO this solution looks more clean to the me as an end user: Let's say a control point has full access to the media files. In that case I can stream "protected content" to any device. But in reality I don't want the "protected content" to be streamed from the TV located in the kids room or from the PS5 or from some player located on the kids iPad.

At home I used static IP address for the devices I wanted to protect. I think giving DNS names like kids-iPhone@localdomain would also work, because most home router implement a DHCP server with dynamic DNS registration for a local domain.

IMHO, in any case, the "right renderer" has to be picked/identified by UMS (RequestHandlerV2) at the time the content get's requested by the media renderer. The only important thing is that the media renderer UUID or IP must be used for "protection check" and not the URL-supplied UUID from the control point.