comments on Media Fragments Working Group

Hi all,

 

 

Below you'll find some comments of MMLab regarding the "Media Fragments
Working Group":

 

"The Group will focus on developing a mechanism to uniquely identify a
temporal fragment within an audio or video object, that is independent of
the underlying audio or video codec in use"

 

Pointing to a media fragment by means of a particular time scheme is indeed
independent of the coding format and will be based on existing solutions
such as MPEG-21 URI or temporal URI. However, since most media available on
the web is encoded using a specific coding format, delivering the fragments
as identified by the URI is not trivial. Two possibilities exist:

.          The full media fragment is sent to the client. Since the client
has a decoder at its disposal, the client has knowledge about the coding
format used. Hence, the media fragment can be partially decoded (i.e.,
decode only the parts pointed out by the URI). One of the biggest problems
with this approach is bandwidth usage. The client does not want to download
the full media fragment if he/she only wants to see specific segments. Note
that this is especially true for audio/video fragments; for images, this
problem could be less relevant (i.e., extract a specific region of the image
on client side)

.          Adapt the full media fragment on the server and send only the
necessary fragments to the client. This solves the bandwidth problem but
introduces a new problem: a web server does not have knowledge about the
underlying coding formats (used to encode the media fragments located on the
server). Hence, adaptation logic needs to be present on the server in order
to correctly deliver the requested content (via the URI) to the client. Note
that in case of using container formats such as MP4, things could go easier
since container formats are capable of keeping timestamps associated with
the compressed streams. Based on these timestamps, the relevant fragments
could be extracted.

Next to the requirement of adaptation logic, there is another problem
regarding the delivery of the requested URI. Compressing media fragments
usually introduces dependencies in the compressed bitstreams. For example,
pictures in a video fragment are predicted based on previous (and/or future)
pictures. Hence, random access to a compressed bitstream (especially in case
of video) is not trivial and requires the availability of random access
points (if not, decoding-encoding operations are needed). Furthermore, the
random access points in a compressed video fragment won't match (in most
cases) with the timestamps specified by the URI. Therefore, delivering
partial media fragments of compressed bitstreams will not match exactly with
the timestamps specified in the URI. Note that container formats provide
solutions for this problem by enabling the possibility to indicate that
particular frames are not allowed to be displayed.

 

 

Sincere greetings,

 

Erik Mannens & Davy Van Deursen

 

Gaston Crommenlaan 8 bus 201

B-9050 Ledeberg-Ghent, Belgium

 

T: +32 9 331 49 93

F: +32 9 331 48 96

M: +32 473 27 44 17

 

http://multimedialab.elis.ugent.be