Re: [GGIE] Some questions on GGIE

["Deen, Glenn (NBCUniversal)" <[e-mail]>]

Hi Linda,


>> Does each instance of MEN represent one “manifest file” for a video content (i.e. the complete set of Chunks for one video)? Like movie A can consist of XX of chunks, and there is one  MEN instance for Movie A? another MEN instance for Movie B?

Each MEN is defined for a specific type of encode/transport. Think of it like a template for the  addresses allocation scheme in the subnetwork addresses the video elements/chunks is defined.  For instance you could defined a MEN layout for MPEG-DASH, and assign in the layout that say a particular address in the network returns the DASH manifest for the player to use.   If you had a different type of encoding/transport that used a different type of manifest, you would define a different MEN scheme for that encoding/transport.  In our demo we defined that address  Prefix::0 returned a DASH manifest, which is but one way it can be done.

The MEN is abstraction/scheme that is defined for different codec/transports in a way that is appropriate for the way the particular codec/transport works.    This permits GGIE to support essentially any codec/transport since you just need to define the MEN scheme appropriate for the application.     We defined as an example such a scheme for MEPG-DASH, and we’ve discussed creating others as examples too.

The nice part of this, is that this would let you define new future video transports and they can be added to the GGIE ecosystem by defining an appropriate MEN.  Meaning we don’t have to have all the answers upfront, and the system is easily extensible without changing any of the previous GGIE choices.


>> Does the MEN instance for Movie A has XX number of chunks? Does each chunk have an address (i.e. does each chunk of the video clip has an address)?

Yes, at least for the MEN we defined for MPEG DASH because DASH partitions the video into chunks.  The way you would do it for other transports would depend on the nature of the transport, but in general yes.   II our example we did give each chunk does have a distinct address, and we also organized them into a address assignment scheme that reflected the MPEG-DASH iFrame alignments.


>> Media Encoded Network” same as “Media Encoding Network”?

Yes. Forgive us, we are trying to settle down on the terminology and there are some consistency edits that need to be made in the IDs.


>> Does one instance of “Media Encoding Network” have one address? Or each element of one MEN have one address?

A MEN instance will have a distinct prefix, and the chunks under it will have addresses allocated in a format appropriate scheme.   Together they are basically an IPv6 subnet.  To introduce a new format, you would define a new MEN for it, and then follow theatMEN scheme when you assign addresses to the media elements.


>>-        You mentioned during our conversation in Bits& Bytes to use IPv6 addresses. Are the IPv6 addresses used to represent MEN? Or the elements of a MEN instance?

An MPEG-DASH MEN is an IPv6 subnet with a common prefix and then each chunk is allocated an IPv6 address.  The layout is in the MEN for MPEG-DASH ID, but a big part of it is that we organized the chunk with aligned iFrames so that their shard addresses where all the same, except for the encode ID bits.       The layout was  of the 128 bits:     Prefix N bits :  Encoding ID M bits:  Shard ID 128-N-M bits.        This lets the MPEG-DASH player change bit rate encodings by just changing the Encoding ID bits and leaving everything else the same.


>> -        Is the “Shard” same as MEN instance?
MPEG-DASH uses the term Chunk for a block of frames of video with a starting iFrame.    Since we are trying to make GGIE support a wide variety of encodings/transports we use the generic Shard instead of Chunk.
Chunk == Shard


>>  Your saying of “networking routing the request for the shard” is about find the location addresses for the elements of the Shard, correct?

Yes, but like any routing request it also is about the path to the shard.    This gets to part of the reason why we are proposing addresses for shards in GGIE, so that the network can be involved in helping make path choices between the requestor and an instance of the shard.   Today it’s entirely done by  the manifest creator with some interaction with the DNS in many cases when it creates the URL’s that it populates the manifest with.


-g    -glenn

From: GGIE <[e-mail]<mailto:[e-mail]>> on behalf of Linda Dunbar <[e-mail]<mailto:[e-mail]>>
Date: Thursday, August 4, 2016 at 1:03 PM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "Leslie Daigle (TCE)" <[e-mail]<mailto:[e-mail]>>
Subject: [GGIE] Some questions on GGIE

Glenn,

I talked to you during the IETF 96 Bits & Bytes a couple of weeks ago.
Really like the content in the draft-deen-daigle-ggie-01. Being a network person, I see some elements of GGIE that network can provide.

First a few questions:

-        Media Encoding Networks (MEN):

o   Does each instance of MEN represent one “manifest file” for a video content (i.e. the complete set of Chunks for one video)? Like movie A can consist of XX of chunks, and there is one  MEN instance for Movie A? another MEN instance for Movie B?

Does the MEN instance for Movie A has XX number of chunks? Does each chunk have an address (i.e. does each chunk of the video clip has an address)?



o   “Media Encoded Network” same as “Media Encoding Network”?

o   Does one instance of “Media Encoding Network” have one address? Or each element of one MEN have one address?

-        You mentioned during our conversation in Bits& Bytes to use IPv6 addresses. Are the IPv6 addresses used to represent MEN? Or the elements of a MEN instance?

-        Is the “Shard” same as MEN instance?

-        Your saying of “networking routing the request for the shard” is about find the location addresses for the elements of the Shard, correct?

Thank you very much,

Linda Dunbar
Huawei USA IP Technology Lab
5340 Legacy Drive,
Plano, TX 75024
Tel: [phone] - 5840
Fax: [phone] - 5900