This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The Bug 13358 (http://www.w3.org/Bugs/Public/show_bug.cgi?id=13358) provides a means of receiving an event for when tracks are added. In the discussion over how the bug is resolved it was proposed to create a seperate bug for addressing when tracks are removed. Below is a description of the use case. Support of events for when tracks are adding will create problems for application developers that need to get information when tracks are removed. This is particularly a problem when working with live broadcast (as discussed from webtv IG) or playlists controlled from the video server (single URL is used to initiate the stream). Both cases will have different content or programs being streamed with possibly each content or program having different tracks. An example for how an application developer may have problem is when a user has language preferences beyond a single language for subtitles or audio. The user preference may be (1) spanish, (2) english, and (3) french. The application may indicate spanish based on available audio/subtitle tracks for a program in a live broadcast but then next scheduled program the spanish audio/subtitle is removed. How does an application keep track of the removed track and change it to english? There may additonal considerations on how a UA may handle the track list. The <video> is long lived and may go for days or weeks. The list of tracks may become very large. A means of refreshing the tracks and remove from the list tracks that are outdated is desired. This may be supported by the application (*author*) fetching the tracks on a track change event. Additionally considerations should be made for UA behaving differently when handling modifications to details on a track. Changes may generate a new track instead of reusing an existing track. For example if a track has an audio track which starts with support stereo and then changes to 5.1 surround. A UA may keep track list unchanged but simply modify one description, other UA may create a new track. It is not possible to dictate exactly how UA shall behave and it is necessary to have a solution that accmodates for frequent changes to tracks overtime.
Are there any sites actually providing a single stream in this way currently? All the sites I've seen that show TV on the Web — Hulu, YouTube, BBC, etc — do it one programme at a time, where the build-up of tracks wouldn't be problematic (and indeed would be required since you'd always be able to seek back to where the tracks exist); and all the sites I've seen that show streams — Apple's events, YouTube live, live.twit.tv, etc — do it with a fixed number of tracks, where there would be no build-up.
(In reply to comment #1) > Are there any sites actually providing a single stream in this way currently? > All the sites I've seen that show TV on the Web — Hulu, YouTube, BBC, etc — > do it one programme at a time, where the build-up of tracks wouldn't be > problematic (and indeed would be required since you'd always be able to seek > back to where the tracks exist); and all the sites I've seen that show streams > — Apple's events, YouTube live, live.twit.tv, etc — do it with a fixed > number of tracks, where there would be no build-up. The problem is not as much with existing internet video services. It is the regular broadcast (satellite, cable, terrestrial and even IP based on IGMP) that is the problem. The purpose of this bug is to identify the requirements coming from the webtv IG for bridging the TV requirements to the web (HTML5). If you need an example in OIPF we have defined JS API's to retrieve this type of track information including adding and removing. Without this support it is hard to integrate <video> with these different broadcast systems. Do you need explicit examples of deployed solutions? Does it matter that the examples are not only IP based but broadcast over satellite, cable, etc? There is plenty of material just need to know in which format you want it.
I don't understand. What does cable TV have to do with the HTML <video> element? Are there cable operators who are planning on outputting their channels such that Web pages can see them, including using all the original tracks instead of collapsing them into the fixed number of audio and video tracks that they currently transmit over the cable? What I need is a clear understanding of who is going to be using this feature, so that I can make sure that we design it in such a way that it properly addresses the needs of those use cases.
In countries following the DVB standards one can look at what the TV supports. If I take Sweden for example the tuner is built into the TV as below example (sorry it is in Swedish). In this example the TV suports DVB-T (terrestrial) and DVB-C (cable). I am sure I can find TV's with DVB-S for satelite. http://www.elgiganten.se/product/ljud-bild/tv/UE40D5004XXE/samsung-40-led-tv-ue40d5004 These are retail devices and there are managed devices like Set Top Box (STB) that have integrated tuners. One can assume tuner is an independent part of the browser but when merging TV and browser one needs to assume they can be integrated and having the framework in <video> to support the characteristics of these broadcast systems is fundamental. If there is a question of deployments one can refer to the specifications coming from OIPF. Refer to section 7.16.5 and support of components which is an equivelent to tracks. There are commercial deployments using these specifications. http://www.oipf.org/docs/Release2/V2.1/OIPF-T1-R2-Specification-Volume-5-Declarative-Application-Environment-v2_1-2011-06-21.pdf The fundamental shift is that HTML5 does not only run on a PC but also on TV's and other retail devices. The spirit of webtv IG was to capture the requirements coming from the TV and map them to W3C and HMTL5. You ask who will use this, it will be web developers who want to create a more integrated experience between the TV and web.
Are you saying these devices will allow arbitrary Web pages to display cable TV in their pages? What URL will they use for this? Does DVB really transmit an ever-changing set of tracks, never reusing tracks? That seems... rather odd.
There is a single stream of type mpeg2 transport stream (MPEG2-TS) which encapsulates audio, video, program data, etc. A single URL is used to refer to MPEG2-TS. This is only an example. On the question of reusing tracks it is more a question of characteristics of the track. Even on the same language the track may change characteristics, PID(identifier), description (stereo to 5.1), etc. How a UA may reuse or not a track is an implementation issue. The trick is how we make the tracks flexible not to impose restrictions on the implementations. PS-I am at TPAC for any discussion or clarifiction. I sometimes wear a maroon cap. Since I am tall I am hard to miss.
Cool, I'll try to find you. I'm wearing a sweater that reads "C@". Usually near the center of whatever controversy is going on...
No objections were raised to making this a LC issue: http://lists.w3.org/Archives/Public/public-html/2011Oct/0138.html
At the F2F meetings in Santa Clara, the HTML WG appeared to support this bug as well as bug 13359 which requests a way to identify types of data in a track element. The combination of bugs 13358 (already accepted), 13359 and 14492 should address the needs of the Media Pipeline task force (MPTF). Here is a link the to relevant MPTF requirement: http://www.w3.org/2011/webtv/wiki/MPTF/MPTF_Requirements#R3._Handling_of_In-band_Tracks
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Accepted Change Description: see diff given below Rationale: I've added this. It may end up being removed if the browser vendors find that it's not worth implementing.
Checked in as WHATWG revision r7098. Check-in comment: support "removetrack" events to handle long-running <video> elements on streams with multiple TV shows having different audio and video streams. http://html5.org/tools/web-apps-tracker?from=7097&to=7098