本文主要是介绍（两百七十一）学习DLNA，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
参考
https://spirespark.com/dlna/guidelines/
1.DLNA
DLNA（DIGITAL LIVING NETWORK ALLIANCE，数字生活网络联盟) 其前身是DHWG （Digital Home Working Group，数字家庭工作组），成立于2003年6月24 日， 是由索尼、英特尔、微软等发起成立的一个非营利性的、合作性质的商业组织。
DLNA旨在解决个人PC ，消费电器，移动设备在内的无线网络和有线网络的互联互通，使得数字媒体和内容服务的无限制的共享和增长成为可能。DLNA的口号是Enjoy your music, photos and videos, anywhere anytime。
DLNA并不是创造技术，而是形成一种解决的方案，一种大家可以遵守的规范。所以，其选择的各种技术和协议都是当前所应用很广泛的技术和协议。
DLNA将其整个应用规定成5个功能组件。从下到上依次为：网络互连，网络协议，媒体传输，设备的发现控制和管理，媒体格式。
2017年2月20日，DLNA在其官网宣布：本组织的使命已经完成，已于2017年1月5日正式解散，相关的认证将移交给SpireSpark公司，未来不会再更新DLNA标准 [1] 。
2.guidelines
DLNA Guidelines - June 2016
The Interoperability Guidelines consists of ten parts covering Architecture and Protocols, Media Formats, Link Protection, DRM Interoperability Systems, Device Profiles, HTML5 RUI, Authentication, Diagnostics, HTTP Adaptive Delivery, and Low Power Mode. It provides vendors with the information needed to build interoperable networked platforms and devices for the digital home. The necessary standards and technologies are available now to enable products to be built for networked entertainment centric usages. However, standards and technologies need to be clarified and options limited to ensure interoperability. The DLNA Home Networked Device Interoperability Guidelines fulfill that role.
说明了主要部分，下面是对每一个部分的详细说明
2.1 架构和协议
Part 1 - Architectures and Protocols
The Interoperability Guidelines are based on an architecture that defines interoperable components for devices and software infrastructure. It covers physical media, network transports, device discovery and control, media management and control, media formats, media transport protocols, and remote user interfaces. Table 1 shows a summary of the key functional components and technology ingredients that are covered by the Interoperability Guidelines.
| Functional Components | Technology Ingredients |
|---|---|
| Connectivity | Ethernet, 802.11 (including Wi-Fi Direct), MoCA, HD-PLC, HomePlug-AV, HPNA and Bluetooth |
| Networking | IPv4 and IPV6 Suite |
| Device Discovery and Control | UPnP* Device Architecture |
| Media Management and Control | UPnP AV, EnergyManagement, DeviceManagement, and Printer |
| Media Formats | Required and Optional Format Profiles |
| Media Transport | HTTP (Mandatory) , HTTP Adaptive Delivery (DASH) and RTP |
| Remote User Interfaces | CEA-2014-A , HTML5 |
| Device Profiles | CVP-NA-1, CVP-EU-1, CVP-2 |
说明了体系架构和协议，包括互联、网络、多媒体、远程UI和设备协议
Part 1-2 – Extended Digital Media Renderer
The DLNA Guidelines Parts 1–2 introduce a number of device classes to identify specific roles that connected endpoints implement in the network. Devices can act as content sources (e.g., Digital Media Servers, Push Controllers), and as content sinks (Digital Media Renderers or Digital Media Players).
Having two types of content sinks has been a useful strategy to accelerate the initial deployment phase. However, many of the modern receiver devices now include both types. Consequently, there is a need to define a receiver device that combines both types. This document addresses this issue and specifically, it describes a device class for an Extended Digital Media Renderer (XDMR).
PART 1-3 - CLOUD ACCESS
This document focuses on the discovery, association, and control of Apps capable of augmenting DLNA devices with the ability to consume content from sources outside of the home. The basic support is realized with the UPnP ApplicationManagement Service.
2 多媒体格式协议
This document describes DLNA Media Format profiles applicable to the DLNA Device Classes. Media Format profiles are defined for each of the following media classes: Audio, Image, and AV. In addition, Profile ID values that identify media collections were also introduced.
It is envisioned that in the home network environment, devices will be capable of exchanging content items that originate from different sources. Content items will typically come encoded in different formats. The term "format" designates the compression and encoding tools utilized to generate the binary instance of a content item, which will be eventually exchanged over the home network using streaming or file transfer protocols. Examples of formats include MPEG-2, MPEG-4, WMV and others for video; or MP3, AAC, WMA and others for audio.
Formats alone however, include as part of their specifications, multiple parameters, features and tools which can be used in a myriad of combinations to generate content binaries. In this document, the notion of a Format Profile is introduced to identify a particular suitable combination of format parameters which define a way for representing content binaries. A format like MPEG-2 for example, can have multiple profiles depending on selections for the companion audio, the system-layer multiplexing specifications, allowed frame resolutions, allowed aspect ratios, allowed bit rates, etc.
This document provides a list of Format Profiles for image, audio, and AV formats defined for use in DLNA devices. For each particular format profile, this document defines a Profile ID text token to be used during the DLNA media discovery and media transfer operations. The Profile ID is exposed in a server's Content Directory Service (CDS) to signal potential networked players or renderers the existence of a content item with particular coding and compression features defined precisely by the item's Profile ID. This document also describes the uses of Format Profiles which define media collections.
The number of potential combinations for suitable profiles becomes large rather quickly, as evidenced by the long profile lists observed in the different clauses and sub clauses of this document. Consequently, this document introduces the notion of mandatory profiles, supported by all devices, as a means to provide baseline content interoperability in the home. Servers will be capable of exposing and transferring mandatory profiles while players and renderers will be capable of decoding and rendering the mandatory profiles.
All profiles not defined as mandatory become optional in the home. An implementer can choose whether to support optional profiles. When supported and used with DLNA’s discover y and transfer methods, it will follow the guideline provisions for encoding and exposing optional profiles.
不大想看了，后面有需要的话再继续看。。。
这篇关于（两百七十一）学习DLNA的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
