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

[Ted Hardie <[e-mail]>]

Hi Glenn,

In-line.

On Thu, Jul 21, 2022 at 1:35 PM Deen, Glenn <[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?

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]> 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]> 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]
> https://www.ietf.org/mailman/listinfo/moq
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/moq__;!!CQl3mcHX2A!EqjB0ptNCUvf7xVMkakLbxPdk_Gx4kKd1I17Jbo4Lq6nWX6RncjNeI9A4VKBUT10uMHrJ2ZWirqKdVczWg$>
>
>