Re: [Moq] [EXTERNAL] Re: Encrypted Media Metadata

["Deen, Glenn" <[e-mail]>]

In line

On 7/21/22, 6:17 AM, "Ted Hardie" <[e-mail]> wrote:

Hi Glenn,

In-line.

On Thu, Jul 21, 2022 at 1:35 PM Deen, Glenn <[e-mail]<mailto:[e-mail]>> wrote:
Hi Ted,

Perhaps replacing the “timed metadata, such as … “ with just “metadata” to cover the broad range of metadata

So:

The media publication protocol will be a push protocol for sending media including audio, video, and timed metadata, such as closed captions and cue points. The common protocol for publishing media over ingest and distribution will support:
Becomes:

The media publication protocol will be a push protocol for sending media including audio, video, and metadata. The common protocol for publishing media over ingest and distribution will support:
I think the two examples given (closed captions and cue points) are pretty important to retain and that "timed metadata" there indicates how they are linked to other data.  Would it be possible to replace that change with one that refers to a broader class of metadata with different links?

Fair enough, what then if we made it inclusive:    “audio, video, and metadata including timed metadata such as closed captions and cue points, and broader metadata that may include content data, encoding data, distribution data as some examples”

-glenn

regards,

Ted


And add “metadata transport” as a bullet, so as to suggest that metadata is a first class data element being included.

-glenn

On 7/21/22, 2:16 AM, "Ted Hardie" <[e-mail]<mailto:[e-mail]>> wrote:

Hi Glenn,

I think I follow your core concern, but I'm a little confused about how to reflect it in the charter in ways that don't start to assume the solution space.  From your perspective are you looking for an elaboration to one of these bullets:


The media publication protocol will be a push protocol for sending media including audio, video, and timed metadata, such as closed captions and cue points. The common protocol for publishing media over ingest and distribution will support:
•         one or more media formats,
•         an interoperable way to request media and encodings,
•         rate adaption strategies based on changing codec rates, changing chosen media encoding/qualities,
•         cache friendly media mechanisms
So that they specifically mention the metadata in, for example, the bullet about requesting media and encodings?  Or are you looking to add a bullet here?

If you have charter text in mind, or can develop some, that would be most helpful.

thanks,

Ted

On Sun, Jul 17, 2022 at 2:10 PM Deen, Glenn <Glenn_Deen=[e-mail]<mailto:[e-mail]>> wrote:
I get the sense from the proposed charter Media Metadata is currently treated sort of monolithically in terms of access to it, its encryptability, and its use in different workflows.  Metadata is quite rich as a part of the media delivery workflow and is getting increasingly important and extensive as media transport and media types evolve.  I propose that it needs more specific focus in the group.

Metadata data and access to it is something that maybe should be considered a distinct type of media content on its own along with having distinct from the transported media authenticated access and encryption considerations that are independent of the media being transported.

This could possibly be part of the “coordinated or cooperative” middle boxes that Lucas has mentioned in his not on the thread “Re: [Moq] "MoQ Architecture" question from Spencer's mail”

Metadata should be more distinctly mentioned in the charter along with perhaps a couple of documents that specifically cover Metadata authentication and encryption and Metadata Use Cases by both end points and middle boxes.

-glenn
--
Moq mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/moq<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/moq__;!!CQl3mcHX2A!EqjB0ptNCUvf7xVMkakLbxPdk_Gx4kKd1I17Jbo4Lq6nWX6RncjNeI9A4VKBUT10uMHrJ2ZWirqKdVczWg$>