Re: [whatwg] TimedTracks and MPEG transport streams - tracks can change dynamically
On Wed, Dec 15, 2010 at 3:31 AM, Philip Jägenstedt phil...@opera.com wrote: On Wed, 24 Nov 2010 17:11:02 +0100, Eric Winkelman e.winkel...@cablelabs.com wrote: I'm investigating how TimedTracks can be used for in-band-data-tracks within MPEG transport streams (used for cable television). In this format, the number and types of in-band-data-tracks can change over time. So, for example, when the programming switches from a football game to a movie, an alternate language track may appear that wasn't there before. Later, when the programming changes again, that language track may be removed. It's not clear to me how these changes are exposed by the proposed Media Element events. The thinking is that you switch between different streams by setting the src= attribute to point to another stream, in which case you'll get an emptied event along with another bunch of events. If you have a single source where audio/video/text streams appear and disappear, there's not really any way to handle it. I believe in-band was the keyword in the request. I do not know how technically the change of stream composition works in MPEG, but in Ogg we have to end a current stream and start a new one to switch compositions. This has been called sequential multiplexing or chaining. In this case, stream setup information is repeated, which would probably lead to creating a new steam handler and possibly a new firing of loadedmetadata. I am not sure how chaining is implemented in browsers. In a live situation you basically don't have a choice and you have to use chaining when your input streams change. For a canned situation you can set up all the required tracks from the start and just have them send data later or stop sending earlier. In the canned document situation therefore the number of tracks does not change. It's just that data may not be available for all the time. The loadedmetadata event is used to indicate that the TimedTracks are ready, but it appears that it is only fired before playback begins. Is this event fired again whenever a new track is discovered? Is there another event that is intended for this situation? There is an onload event on the TimedTrack to indicate that a track is finished loading. But there is no event to indicate that a new track is available. Similarly, is there an event that indicates when a track has been removed? Or is this also handled by the loadedmetadata event somehow? No, there is no onunload event on the TimedTracks. No, the loadedmetadata event is only fired once per resource, it's not the event you're looking for. As for actual solutions, I think that having loadedmetadata fire again if the number or type of streams change would make some sense. -- Philip Jägenstedt Core Developer Opera Software Cheers, Silvia.
Re: [whatwg] Bluetooth devices
On Tue, Dec 14, 2010 at 10:12 AM, Bjartur Thorlacius svartma...@gmail.com wrote: I still don't grasp how that could be useful. Please provide an example. So you've got a non-kb, mouse, headphone or camera device, say a permanent storage drive. No, not something so general-purpose. Say it's some type of device where the market is so small that standardization is infeasible -- maybe it's only useful in a particular specialty, and there are only one or two low-volume vendors. Or maybe it's some new type of device where the market is uncertain and nothing has been standardized yet. Given that there's no standard high-level way to interact with the device, it might be desirable to have *some* way to interact with it, necessarily generic and low-level. Probably along the lines of sending and receiving binary messages. At least that's the general idea I get. I can't give any specific examples, but I don't think mass-market stuff like permanent storage drives is what we're talking about here. (We already have filesystem APIs in the works anyway, right?) Of course, more specific real-world use-cases would be necessary before anyone would consider speccing something like this.
Re: [whatwg] Proposal for a tab visibility API
Sorry for the delayed reply. I sent a number of responses over the past week, but it just came to my attention that due to some kind of mailing-list snafu, they never actually were sent out. I've attempted to bring all of my replies into this one message. Sorry for the impression that I had abandoned this thread--that was not my intention! Regarding the fact that background tabs aren't necessarily invisible: - On December 8, Boris Zbarsky wrote: There is no such guarantee for background tabs. For example, browsers may show tab previews in various contexts (Panorama in Firefox 4, e.g.). - The point of the API, as proposed, is that page scripts will know when their content is guaranteed to be invisible to the user--that is, the API will not provide a false positive about invisibility. However, the API may provide false negatives about invisibility, for reasons many others on this thread have been pointed out (including different windowing systems, multiple monitors, partial transparency, etc.). The easiest way to achieve this guarantee is to only consider a tab hidden when it is a background tab within* *a window. The window itself, of course, may be on a little-noticed second monitor, partially obscured, etc. But as you point out, there are still some edge cases where even a background tab is visible. In this specific example, I think the right answer would be to have an additional visibility value of preview, which, for the purposes of the isVisible property, would be considered a hidden state. There are some cases where a tab would consider a tab preview to be hidden (like the puzzle timer use case) and some cases where it would be considered visible (like the video playing use case). This would allow web developers to decide for themselves how they wanted to respond to that case. Regarding the additional abuse potential: -- On December 8th, Boris Zbarksy wrote: I'd really appreciate some comment on this. I'm pretty worried about adding features that we then have to start working around people abusing almost immediately... - Although I agree that there is some additional potential for abuse, I don't think it's a particularly large incremental potential. Sites that want to be annoying already have a very large toolbox today. Sites today could easily hook up a script that detects inactivity on a tab (e.g. lack of scrolling or mouse movement) and pops an alert, refocussing the tab. In practice, this is not a common occurrence--users can vote with their address bar and avoid sites that are needlessly annoying. There would be some easy defenses browser implementors could enact if this focus-grabbing did indeed become a problem. For example, code running in response to a visibilitychange event could be forbidden to open an alert (something that would be easy for moderately-savvy developers to circumvent via a setTimeout). Additionally, if a site pops multiple alerts when the tab is hidden, the alert shown to the user could contain an additional option to Prevent this site from grabbing focus in the future that would not allow alerts when the tab is hidden. Although there is some additional opportunity for abuse, I think that it is not particularly large, possible to defend against if necessary, and outweighed by the advantages such an API would provide to legitimate web developers. Regarding the video player use case from the initial proposal: - On December 8th, Maciej Stachowiak wrote: This use case can be handled without help from the page. In Safari, video (whether through media elements or plugins) won't start playing when a user opens a tab in the background, until the user switches to that tab. - Although what you describe satisfies the specific use case, it doesn't address the more general use case of animations (either explicit via javascript or via CSS Animations) or content that is not a plugin/video file. Regarding solving the use cases that cannot be addressed currently: -- On December 8th, Maciej Stachowiak wrote: That leaves the following use cases: * A puzzle game has a timer that keeps track of how long the user has taken to solve the puzzle. It wants to pause the timer when the user has hidden the tab. * A web app that uses polling to fetch dynamic content can pause polling when it knows the page is hidden from the user. * A page wants to detect when it is being prerendered so it can behave appropriately. I am not sure what the third needs exactly, but it seems like first two could be better served with an API that sets a timer which will only fire when the page is visible. That kind of API might be easier to use right, and avoids the need for JS to run when switching tabs, just to cancel and restart timers. - Although that API might be easier to use correctly (I don't know if I'm convinced), note that it would still have the same abuse concerns as the proposed API. A website developer determined to be annoying
Re: [whatwg] toDataURL image/jpeg composition
On 12/9/2010 3:08 AM, timeless wrote: On Fri, Dec 3, 2010 at 1:06 AM, Charles Pritchardch...@jumis.comwrote: Currently, Firefox and Safari output image/jpeg in a way that differs from the spec: http://www.w3.org/Bugs/Public/show_bug.cgi?id=11431 is there a reason you haven't found/filed bugs in bugzilla.mozilla.org/bugs.webkit.org? Three capable people are documenting here (revised): http://www.w3.org/Bugs/Public/show_bug.cgi?id=11431 On that note: was the following resolved? https://bugs.webkit.org/show_bug.cgi?id=39177 I'm afraid i'm going to mix metaphors. (the ones that come to mind are Bad Pool and Show Your Cards / Don't Keep Cards Up Your Sleeve) ... I consider it rude to expect others to do research to discover pertinent information you already have. I'm not sending people hunting through e-mail threads, to play bad pool on the list. I have limited time, and limited attention. Oliver's response wasn't much help. Oliver's response was a statement explaining what he/the webkit team/apple felt was the right thing from a deployed browser perspective. it's a useful statement. that it didn't help you is unfortunate, but bug trackers are not just for you. it helped me. You seem to know more about that bug than I do, you've not shared it.
