[M4IF Technotes] RE: implementation of SL/DMIF

[steve.mcrobert amd.com]

Guido: Thanks for your most helpful reply.
You comment that "the DMIF spec as such is not being extended, and the "bits
on the wire" are being defined in a separate MPEG4 document (part 8)".
What does "not being extended" mean?
That it will be used as currently defined?
Or that in practice it will be bypassed?
Will the great flexibility in combining different types of object described
in part 1 (systems) of the MPEG-4 Standard be fully supported?
How can I get access to part 8 of the standard?
The ISO Web site lists only parts 1-6.
I purchased  ISO/IEC 14496 parts 1-6 earlier this year (part 1 is dated
2023-12-15)
Regards, Steve 
> -----Original Message-----
> From: Franceschini Guido [mailto:Guido.Franceschini   TILAB.COM]
> Sent: Friday, September 14, 2023 1:20 AM
> To: McRobert, Steve; Guido.Franceschini   cselt.it
> Cc: rkoenen   intertrust.com
> Subject: RE: implementation of SL/DMIF
> 
> 
> Hi Steve,
> 
> RTP and Sync Layer partly overlap indeed, and that's the reason why a
> few fields of the SL (namely: AU_EndFlag <-> Marker bit in some case;
> timestamps) are mapped into field of the RTP header.
> Apart from that, the I-D for RTP over MPEG4 addresses optimization
> issues, and defines a mechanism to aggregate/interleave multiple SL
> packets into a single RTP packet.
> 
> What's DMIF role in all this ? How to implement this in practice ?
> 
> Well, I have largely contributed to the DMIF spec, to the reference
> software dealing with DMIF and SL, and, internally to TILAB, to a vast
> number of what we call "DMIF Instances". I try to shed some light on
> this.
> 
> The basic concept is that a multimedia application, and namely MPEG-4
> Systems, should be implementable independently of how the content is
> retrieved, in order to easily add new transport solutions in 
> the future
> (both from a standard and implementation perspective). This 
> idea lead to
> the definition of a simple but accurate semantic interface, the DAI
> (DMIF-Application Interface)
> Below the DAI you have to deal with the peculiarities of your 
> transport,
> on top of the DAI you only deal with a single content representation.
> After the initial specification in 1998, we amended the DAI 
> and the ref.
> sw. to take into account the fact that different transport mechanisms
> represent the same semantic information (timestamp, AU boundaries,
> Random Access Flag, sequence numbers ...) with different sintax.
> Examples are RTP, MPEG2-TS, MP4 files. To cope with this, the exchange
> of data across the DAI goes in tuples <payload, metainfo>, where the
> payload represents the pure content, and the metainfo semantically
> carries a complete representation of the SL info. Each transport
> mechanism defines headers, which include information such as 
> timestamps.
> Therefore the implementation of a DMIF Instance, dealing with 
> a specific
> transport stack, and knowing the format of those header, can transform
> the information contained herein into a uniform metainfo 
> representation
> to be carried across the uniform DAI.
> What I am stating above is proved in reality: using this technique, we
> have developed in TILAB "DMIF Instances" to get content from:
> 
> - MP4 files
> - the Internet with Unicast and Multicast using 
> UDP/RTP/TCP(unicast), or
> with HTTP
> - MPEG2 Transport Streams
> - Fixed and Mobile phone lines
> 
> Note that the SL information is represented in very different syntaxes
> in all the above cases
> On top of any of those DMIF Instances we run Players, Recorders,
> Recasters and Servers, all using a single interface.
> 
> As far as the AVT efforts are concerned: DMIF defines the DAI and the
> architectural model. It also specifies "bits on the wire" for a few
> cases, by means of the so-called "Default DMIF Signalling Protocol" (a
> protocol for peer-to-peer communication that fully supports all MPEG-4
> Systems requirements. However it overlaps with Hxxx and RTSP, that
> -although unable to support all MPEG4 Systems options- are more
> appealing for developers) In the initial intentions, it was 
> the box into
> which the details of the various transports were to be defined.
> Real-life however indicates that many people do not care about DAI or
> architecture, which are believed to be sort of 
> "implementation issues",
> and wanted to avoid mixing the details of a particular transport with
> the DMIF specification. Therefore, the DMIF spec as such is not being
> extended, and the "bits on the wire" are being defined in a separate
> MPEG4 document (part 8): this document reflects the AVT work and
> "imports" it in MPEG4
> 
> I hope I cleared your doubts.
> 
> Best regards
> 
> Guido Franceschini
> 
> Telecom Italia Labs
> TILAB - Multimedia Division
> Via G.Reiss Romoli 274
> I-10148 Torino, Italy
> tel + 39 011 228 6137
> fax + 39 011 228 6299
> 
> -----Original Message-----
> From: steve.mcrobert   amd.com [mailto:steve.mcrobert   amd.com]
> Sent: Thursday, September 13, 2023 9:21 PM
> To: Guido.Franceschini   cselt.it
> Cc: rkoenen   intertrust.com
> Subject: implementation of SL/DMIF
> 
> 
> Guido:
> 
> I'm having trouble understanding how the Synchronization 
> Layer and the DMIF
> are being implementated in practice.
> 
> The work going on in the AVT group of IETF is focussed on RTP, & seems
> largely to view the Synchronization Layer as overlapping with RTP &
> therefore redundant.
> 
> I can't find any work on the DMIF at all.
> 
> Can you point me in the right direction?
> 
> Thanks, Steve
> 
> The reasonable man adapts himself to the world; the unreasonable one
> persists to adapt the world to himself. Therefore all progress depends
> on
> the unreasonable man. -George Bernard Shaw, writer, Nobel laureate
> (1856-1950)
> 
>  <<McRobert, Steve (E-mail).vcf>> 
>