Tayeb Lemlouma
IRISA Lab and University of Rennes I, Lannion, France
Content Accessibility, Content Adaptation, Web Pagination, Media Segmentation, Digital Home, DLNA,
Device Independence.
In this paper we address the accessibility to advanced networking functionalities and media rendering using a
new framework. The objective of proposing this new framework is to make advanced services accessible for
heterogeneous and limited devices. The context of this work concerns digital homes where several multimedia
services exist and their use requires complex configurations and the ability to handle advanced networking op-
erations. This required ability is not satisfied for handheld devices that are heterogeneous in terms of software
and hardware capabilities. Indeed, even advanced mobile terminals do not support, at least natively, network-
ing operations such as the multicast, services discovery and multimedia streaming with different protocols. In
order to improve the user’s experience in such environments, we focus on the Web accessibility and the adop-
tion of the HTTP protocol that are nowadays supported by the majority of heterogeneous terminals such as
mobile phones, TVs and game boxes. In order to demonstrate the feasibility and the validity of our framework
we consider, as a digital home architecture, the Digital Living Network Alliance (DLNA) environment. We
show that even if the existing architecture and multimedia/networking services are complexes, the proposed
framework simplifies the architecture for the user and guarantees the delivery of an accessible and adapted
With the increasing popularity and the emergence of
smart powerful mobile devices, users become more
demanding in terms of quality of experience. As mo-
bile devices become widely used in a similar way
like with desktop terminals, users require similar ac-
cessibility regarding network’s content and services.
Unfortunately, even with the clear and huge advance
of mobile devices capabilities, many services still in-
accessible natively. Without further extensions and
advanced configurations, many services, content for-
mats and delivery methods remain rich, complex and
not adapted to ”limited” environments compared to
desktop platforms. In order to handle the hetero-
geneity of environments and terminals and provide
a universal accessibility, it is necessary to determine
a minimal set of compatible and standard function-
alities that can be used in advanced and limited en-
vironments. In the context of content access, the
HTTP protocol represents the most common and sim-
ple method used for delivering data. HTTP can be
easily implemented in limited environments and can
deliver data from simple Web pages to media con-
tent. Our framework is based on this observation. It
aims to improve the user’s experience regarding the
use and the access of complex multimedia services.
The objective is to enable the use of complex services
and content, using limitted terminals, in a universal
way. For limited devices, digital homes represent a
challenging context because several multimedia ser-
vices are availables but their use requires complex
configurations and the ability to handle advanced net-
working operations. This required ability is not sat-
isfied for handheld devices that are heterogeneous in
terms of software and hardware capabilities. Indeed,
even advanced mobile terminals do not support, at
least natively, networking operations such as the mul-
ticast, services discovery and multimedia streaming
with different protocols. We believe that the adop-
tion of the HTTP protocol coupled with the respect
of Web accessibility guidelines improve the quality
of experience of users regarding the access and use
of multimedia and networking services even in com-
plex architectures. We consider any network service
as the union of the following three sets: (1) input argu-
ments, (2) advanced operations and (3) output results.
Consequently, enabling a service in a limited environ-
Lemlouma T..
DOI: 10.5220/0003943904440451
In Proceedings of the 8th International Conference on Web Information Systems and Technologies (WEBIST-2012), pages 444-451
ISBN: 978-989-8565-08-2
2012 SCITEPRESS (Science and Technology Publications, Lda.)
ment becomes equivalent to perform the following:
(1) delegate the execution of incompatible operations
to an intelligent component, and (2) provide a stan-
dard and compatible interface that allows the user to
interact with services and rich content and receives an
adapted form of the service’s output. The application
of this approach will be validated in the Digital Liv-
ing Network Alliance (DLNA) environment (DLNA,
2007). DLNA represents an ideal context that rep-
resents heterogeneity regarding the content, servers,
services and terminals that can aim to access the home
network services and content. The framework of Uni-
versally, that we present in this paper, is discussed
regarding the provided Web interface and its compli-
ance with the W3C recommendations and the content
fragmentation (Web pagination and media segmenta-
The objective of DLNA technology is to distribute
digital content from a source to all the compatible de-
vices (DLNA, 2007; DLNA, 2006). The key func-
tions of DLNA are: connectivity and networking, de-
vice discovery and control, media management, me-
dia formats and media transport (Fig. 1). Connectiv-
ity and networking use the existing network platform
at home. Device discovery and control is based on the
UPnP Device Architecture (DA) 1.0 (UPNP FORUM,
2008b). Media management is based on the UPnP
AV (UPNP FORUM, 2008a). Media formats are de-
fined as a set of required and optional format profiles.
The media transport in DLNA is done overHTTP. The
RTP protocol is introduced recently and still optional
(DLNA, 2007; DLNA, 2006).
Three entities are specified: devices, services and
control points (CPs). Services are functions provided
by a device, found and invoked by a CP. The main
functions of a UPnP device are: IP addressing, dis-
covery (periodic advertisement of services), descrip-
tion of services and capabilities, control in response
of CPs requests, eventing to notify registered CPs
and presentation in HTML to possibly monitor the
device. This depends on the specific capabilities of
the presentation page and device and if the device
has a presentation’s URL. SSDP messages are sent
over HTTPMU (HTTP Multicast over UDP) in order
to discover resources in the network (UPNP FORUM,
2008b). SOAP allows to specify available operations.
In the audio video (AV) digital home, the three main
entities are: the media server (MS) that offers me-
dia content, the media renderer that plays content and
CPs that control what and how contents are played.
Figure 1: DLNA framework.
MS provides three services: Content Directory Ser-
vice (CDS), Connection Manager Service (CMS) and
AV Transport Service (AVT) (Fig. 1). A media ren-
derer provides the Rendering Control Service (RCS),
the CMS and AVT services. CDS provides actions
for CPs in order to list media items and relative meta-
data. RCS provides actions for a CP to control the
rendering of a media resource. CMS handles con-
nections with a device and AVT controls the player
actions (play, seek, etc.). DLNA defines two main en-
tities: Digital Media Server (DMS) and Digital Media
Player (DMP). DMS is a UPnP/AV CDS device that
provides media resources. DMP is a UPnP/AV CDS
control point that can discover resources and render
In a DLNA/UPnP environment, the number, na-
ture (UDP and multicast) and the periodicity of UPnP
advertisements can be inconvenient. Also, in order to
render a media resource, several messages and steps
must be achieved. A mobile device, used in the dig-
ital home, has to support the multicast, UPnP Tem-
plate Langugae parsing, SOAP protocol and the un-
reliable nature of UDP especially over a wireless ac-
cess. Moreover, there is no guarantee that the origi-
nal format and profile of the requested media resource
will be supported. This situation is not adapted to het-
erogeneous environments where rendering capabili-
ties, delivery and access technology, bandwidth, con-
gestion probability and power consumption are not
the same for all the existing devices.
The aim of our proposition is to enable and optimize
the access and control of existing media resources
in home for heterogeneous and mobile devices with
limited access and rendering capabilities. To do so,
we propose Universally: a new component that can
be easily integrated into the digital home architec-
ture and provide a universal access in a heterogeneous
environment. The modular architecture of Univer-
Figure 2: The Universally architecture.
sally is presented in Fig. 2. The key idea is to pro-
vide an easy media access only when it is needed
by a user and requested by its device. Based on an
Advanced Web Interface (AWI) module, devices can
browse available DMSs and resources since it is done
over HTTP. Once a media resource is found and dis-
played on the AWI with a hyperlink, the user can use
it directly, or use an adapted version delivered in a real
time. Universally delegates the UPnP main functions
(discovery, control, etc.) to a specific module that
ensures the access for limited devices such as those
which do not support the multicast natively or are not
compatible with DLNA. Since devices with advances
capabilities can also use the proposed AWI, UPnP ad-
vertisements of media services are filtered and only
responses to the Universallys M-SEARCH requests
are authorized. Unnecessary traffic is so avoided. The
context module is used to describe the hardware and
software capabilities of devices that aims to play a
media resource (Lemlouma, 2012). If the original for-
mat of a media is not supported, it can be adapted then
transferred to the device. Based on the device’s pro-
file, the Web interface is also dynamically adapted by
performing a pagination of discovery results when the
device explores media resources of available DMSs.
Searching MSs are done only once when the user ac-
cesses the AWI interface. The AWI’s home page is
a simple page with an HTML refresh duration, after
what the user is redirected to a new page where the
result of services discovery is displayed. At any mo-
ment, the user can manually trigger a new services
discovery. Universally has allowed to: avoid unnec-
essary traffic (NOTIFY and M-SEARCH), unify the
eventual available presentations of MSs and devices,
make the browsing of resources possible and optimal
and avoid SOAP and XML UPnP handling and pars-
ing for limited heterogeneous devices.
The W3C Web Content Accessibility Guidelines
(WCAG) 2.0 (W3C-WCAG, 2008) propose recom-
mendations for making Web content more accessi-
ble for users. The W3C Mobile Web Best Practices
(MWBP) recommendation 1.0 (W3C-BP, 2008) ad-
dresses a series of recommendations designed to im-
prove the user experience of the Web with mobile de-
vices. The proposed recommendations refer to deliv-
ered content but are not intended to be the best prac-
tice for the processes of content creation and render-
ing on devices. The result of performing networks
operations must lead to Web interfaces designed in a
compliant way to the two previous W3C standards.
As we focus on the accessibility of limitted devices,
we consider, in the design of our gerented interfaces,
the recomandations of the MWBP standard. We have
evaluated the Advanced Web Interface according to
the sixty statements of MWBP 1.0.
Table 1 summarizes the support of MWBP 1.0 by
the advanced Web interface of Universally. The large
compliance, regarding the MWBP statements, is due
to the structure simplicity of our Web interface that
hides the support of advanced networking functional-
ities. Some statements such as the user input are not
applicable since the user’s interaction is mainly based
on exploring existing media servers and items.
An important number of statements are ensured
thanks to: the use of content pagination with small
size, navigation hyperlinks used in content explo-
ration and pages navigation, the use of the same and
simple template for different pages, the simple and
short URI that identifies the hosting server of Univer-
sally. Page refreshing, used while a network oper-
ation (media servers searching) is triggered, is com-
pliant with the statement #14 of the MWBP 1.0. At
anytime, the user can stop it using the stop hyperlink
(Fig. 3).
Table 1: The support of MWBP 1.0 by the Advanced Web Interface of Universally.
Best Practice # of MWBP 1.0 # of N/A # of Supported
Group of MWBP 1.0 Statements Statements Statements
Overall Behavior 4 0 4
Navigation and Links 12 4 8
Page Layout and Content 12 2 10s
Page Definition 25 4 21
User Input 7 6 1
Figure 3: The advanced Web interface of Universally.
According to the statement #21 of the MWBP 1.0,
a delivered page must be limited in size. In our ap-
proach, we propose to make a balance between the
scrolling and pagination of the result presented in the
Web interface. Scrolling long pages can affect the
user experience and requires a long time load. On
the other hand, an important pagination implies mul-
tiple requests to receive the relevant result. In order
to optimize our process, we consider three input pa-
rameters: the screen size of the user’s device, the size
of delivered page and the network access technology
used by the device. We distinguish four types of dis-
played pages: searching progression, negative result,
media servers list and items list (Fig. 3). The two first
pages are displayed in the case where Universally is
looking for media servers or when no media servers
are found. The size of these two pages is small (1,6
Kb) which is compliant with the MWBP recommen-
dation. The servers list page includes hyperlinks to
different found media servers. The items list page in-
cludes links to folders and media resources items that
a media server hosts. The following is an example of
links extracted from our experimentations.
a accesskey=”3” href=”/ms?serv=3&id=0&inf
Me-PC: TVersity Media Server
a accesskey=”7” href=”/ms?serv=3&id=0/3/976
a accesskey=”9” href=”/ms?serv=3&id=0/3/976
Key(2 Jays Remix)
The first line represents the third found media
server (named Me-PC: TVersity Media Server”) in
the digital home network. The second one represents
a folder item (named All”) of the media server. The
third line represents a video item of the found media
server (existing in the ”All” folder).
The HTML code of each hyperlink has the follow-
ing format:
<a accesskey="[access key of the hyperlink]"
href="[arguments]">[name of the item]
</a>([type of media item])<br/>
The access key parameter is used to be compli-
ant with statement #9 of the MWBP 1.0. It is set
to the position of the link in the HTML page; it can
vary from 1 to 20, so it is coded with two charac-
ters. The source of the hyperlink ([arguments]) is
formatted for media servers and folders as follows:
ms?serv=[identifier of the server]&id=[identifier of
the folder (set to ”0” if the link represents a media
server)]&inf=[starting index of items that will be ex-
plored if the link is hit]&total=[number of XML child
items (folders and/or media items) used in pagina-
tion]. For a media resource link (e.g. a video or audio
file), the format is similar to media servers and folders
links with the new attributes: idmedia and action. The
idmedia is an identifier of the resource. It is used to
avoid including the hard link provided by the media
server that is in general very long. Using the idme-
dia attribute allows to adapt, in real time, the original
media if it is not supported by the user’s terminal (ac-
tion=adapt). Otherwise, the user can directly access
to the media without adaptation (action=deliver). The
delivered page’s size of the found servers and items
list can be calculated as follows:
Size = sizeof(templateOfThePage)+
n· sizeof(itemLink) + sizeof(navigationImages)
The size of the template is fixed (3,83 Kb in our
implementation). The size of a navigation icon (next
or previous) is 1,69 Kb. Note that only one naviga-
tion icon is displayed in the first and the last page
of the paginated result (Fig. 4). Also, even that the
same navigation icon is displayed twice on the bot-
tom and the top of the page (in respect to the MWBP
statement #6), the icon size is considered only once
in calculating the size of the delivered page. This is
done because the browser requests the icon only one
time, and thanks to its cache, the icon is displayed in
the top and the bottom of the page without sending a
new request.
The maximal length of a hyperlink’s text (the
[name of the item] value) is set to 30 characters (fol-
lowed by the
string if the original text is greater
than 30. According to the format discussed previously
<a accesskey="[access key of the hyperlink]"
href="[arguments]">[name of the item]</a>
([type of media item])<br/>),
and the max-
imal encoding length of each attribute, we have
evaluated the maximal length of a complete link to
121 bytes.
With the result of (1), the maximal overall size of
a delivered page (including n links) is then:
Size(Kbytes) = 3, 83+ 0, 118· n+ 2· 1, 69
= 7, 21+ 0, 118· n
Figure 4: Pagination and interlinking of a parent element.
The advanced Web interface of Universally deliv-
ers a paginated result where the number of displayed
links in each page depends to the profile of the user’s
terminal (the screen size) and is limited to a maximum
of 20 links. This property, with the result of (2), guar-
antees the compliance with the MWBP statement #21
in respect to the default delivery context which was
defined as being the minimum delivery context spec-
ification necessary for a reasonable experience of the
Web (W3C-BP, 2008). Indeed, the considered met-
ric here is the size of each delivered page. Whatever
services complexity, in our case the result’s size will
never exceed 10 Kbytes which is suitable for any net-
work access technology (cellular, wireless and wired)
and required in a default delivery context. This sat-
isfied property means that the size of each received
result (after the network discovery of services) still
very small. Hence, this will not affect negatively the
user experience in discovering multimedia resources.
The content pagination is applied to deliver fragments
of the original content in a suitable way that is well
balanced between the number of necessary requests
and the size of each fragment. In a digital home en-
vironment, Universally applies pages pagination re-
garding the list of discovered media servers and the
list of items hosted by a media server or stored in an
explored folder. In other term, if the list of discov-
ered media servers or items of a given folder is long
and not adapted to the terminal’s limitations, the list
will be divided in small pages interlinked with next
and previous hyperlinks (Fig. 4). In order to paginate
the content of a root element (media server or folder),
the number of child elements must be know in ad-
vance. To do so, Universally uses the invocation of
the SOAP actions: Browse and BrowseMetadata sent
to the Content Directory service of the media server.
This service is identified by the URI: urn:schemas-
upnp-org:service:ContentDirectory:1#Browse. The
number of child elements is returned within the SOAP
result in the XML attribute childCount. In the follow-
ing, an example of the result of a SOAP Browse action
received, in Universally, from a media server.
<DIDL-Lite xmlns="..">
<container id="0" childCount="4" parentID
="-1" restricted="true">
<res protocolInfo="http-get:*:image/jpeg:
The container tag, specifies the identifier of the
current element (here it is the root of the media
server, id=0) and the number of child elements (child-
Count=4). As shown in Section 5, every browsing
link, displayed within our Web interface, includes the
inf and total arguments. The first argument is used
to display child items (of the current parent element)
starting from the inf position (Algorithm 1, line 2).
The second argument has the value of the childCount
attribute. It allows to check if there are more ele-
ments to display in a next page or not (Algorithm
1, line 3). If it is the case, a next link is included
in the presentation page. As mentioned previously,
the number of the child elements to display in a page
(itemsPerPage) is set according to the terminal’s pro-
file. Handling terminal’s profiles is based on the Mul-
timedia Universal Profiling (MUP) schema that we
have defined based on the W3C RDF language (the
proposed RDF schema will not be discussed in this
paper) (Lemlouma, 2012). MUP allows to describe
the profiles that are stored in a profiles repository and
specify the displaying and rendering capabilities of a
device. Near to 14000 different user agents are stored
(Lemlouma, 2011).
Figure 5 shows an overview of the HTTP content-
length variation over the access time. The measure-
ments concern all the HTTP responses (HTML and
images) of Universally to a mobile phone while ex-
ploring four media servers during about one minute.
The results show the conformance of Universally re-
sponses regarding the size metric adopted in the de-
fault delivery context of MWBP as predicted and dis-
cussed in Section 5. Here, the maximal size is near to
3,5 Kb.
Algorithm 1: Result pagination and exploration.
Require: inf, itemsPerPage and childCount.
Ensure: Display items in a paginated way.
1: nextHTML
; previousHTML
2: displays itemsPerPage items from the parent el-
ement starting from the item position: in f;
3: if (inf + itemsPerPage) < childCount then
4: nextHTML
'<a accesskey="N" href="/ms
?serv = ID
)"><img alt="Next"
src="Next.png" ..></a>';
5: end if
6: if inf > 0 then
7: previousHTML
'<a accesskey="P" href="/ms
)"><img alt="Previ-
ous" src="Previous.png" ..></a>';
8: end if
9: displayingHTML
Figure 5: Content pagination and HTTP content-length over
access time.
Similar to content pagination, media delivery has to
improve the user experience and be adapted to lim-
ited devices. In a digital home environment, a large
amount of the stored content is rich media content
(movies, music, pictures, etc.) having often a high
quality and requires an important storage space. Sev-
eral media delivery protocols and methods were pro-
posed for different environments including limited
devices (Ma K. J.; Barto and R., 2011). In order to
gain access to a large amount of heterogeneous de-
vices and avoid complex network requirements, we
adopt the HTTP as the delivery protocol. For hetero-
geneous environments, HTTP represents a common
protocol either for downloading or streaming media
and structural resources. Furthermore, the protocol
is easily accepted by firewalls and different network
configurations which is not the case of other methods
like RTP over UDP with dynamic ports. Universally
considers the media fragmentation with the HTTP
protocol by implementing the HTTP Live Streaming
(Pantos and May, 2011). In Universally, when an
original video has to be adapted (based on the termi-
nal’s profile (Lemlouma, 2012)), our advanced Web
interface delivers a hyperlink pointing to a playlist file
(a m3u8 file, as shown bellow) that contains links to
different video fragments.
#EXTINF:10, ..
The playlist content is updated each time a new video
fragment is created. In a video adaptation instance,
the playlist includes links to the last ve created
segments. Our implementation of the media frag-
mentation is based on the VLC transcoding of the
VideoLAN project (VIDEOLAN, 2011) with a video
segment’s duration of 10 seconds. Figure 6 shows
an overview of the different segments length down-
loaded by the native player (AppleCoreMedia) of a
mobile phone (an iPhone 4GS, iOS 5.0.1) during a
real time video adaptation. The original video, of our
experimentation, is a HD video with a size of 1,02
Gbytes, a duration near to 25 minutes, video codec of
H264 MPEG4 AVC (part 10), a dimension of 1440
per 1080 and audio codec of A52 with a rate of 384
Kb/s. The adapted format is H.264 Base Profile, level
3 (ITU-T H.264, 2009) with a dimension of 320
per 240 resolution. The generated fragments allow
the player to download and use segments buffering
for a smooth play-out. Ideally, since each segment -
generated in real time- represents 10 seconds of the
original video, the player should buffer required seg-
ments prior to the current instant of video playing.
For instance, at t=50 seconds (from the beginning of
a video), the fifth segment must be previously gener-
ated and downloaded. The generation and download
of a segment depend to the segmenter implementa-
tion, the original and targeted video transcoding, the
segment size and the available link bitrate between
Figure 6: Media segmentation streaming.
Figure 7: Media fragments generation.
Universally and the user’s terminal. Figure 7, shows
the generation times and lengths of sixty segments of
10 seconds of our HD test video. For the user expe-
rience, the observed video segmentation delays vary
from 0 to 4 seconds. This real time media adaptation
enables users to explore quickly existing media items
and start to render them in an optimal way indepen-
dently to the original size and format constraints.
In this paper, we addressed the accessibility to ad-
vanced networking functionalities and media render-
ing using a new framework. The objective of propos-
ing this new framework is to make advanced services
accessible for heterogeneous and limited devices that
are natively unable to: handle networking protocols,
interact with other components of the network and
achieve complex networking and access actions. We
have shown that based on a standard Web interface
and the HTTP protocol, the user experience (in dis-
covering, using and accessing complex networking
and multimedia services) was improved. First, thanks
to the Universally approach, limited terminals are
now able to discover and access complex services;
this was not initially possible for terminals that do
not support advanced networking operations such as
the multicast. Secondly, the approach guarantees a
standard and accessible network response which is
very limited in size: a maximum of 10 Kb for the
Web interface and 950 Kb for media segments what-
ever the complexity of the existing digital home net-
work. Whether with the content pagination or the me-
dia segmentation, the quality of experience of the user
is improved whatever the access technology used by
its device. The content fragmentation regarding Web
pages and media content has permitted to optimize
the content delivery for terminals with a minimal set
of capabilities. Within the DLNA environment, and
thanks to Universally, searching, access and render-
ing of media resources and services is enabled from
anywhere to mobile phones and other limited devices
that do not support natively required DLNA network-
ing functionalities and complex media rendering.
Lemlouma, T. (2011). An overview of the MUP
repository’s identifiers, january 2012. http:// peo-
identifiers repository version 01 2012.txt.
Lemlouma, T. (2012). Source of the multimedia universal
profiling (MUP) schema, january 2012. http:// peo-
Ma K. J.; Barto, R. B. S. and R., N. (2011). Mobile video
delivery with HTTP. In IEEE Communications Mag-
azine 2011, Volume: 49, Issue: 4, pp: 166-175.
Pantos, R. and May, W. (2011). HTTP live streaming,
september 2011.
DLNA (2006). DLNA Network Device Interoperability
Guidelines, october 2006. http://
DLNA (2007). Digital Living Network Alliances:
DLNA overview and vision whitepaper, 2007.
ITU-T H.264 (2009). ISO/IEC 14496-10 AVC. ad-
vanced video coding for generic audiovisual ser-
vices [s].
UPNP FORUM (2008a). UPNP AV Architecture:1, 30
september 2008.
UPNP FORUM (2008b). UPNP Device Architecture 1.0,
24 april 2008.
VIDEOLAN (2011). VideoLAN project. http://
W3C-BP (2008). Mobile web best practices 1.0, mobile
web initiative (mwi). In W3C Recommendation, 29
July 2008.
W3C-WCAG (2008). Web content accessibility guidelines
(wcag) 2.0. In W3C Recommendation 11, December