RE: Still about "id" format

________________________________
From: Jon Piesing [Jon.Piesing@tpvision.com]
Sent: Friday, November 15, 2013 1:06 AM
To: Bob Lund; Brendan Long; Giuseppe Pascale
Cc: public-inbandtracks@w3.org
Subject: RE: Still about "id" format

>The PID is used by the Web application to correlate a video, audio or text track, created from an MPEG-2 TS media resource, with the PMT data exposed as TextTrackCues.

The "id" property must have other use cases than what you mention as it's defined in HTML5 which doesn't expose PMT data as TextTrackCues.

As far as I can see from the email archive, this group has not yet made a decision to follow the approach of exposing PMT data as TextTrackCues. The "Re: Recap of TPAC discussion" email includes an alternative that looks much more reasonable to me. If that alternative was to be adopted then the use-case for "id" mentioned previously goes away.

<Bob> Yes, if we choose the to store a track's metadata in a track attribute the then the id is not needed to correlate the track with separate metadata TextTrackCue content </Bob>

"This was to set an attribute on all video, audio and text tracks that contain that tracks media resource metadata. The inbandTrackMetadataDispatchType [1] attribute  essentially fills this role for TextTracks with 'kind' == metatdata. We could propose adding this attribute to video and audio tracks, and renaming it trackMetadata."

I can understand non-W3C groups taking the approach of exposing PMT data as TextTrackCues in order to avoid forking any W3C APIs. However for the W3C to follow this approach instead of the approach mentioned in the "Re: Recap of TPAC discussion" email would seem utterly bizarre to me.

> Thus, it is not required that the PID have any end-to-end identity. The PMT data will contain the component_tag, if present, and therefore Web app can access that if needed.

The use-cases that motivated adding the "id" property in the first place should be looked at to see if any of them need or would benefit from end-to-end identity.

<Bob> If the component_tag is in the PMT, it will be available to Web applications in both implementation approaches, whether it is in the id or not. It isn't a question whether the data will be available. </Bob>

Jon



________________________________
From: Bob Lund [B.Lund@CableLabs.com]
Sent: 14 November 2013 21:01
To: Jon Piesing; Brendan Long; Giuseppe Pascale
Cc: public-inbandtracks@w3.org
Subject: Re: Still about "id" format



From: Jon Piesing <Jon.Piesing@tpvision.com<mailto:Jon.Piesing@tpvision.com>>
Date: Thursday, November 14, 2013 1:33 AM
To: Brendan Long <B.Long@cablelabs.com<mailto:B.Long@cablelabs.com>>, Giuseppe Pascale <giuseppep@opera.com<mailto:giuseppep@opera.com>>
Cc: "public-inbandtracks@w3.org<mailto:public-inbandtracks@w3.org>" <public-inbandtracks@w3.org<mailto:public-inbandtracks@w3.org>>
Subject: RE: Still about "id" format
Resent-From: <public-inbandtracks@w3.org<mailto:public-inbandtracks@w3.org>>
Resent-Date: Thursday, November 14, 2013 1:34 AM

If a content provider has content with >1 track of the same type where these cannot be distinguished by standard per-track metadata then having an id that survives passage through the distribution system has value. In DVB markets, PIDs do not have this property.
Indeed the same elementary stream may have different PIDs in different geographical areas and when received by different distribution channels (cable / satellite / terrestrial / multicast IP).

The PID is used by the Web application to correlate a video, audio or text track, created from an MPEG-2 TS media resource, with the PMT data exposed as TextTrackCues. Thus, it is not required that the PID have any end-to-end identity. The PMT data will contain the component_tag, if present, and therefore Web app can access that if needed.

Using the PID as the track.id seems better since the PID is available in all regions. Also, it is consistent with the idea of using the media resource stream ID as the track id.



Jon
________________________________
From: Brendan Long [B.Long@cablelabs.com<mailto:B.Long@cablelabs.com>]
Sent: 13 November 2013 17:15
To: Giuseppe Pascale; Jon Piesing
Cc: public-inbandtracks@w3.org<mailto:public-inbandtracks@w3.org>
Subject: RE: Still about "id" format


- what is the use case we are trying to address by exposing these info via the track ID attribute? Is the only think we care is to have something that unique locally to the application (in that case it may not matter much if the PID changes along the broadcast value chain as far as each track as a unique PID at the end) or are we trying to convey some other type of information?

One case is the media fragments, where it would probably be useful if the ids were controllable (like Matroska TrackUIDs and Ogg Skeleton Names are), or at least stay the same after transcoding. I assume that would make authoring easier.

The other is finding metadata, where it probably doesn't matter if the ids change, just that they are consistent within a single file.