Re: [whatwg] Arithmetic coded JPEGs
I think arithmetic coding is more problematic than you think, from a deployment and usage point of view. Yes, it does save some bits, but alas minimum size is not what people optimize JPEG encoding for; they are much more interested in maximum compatibility. Much hardware support doesn’t include arithmetic coding, as far as I know, and even though libJPEG does, at least some users of that turn it off again. I think that’s partly because it’s quite a bit slower in libJPEG. So, one gains maybe 10-20% compression at the expense of compatibility and performance. Not a trade-off people want to take, I fear. sorry, practical realities bite again... > On Nov 30, 2016, at 6:34 , Evgeny Vrublevsky > wrote: > > Hello. > > I'm writing about arithmetic coded JPEG support. Historically, it wasn't > supported by browsers due patents. But all of these patents are expired > several years ago, and modern libjpeg, libjpeg-turbo and mozjpeg have > optional support of the arithmetic coding. > > Arithmetic coded JPEG support will allow us to recompress all existing > JPEGs losslessly, saving 10-20% of size. I've provided some examples here: > https://bugs.chromium.org/p/chromium/issues/detail?id=669501#c3 > > Similar ticket exists also in the Mozilla's Bugzilla: > https://bugzilla.mozilla.org/show_bug.cgi?id=680385#c17 . Now, I'm just > following this direction from the ticket: >> For now, the right place to go to move forward with this is on the > standards mailing lists, not in this bug. > > Unfortunately, browsers still don't support arithmetic JPEG officially. Is > this a right place to start a discussion if it is possible to change it? > > -- > Best regards, Evgeny Dave Singer sin...@mac.com David Singer Manager, Software Standards, Apple Inc.
Re: [whatwg] What's the element for a paragraph label?
I am guessing that he'd like a consistent way to style the terms in a
‘definition of terms’ section, the acronyms in a ‘list of acronyms’ section,
and so on.
defined terms
Fruit: delicious stuff that falls
from trees
…
acronyms
OTT: lit. Over the Top, figuratively
meaning something excessive
…
> On Sep 7, 2016, at 18:49 , Domenic Denicola wrote:
>
> Hi Brenton, great to have you here.
>
> From: whatwg [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of brenton
> strine
>
>> Is there a semantic element that can be used in a situation like this? If
>> so, I
>> propose adding "label" to the specification for that element.
>>
>> Then again, maybe this most appropriately a .
>
> The question is largely about what you're trying to accomplish. What will be
> interpreting your HTML's semantics? I can think of a few options:
>
> - If this is part of a series of labeled paragraphs, perhaps you are looking
> for dl/dt/dd
> - A heading could indeed be appropriate in some cases
> - strong is probably most generally what you are looking for. Indeed,
> https://html.spec.whatwg.org/multipage/semantics.html#the-strong-element uses
> it in the very first example ("Importance" and the "Example" paragraph after
> that).
> - If this is purely a stylistic label, span indeed makes sense.
Dave Singer
sin...@mac.com
David Singer
Manager, Software Standards, Apple Inc.
Re: [whatwg] Removing mediagroup/MediaController from HTML
> On Oct 3, 2015, at 13:39 , Silvia Pfeiffer wrote: > > On Fri, Oct 2, 2015 at 10:27 AM, Domenic Denicola wrote: >> From: whatwg [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of >> >>> is removal really the right thing to do, given that we have an >>> implementation? >> >> I agree this is a problematic question. I opened >> https://github.com/whatwg/html/issues/209 for the more general issue but am >> happy to have the discussion here since that hasn't gotten much replies. Do >> check out the examples listed there though. E.g. Blink is in similar >> situations with and HTML imports. >> >> The web seems to end up with a lot of APIs like this, where the spec ends up >> just being documentation for a single-vendor implementation. I don't really >> know what to do in these cases. If our goal in writing these specs is to >> produce an interoperable web platform, then such features seem like they >> shouldn't be part of the platform. > > > There is also a question about the why of the current state: is it > just a single-vendor implementation because nobody at the other > vendors has gotten around to implementing it or is it because they > fundamentally object to implementing it. If there are objections, then > it's reasonable to consider removing the feature. Otherwise, it would > be premature to remove it IMHO. Yes. It wasn’t even our proposal (see <https://lists.w3.org/Archives/Public/public-html/2011Mar/0436.html>) and we feel it answers some important cases that we can’t otherwise answer. Some insights from others would be welcome. David Singer Manager, Software Standards, Apple Inc.
Re: [whatwg] Removing mediagroup/MediaController from HTML
> On Oct 1, 2015, at 6:49 , Anne van Kesteren wrote: > > In https://github.com/whatwg/html/issues/192 we're planning on > removing mediagroup/MediaController from HTML since other than WebKit > no implementations appear interested in implementing these features. Hi is removal really the right thing to do, given that we have an implementation? I can understand a note saying that this interface is not currently broadly implemented, as a warning to authors. If there are technical problems, and we have or can imagine a better replacement, I can imagine deprecation as a warning to both implementors and authors. But making an implementation become undocumented seems strange — and as a point of practice, would seem to deter implementors from being first-to-implement of something, or they might get caught like this. That’s not a good incentive. David Singer Manager, Software Standards, Apple Inc.
Re: [whatwg] VIDEO and pitchAdjustment
> On Sep 1, 2015, at 11:36 , Kevin Marks wrote: > > I suppose the browser could generate this data the first time it reads > > through the video. It would use a lot less memory. Though that sounds like > > a problem for the browsers to solve, not the standard. > > There is no *generation* on the browser side; these tables are part of the > file format. > > Well, when it imports stream-oriented media it has to construct these in > memory, but they can be saved out again. I know that in theory this made its > way into the mp4 format, but I'm not sure how much of it is real. Two different questions: a) do the QuickTime movie file format and the MP4 format contain these tables? Yes. b) if I open another format, what happens? For case (a), the situation may be more nuanced if Movie Fragments are in use (you then get the tables for each fragment of the movie, though they are easily coalesced as they arrive). For case (b), classic QuickTime used to ‘convert to movie’ in memory, building the tables. The situation is more nuanced on more recent engines. I think the point of the discussion is that one cannot dismiss trick modes such as reverse play as being unimplementable. David Singer Manager, Software Standards, Apple Inc.
Re: [whatwg] VIDEO and pitchAdjustment
> On Sep 1, 2015, at 10:47 , Yay295 wrote: > > On Tue, Sep 1, 2015 at 11:30 AM, David Singer wrote: > > On Sep 1, 2015, at 4:03 , Robert O'Callahan wrote: > >> On Tue, Sep 1, 2015 at 8:02 PM, Kevin Marks wrote: > >> QuickTime supports full variable speed playback and has done for well over > >> a decade. With bidirectionally predicted frames you need a fair few buffers > >> anyway, so generalising to full variable wait is easier than posters above > >> claim - you need to work a GOP at a time, but memory buffering isn't the > >> big issue these days. > > > > "GOP”? > > Group of Pictures. Video-speak for the run between random access points. > > > How about a hard but realistic (IMHO) case: 4K video (4096 x 2160), 25 fps, > > keyframe every 10s. Storing all those frames takes 250 x 4096 x 2160 x 2 > > bytes = 4.32 GiB. Reading back those frames would kill performance so that > > all has to stay in VRAM. I respectfully deny that in such a case, memory > > buffering "isn't a big issue”. > > well, 10s is a pretty long random access interval. > > There's no way to know the distance between keyframes though. The video could > technically have only one keyframe and still work as a video. yes, but that is rare. There are indeed videos that don’t play well backward, or consume lots of memory and/or CPU, but most are fine. > > >> What QuickTime got right was having a ToC approach to video so being able > >> to seek rapidly was possible without thrashing , whereas the stream > >> oriented approaches we are stuck with no wean knowing which bit of the file > >> to read to get the previous GOP is the hard part. > > > > I don't understand. Can you explain this in more detail? > > The movie file structure (and hence MP4) has a table-of-contents approach to > file structure; each frame has its timestamps, file location, size, and > keyframe-nature stored in compact tables in the head of the file. This makes > trick modes and so on easier; you’re not reading the actual video to seek for > a keyframe, and so on. > > I suppose the browser could generate this data the first time it reads > through the video. It would use a lot less memory. Though that sounds like a > problem for the browsers to solve, not the standard. There is no *generation* on the browser side; these tables are part of the file format. David Singer Manager, Software Standards, Apple Inc.
Re: [whatwg] VIDEO and pitchAdjustment
> On Sep 1, 2015, at 4:03 , Robert O'Callahan wrote: > > On Tue, Sep 1, 2015 at 8:02 PM, Kevin Marks wrote: > >> QuickTime supports full variable speed playback and has done for well over >> a decade. With bidirectionally predicted frames you need a fair few buffers >> anyway, so generalising to full variable wait is easier than posters above >> claim - you need to work a GOP at a time, but memory buffering isn't the >> big issue these days. >> > > "GOP”? Group of Pictures. Video-speak for the run between random access points. > > How about a hard but realistic (IMHO) case: 4K video (4096 x 2160), 25 fps, > keyframe every 10s. Storing all those frames takes 250 x 4096 x 2160 x 2 > bytes = 4.32 GiB. Reading back those frames would kill performance so that > all has to stay in VRAM. I respectfully deny that in such a case, memory > buffering "isn't a big issue”. well, 10s is a pretty long random access interval. > > Now that I think about it, I guess there are more complicated strategies > available that would reduce memory usage at the expense of repeated > decoding. which indeed QuickTime implemented around 10 years ago. > E.g. in a first pass, decode forward and store every Nth frame. > Then as you play backwards you need only redecode N-1 intermediate frames > at time. I don't know whether HW decoder interfaces would actually let you > implement that though... > > What QuickTime got right was having a ToC approach to video so being able >> to seek rapidly was possible without thrashing , whereas the stream >> oriented approaches we are stuck with no wean knowing which bit of the file >> to read to get the previous GOP is the hard part. >> > > I don't understand. Can you explain this in more detail? The movie file structure (and hence MP4) has a table-of-contents approach to file structure; each frame has its timestamps, file location, size, and keyframe-nature stored in compact tables in the head of the file. This makes trick modes and so on easier; you’re not reading the actual video to seek for a keyframe, and so on. David Singer Manager, Software Standards, Apple Inc.
Re: [whatwg] [url] Feedback from TPAC
On Nov 4, 2014, at 15:32 , Anne van Kesteren wrote: > On Tue, Nov 4, 2014 at 4:24 PM, David Singer wrote: >> at the moment I am more interested in understanding what the best behavior >> might be than majority voting > > I don't think there is disagreement about what better behavior might > be in this case, if we skip over the details for the moment. really? Safari, Chrome and Opera all return what to me is eminently sensible stuff://www.app.com/a/b/banana Only Firefox and your parser compose ‘banana’ against 'stuff://www.app.com/a/b/' to make ‘banana’. (I don’t have IE to hand at the moment). Whether they do this because it’s sensible or because it’s the RFC behavior, I do not know, of course. But being future-resilient (we’ll never be fully future proof, I agree) seems pretty desirable. Why is ‘banana’ the better answer here? I assume it fixes some other issue we haven’t explicitly mentioned? > However, > how likely is it in your estimation that Apple changes the URL parser > it ships in this regard? I have no idea. I am not in charge of the products we ship :-(, I just try to help the standards landscape include standards we could or would like to support. Clearly I would not yet be advocating for such a change (but I am asking questions in order to learn and tease out the issues, not oppose, right now). David Singer Manager, Software Standards, Apple Inc.
Re: [whatwg] [url] Feedback from TPAC
On Nov 4, 2014, at 15:09 , Sam Ruby wrote: > On 11/04/2014 09:55 AM, David Singer wrote: >> I am pretty puzzled why the base URL composed >> with the URL results not in >> >> stuff://www.app.com/a/b/banana >> >> but >> >> stuff:///banana >> >> Is this a bug or feature of the spec., or a bug in this implementation? > > Please refresh. I've changed the implementation to match the spec. Spoiler > alert: the results returned now don't match either of the values you mention > above. banana really not good. > Either of those results would be a bug in the implementation. Per the > specification proposal; the existing specification is the RFC > and dominant URL implementations at the moment I am more interested in understanding what the best behavior might be than majority voting > only a limited set of > schemes support relative URLs. Not good. I mean, this means that we would have to change the base generic spec. whenever a new scheme comes along for which relative references make sense. RFC 3986 is clear that relative references are a general feature. I am obviously not understanding why it might be desirable to be so future-fragile here. (Particularly since I am thinking of defining exactly such a scheme). > > - Sam Ruby > >> On Nov 4, 2014, at 14:32 , Anne van Kesteren wrote: >> >>> On Tue, Nov 4, 2014 at 3:28 PM, Sam Ruby wrote: >>>> To help foster discussion, I've made an alternate version of the live URL >>>> parser page, one that enables setting of the base URL: >>>> >>>> http://intertwingly.net/projects/pegurl/liveview2.html#foobar://test/x >>>> >>>> Of course, if there are any bugs in the proposed reference implementation, >>>> I'm interested in that too. >>> >>> Per the URL Standard resolving "x" against "test:test" results in >>> failure, not "test:///x". >>> >>> >>> -- >>> https://annevankesteren.nl/ >> >> David Singer >> Manager, Software Standards, Apple Inc. >> David Singer Manager, Software Standards, Apple Inc.
Re: [whatwg] [url] Feedback from TPAC
I am pretty puzzled why the base URL composed with the URL results not in stuff://www.app.com/a/b/banana but stuff:///banana Is this a bug or feature of the spec., or a bug in this implementation? On Nov 4, 2014, at 14:32 , Anne van Kesteren wrote: > On Tue, Nov 4, 2014 at 3:28 PM, Sam Ruby wrote: >> To help foster discussion, I've made an alternate version of the live URL >> parser page, one that enables setting of the base URL: >> >> http://intertwingly.net/projects/pegurl/liveview2.html#foobar://test/x >> >> Of course, if there are any bugs in the proposed reference implementation, >> I'm interested in that too. > > Per the URL Standard resolving "x" against "test:test" results in > failure, not "test:///x". > > > -- > https://annevankesteren.nl/ David Singer Manager, Software Standards, Apple Inc.
Re: [whatwg] [url] Feedback from TPAC
On Nov 3, 2014, at 15:32 , Anne van Kesteren wrote: > On Mon, Nov 3, 2014 at 4:19 PM, David Singer wrote: >> The readability is much better (I am not a fan of the current trend of >> writing specifications in pseudo-basic, which makes life easier for >> implementers and terrible for anyone else, including authors), and I also >> think that an approach that doesn’t obsolete RFC 3986 is attractive. > > Is Apple interested in changing its URL infrastructure to not be > fundamentally incompatible with RFC 3986 then? I was expressing a personal opinion on readability, and on living in a larger community, not an Apple position. > > Other than slightly different eventual data models for URLs, which we > could maybe amend RFC 3986 for IETF gods willing, I think the main > problem is that a URL that goes through an RFC 3986 pipeline cannot go > through a URL pipeline. E.g. parsing "../test" against > "foobar://test/x" gives wildly different results. That is not a state > we want to be in, so something has to give. Agreed, we have to work out the differences. David Singer Manager, Software Standards, Apple Inc.
Re: [whatwg] [url] Feedback from TPAC
On Nov 2, 2014, at 20:05 , Sam Ruby wrote: > Third, here's a completely different approach to defining URLs that produces > the same results (modulo one parse error that Anne agrees[2] should changed > in be in the WHATWG spec): > > http://intertwingly.net/projects/pegurl/url.html#url > I rather like this. The readability is much better (I am not a fan of the current trend of writing specifications in pseudo-basic, which makes life easier for implementers and terrible for anyone else, including authors), and I also think that an approach that doesn’t obsolete RFC 3986 is attractive. David Singer Manager, Software Standards, Apple Inc.
Re: [whatwg] Features for responsive Web design
On Sep 4, 2012, at 12:47 , Ian Hickson wrote: > On Thu, 7 Jun 2012, Mark Callow wrote: >> >> IIRC Kodak's PhotoCD image format had this characteristic. The first >> part is a low res. image, the second is the differences between the low >> res. image zoomed to the high res. size and the actual high res. image. > > Such formats certainly would make a lot of this simpler! supported in JPEG 2000 (for files in resolution progression order), FWIW David Singer Multimedia and Software Standards, Apple Inc.
Re: [whatwg] was The element, now about alt text
On Jun 3, 2012, at 23:02 , Anselm Hannemann Web Development wrote: > > Sure but why? It is much more clearly to use the alt-attribute than using > text between container and child elements IMO. > >>> Alt-text should always be in an attribute and this would also be easier for >>> screenreaders etc. This may be an aside to the current discussion, but actually I think that user-presentable text should *never* be in an attribute. Why? 1) 'ML' stands for markup language; what's in the markup should be information about the content, not the content itself. 2) More important, when text is in an attribute, it's not amenable to markup. You want to style the alt text, or associate it with a CSS class, or tag it with a language, script, or writing direction, or…? It needs to be in the content, and then that's all possible. I realize that changing where alt text is for existing elements would be…problematic…but I don't think we should propagate the error further. David Singer Multimedia and Software Standards, Apple Inc.
Re: [whatwg] Support for the formation of the Web Hypertext Application Technology Community Group (was Re: HTML Working Group Changes)
On Apr 25, 2012, at 12:48 , Sam Ruby wrote: >> >> I encourage discussion about what the CG will be doing to go to the >> mailing lists that are provided for that purpose: they are listed in the >> top right of the following page: > > Oops: make that top left. Thanks, Sam, but cross-posting as I think it's relevant to people in HTML as well as WhatWG. Please be sure that you choose wisely if following up! As far as Apple is concerned, we plan to contribute and work in both the working group (WG) and the community group (CG). We think they both have important roles, and having them under the one umbrella will enable better fulfillment of those roles. Though the rest of this message discusses mostly what this means for the CG and its relationship to the WG, I want to say that our firm support for the work of the WG remains unchanged. This step is positive for a number of reasons. It brings one of the major places that HTML exploration is done 'home'; now the W3C has a community group working on the 'living (bleeding?) edge', and a working group forming stable specifications. In addition, the WhatWG had a slight lack of infrastructure, most notably an IPR policy. Making it a community group, and having contributions and documents be under that policy, is great. Thanks to Anne for using the -contrib list recently for a formal contribution; that makes it clear that we're under that policy. I also think that the W3C WG/Rec process has struggled for years with dates partly because it tries to guess when innovations will happen -- the exploratory phase of standards has been part of the calendar that chairs have to guess when writing a charter. I think the CGs give us a good opportunity to do that exploration with lighter staff support, no artificial dates, and yet with a policy framework and a family relationship (the CG process also envisages possible transition of material to WGs). There has also been question in the past about use and re-use of HTML text, if some of the work was inside and some outside the W3C. Well, now it's all inside; that concern goes away. Finally, I think this brings clarity to 'where do I help?'. As I see it, if you have new ideas that need working out, experimentation, and discussion, join the CG and help develop ideas there, so that they can be handed to the WG for standardization. And in a CG, it's OK to try, fail, and learn something in the process. In fact, if you're not realizing that some of your ideas don't work out, I'd say that you're being too conservative. WGs really are not good places for ideas with wrinkles. If you have a mature concept that has acceptance and needs a stable, referencable, standard, then work with the WG. Now, CGs are still fairly new; we haven't been all round the cycle with CG-initiated work. But I do think that their structure is well-designed, a very intelligent balance of needs, and really help the W3C be central not only in standardization, but also the exploratory edge. (If you are interested in standards process, read the CG documents, it's well worth it). As I said, we at Apple are excited to be doing both WG and CG work; we need a lively edge and we need stable, interoperable, specifications. I would encourage everyone to do the same, and join and contribute to the group you're not part of - CG or WG. That way you can both initiate and stabilize ideas in supportive environments. Personally, I congratulate all who helped bring this about; though there is undoubtedly more to do, this is a very positive step. Thank you! David Singer Multimedia and Software Standards, Apple Inc.
Re: [whatwg] Decimal comma in numeric input
Sorry, I didn't mean to argue that CSS should be involved, merely that the communication user to user-agent should be considered to use locle-dependent formats, and that the communication user-agent to server should be in a standard format. On Jan 19, 2012, at 16:29 , Jukka K. Korpela wrote: > 2012-01-20 1:19, David Singer wrote: > >> What the user enters and sees on screen is a presentational/locale issue > > Which one? “Presentational” normally refers to things like layout design, > colors, fonts, and borders. Locales are something different. > > The difference between “1.005” meaning one thousand and five vs. one and five > thousandths is normally regarded as a locale difference, and nobody has > suggested that that it should be handled in CSS when it is about document > content. > > Why would things suddenly change when it comes to user interface? Besides, > there is nothing in CSS as currently defined that even tries to address such > issues. > > Yucca > David Singer Multimedia and Software Standards, Apple Inc.
Re: [whatwg] Decimal comma in numeric input
On Jan 19, 2012, at 13:35 , Bronislav Klučka wrote: > > > On 19.1.2012 21:51, John Tamplin wrote: >> On Thu, Jan 19, 2012 at 3:38 PM, Ian Hickson wrote: >> >>>>> On Thu, 14 Apr 2011, John Tamplin wrote: >>>>> Indeed. To solve this, we need help from CSS. That's one of the reasons >>>>> we created in HTML. >>>> This is about data representation and localization, not about optional >>>> stylistic suggestions, so CSS is a wrong way to deal with the issue. >>> I disagree. It's entirely a presentational issue. It's almost the >>> _definition_ of a presentational issue. >> >> I still disagree -- a user types "1,575" in a field. Is that interpreted >> as a value between 1 and 2 or between 1000 and 2000? Interpretation of the >> value entered by the user has nothing to do with CSS. >> > > This should depend on selected locale, is coma thousands or decimal > separator? Browser should follow such settings and display value accordingly, > but value MUST be sent to server according to 1 set of rules, regardless of > anything else (e.g. no thousands separator and full stop as decimal > separator). No browser locale, no server locale... one set of rules. > Consider JavaScript here... regardless of displayed value, you always get > Number type out of it (not string like 15.123,55 but 15123.55) > So it is just display here, but spec should explain the difference between > display value and underlying data. Yes. What the user enters and sees on screen is a presentational/locale issue mediated by the browser etc. What an API returns, a form sends, etc., when it is a number in string format, should be fixed. David Singer Multimedia and Software Standards, Apple Inc.
Re: [whatwg] WebVTT feedback (and some other feedback that snuck in)
It is also useful for the case where you are given a VTT file and have to write the HTML. It's nice not to have to work out aka guess the srclang tag value. Dave Singer (iPhone) On Dec 2, 2011, at 21:22, Christopher Giffard wrote: > I believe an in-file language tag would be important for situations where the > file isn't being rendered/parsed by a browser user agent - it could be used > offline in VLC or a similar application. > > Kind Regards, > > Christopher Giffard > > On 03/12/2011, at 12:45 AM, Simon Pieters wrote: > >> On Fri, 02 Dec 2011 14:38:13 +0100, David Singer wrote: >> >>> >>> On Dec 2, 2011, at 11:58 , Simon Pieters wrote: >>> >>>> On Fri, 02 Dec 2011 01:34:15 +0100, Ian Hickson wrote: >>>> >>>>> If we are to add language information to the language, there's four ways >>>>> to do it: inline, cue-level, block-level (a section of the file, e.g. >>>>> setting a default at different points in the file), and file-level. >>> >>> 5. externally (e.g. a lang tag on the element that embeds the VTT file). >>> (Though this is not exclusive with the above 4, and there is some argument >>> for intrinsic tagging, as it goes with the file) >> >> This already exists. >> >> -- >> Simon Pieters >> Opera Software >> >
Re: [whatwg] WebVTT feedback (and some other feedback that snuck in)
On Dec 2, 2011, at 11:58 , Simon Pieters wrote: > On Fri, 02 Dec 2011 01:34:15 +0100, Ian Hickson wrote: > >> If we are to add language information to the language, there's four ways >> to do it: inline, cue-level, block-level (a section of the file, e.g. >> setting a default at different points in the file), and file-level. 5. externally (e.g. a lang tag on the element that embeds the VTT file). (Though this is not exclusive with the above 4, and there is some argument for intrinsic tagging, as it goes with the file) >> >> Inline would look like this: >> >> WEBVTT >> >> cue id >> 00:00:00.000 --> 00:00:01.000 >> cue text says bonjour >> >> File-level would look like this: >> >> WEBVTT >> language: fr > > Experience with
Re: [whatwg] WebVTT feedback (and some other feedback that snuck in)
I guess I may be confused. I see two ways of rendering VTT (at least): 1) the UA interprets only VTT, and chooses 'suitable' fonts etc. 2) the UA interprets VTT with class markups and an associated CSS style sheet or sheets, and the author and the UA between them can go hog wild. In case (2), you get to use any fancy (preferably legible :-)) font you like, if the UA is willing to support it. Does this not satisfy? David Singer Multimedia and Software Standards, Apple Inc.
Re: [whatwg] SRT research: timestamps
On Oct 5, 2011, at 16:36 , Glenn Maynard wrote: > On Wed, Oct 5, 2011 at 7:17 PM, David Singer wrote: > which rather raises the question of how many people will write comma instead > of dot in VTT, given a european view or SRT habits. > > If the files don't work in VTT in any major implementation, then probably not > many. It's the fault of overly-lenient parsers that these things happen in > the first place. I rather expect that there may be people tempted to write an implementation that will ingest SRT and VTT, and unify their parsing to cope with either. "Be strict with what you produce, and liberal with what you accept" is a maxim for at least some people, also. And being strict with HTML (I seem to recall that one of the features of XHTML was that nothing was supposed to show when documents had errors) didn't get a lot of traction, either. David Singer Multimedia and Software Standards, Apple Inc.
Re: [whatwg] SRT research: timestamps
On Oct 5, 2011, at 14:07 , Silvia Pfeiffer wrote: > On Thu, Oct 6, 2011 at 4:22 AM, Simon Pieters wrote: >> The most common error is to use a dot instead of a comma. > > They're WebVTT files already. ;-) > which rather raises the question of how many people will write comma instead of dot in VTT, given a european view or SRT habits. David Singer Multimedia and Software Standards, Apple Inc.
Re: [whatwg] ...
On May 13, 2011, at 4:35 , Philip Jägenstedt wrote: > > I wasn't asking how to work around the problem once you know it exists, I was > wondering if any browser vendors have done anything to make this problem less > likely to happen on pages like http://html5demos.com/video that don't do the > right thing? > I am not sure what there is to do. This is pretty much the same as setting a 7am alarm call, after 7am, after all. The only thing I can think of is a general change to HTML, and it's pretty major, to do away with "delta function" events, and instead have handlers triggered by changes in state. Then, you ask "tell me when state X becomes true" instead of "tell me when X happens", and the system can say "it already is true, dummy" when you register the event. This is not a ... small ... change to HTML. And the problem is not unique to video. David Singer Multimedia and Software Standards, Apple Inc.
Re: [whatwg] CSS5 anyone? Or a WHATWG CSS3 Working Group would be cool too
You could help the CSS group move faster? They (we) are nice people, with a large list of things to work on. There's even a public mailing list. If you have ideas, they are pretty open to them, also. Before you give up, I'd give them a try. On Mar 19, 2011, at 6:06 , Martin Alterisio wrote: > I hope I'm not stepping on a tabooed topic here... It's just that I wish > that someone would do to CSS what you guys did to HTML. > > I respect the work being done by the W3C CSS Working Group but it just > doesn't fell enough. It doesn't feel open enough, nor fast enough. > > I really want to see a version of CSS where the language provides a > straightforward solution to layout rather than a challenge. But I don't see > it happening with just the efforts and the current structure that supports > CSS development. > > Is there anything that can be done about this? David Singer Multimedia and Software Standards, Apple Inc.
Re: [whatwg] Limiting the amount of downloaded but not watched video
On Jan 23, 2011, at 21:40 , Glenn Maynard wrote: > > The most important unresolved use case is: how to allow limiting the amount > of prebuffered data, while also having a mechanism to disable that limit > when there isn't enough bandwidth. The problem isn't so much the lack of bandwidth, as the common-ness of bandwidth variability. Essentially, UAs buffer as much as possible "against a rainy day" -- in case that soon the bandwidth drops (or goes away completely). As we have explored, this is clearly the place to be if you want the best user experience. Users also like it because such a model allows them to buffer-and-wait for content that is coded at a rate above the average bandwidth they experience. David Singer Multimedia and Software Standards, Apple Inc.
Re: [whatwg] Limiting the amount of downloaded but not watched video
When the HTML5 states were first proposed, I went through a careful exercise to make sure that they were reasonably delivery-technology neutral, i.e. that they applied equally well if say RTSP/RTP was used, some kind of dynamic streaming, simple HTTP, and so on. I am concerned that we all tend to assume that HTML==HTTP, but the source URL for the media might have any protocol type, and the HTML attributes, states etc. should apply (or clearly not apply) to anything. Assuming only HTTP, in the markup, is not a good direction. On Jan 21, 2011, at 9:22 , Zachary Ozer wrote: > We never make any promises about when we'll get something into an > official release, but I think we'd start playing around with it in our > development version once a reference implementation was publicly > available. > -- > Zachary Ozer > Developer, LongTail Video > > w: longtailvideo.com • e: z...@longtailvideo.com • p: 212.244.0140 • > f: 212.656.1335 > JW Player | Bits on the Run | AdSolution > > > > On Thu, Jan 20, 2011 at 7:03 PM, Roger Hågensen wrote: >> On 2011-01-20 19:16, Zachary Ozer wrote: >>> >>> == New Proposal == >> >> I like this. It seems you laid out everything to ensure a balanced buffer, >> kinda like a moving window buffer which I pointed out earlier. >> So as far as I can see, your proposal looks pretty solid, unless there are >> any implementation snafus. (looks at the Chrome, Safari, Opera, Firefox guys >> in the list (hmm, where's the IE guys?)) >> I really like the way you described the "state3", and I think that would be >> my personal preference for playback myself. I assume JW player would be very >> quick at supporting/using it? >> >> -- >> Roger "Rescator" Hågensen. >> Freelancer - http://www.EmSai.net/ >> >> David Singer Multimedia and Software Standards, Apple Inc.
Re: [whatwg] Limiting the amount of downloaded but not watched video
On Jan 18, 2011, at 16:16 , Glenn Maynard wrote:
> On Tue, Jan 18, 2011 at 6:54 PM, David Singer wrote:
>
>> I feel like we are asking this question at the wrong protocol level.
>>
>> If you use the HTML5 video tag, you indicate the resource and the protocol
>> used to get it, in a URL.
>>
>> If you indicate a download protocol, you can hardly be surprised if, well,
>> download happens.
>>
>
> HTTP isn't a "download protocol"--I'm not really sure what that means--it's
> a transfer protocol. Nothing about HTTP prevents capping prebuffering, and
> nothing about an HTTP URL implies that the entire resource needs to be
> downloaded.
>
> This setting is relevant for any protocol, whether it's a generic one like
> HTTP or one designed for streaming video. This isn't a discussion about
> HTTP; it's one about an interface to control prebuffering, regardless of the
> underlying protocol. I havn't seen it suggested that any difficulty of
> doing this is due to HTTP. If you think it is, it'd be helpful to explain
> further.
I'm sorry, perhaps that was a shorthand.
In RTSP-controlled RTP, there is a tight relationship between the play point,
and play state, the protocol state (delivering data or paused) and the data
delivered (it is delivered in precisely real-time, and played and discarded
shortly after playing). The server delivers very little more data than is
actually watched.
In HTTP, however, the entire resource is offered to the client, and there is no
protocol to convey play/paused back to the server, and the typical behavior
when offered a resource in HTTP is to make a simple binary decision to either
load it (all) or not load it (at all). So, by providing a media resource over
HTTP, the server should kinda be expecting this 'download' behavior.
Not only that, but if my client downloads as much as possible as soon as
possible and caches as much as possible, and yours downloads as little as
possible as late as possible, you may get brownie points from the server owner,
but I get brownie points from my local user -- the person I want to please if I
am a browser vendor. There is every incentive to be resilient and 'burn'
bandwidth to achieve a better user experience.
Servers are at liberty to apply a 'throttle' to the supply, of course
("download as fast as you like at first, but after a while I'll only supply at
roughly the media rate"). They can suggest that the client be a little less
aggressive in buffering, but it's easily ignored and the incentive is to ignore
it.
So I tend to return to "if you want more tightly-coupled behavior, use a more
tightly-coupled protocol"...
David Singer
Multimedia and Software Standards, Apple Inc.
Re: [whatwg] Limiting the amount of downloaded but not watched video
On Jan 18, 2011, at 5:40 , Boris Zbarsky wrote: > On 1/18/11 6:09 AM, Glenn Maynard wrote: >> I'm confused--how is the required buffer size a function of the length of >> the video? Once the buffer is large enough to smooth out network >> fluctuations, either you have the bandwidth to stream the video or you >> don't; the length of the video doesn't enter into it. > > The point is that many users _don't_ have enough bandwidth to stream the > video. At that point, the size of the buffer that puts you in > HAVE_ENOUGH_DATA depends on the length of the video. > It certainly used to be true that many users of Apple's trailers site would deliberately choose higher quality (and hence bandwidth) trailers than they could download in realtime. David Singer Multimedia and Software Standards, Apple Inc.
Re: [whatwg] Limiting the amount of downloaded but not watched video
I feel like we are asking this question at the wrong protocol level. If you use the HTML5 video tag, you indicate the resource and the protocol used to get it, in a URL. If you indicate a download protocol, you can hardly be surprised if, well, download happens. If you want a more tightly coupled supply/consume protocol, then use one. As long as it's implemented by client and server, you're on. Note that the current move of the web towards download in general and HTTP in particular is due in no small part to the fact that getting more tightly coupled protocols -- actually, any protocol other than HTTP -- out of content servers, across firewalls, through NATs, and into clients is...still a nightmare. So, we've been given a strong incentive by all those to use HTTP. It's sad that some of them are not happy with that result, but it's going to be hard to change now. David Singer Multimedia and Software Standards, Apple Inc.
Re: [whatwg] HTML5 video: frame accuracy / SMPTE
OK, but it does seem kinda a tautology if you say "I want to use a time-expression that represents fractions of seconds as frame numbers, and it's not very accurate if there aren't very many frames/second..." ! On Jan 11, 2011, at 23:40 , Rob Coenen wrote: > Hi David- that is b/c in an ideal world I'd want to seek to a time expressed > as a SMPTE timecode (think web apps that let users step x frames back, seek y > frames forward etc.). In order to convert SMPTE to the floating point value > for video.seekTime I need to know the frame rate. > > -Rob > > On Tue, Jan 11, 2011 at 10:35 PM, David Singer wrote: > why does the frame rate make any difference on the accuracy of seeking to a > time? Imagine a video that runs at 1 frame every 10 seconds, and I seek to > 25 seconds. I would expect to see 5 seconds of the third frame, 10 seconds > of the 4th, and so on. > > On Jan 11, 2011, at 18:54 , Rob Coenen wrote: > > > just a follow up question in relation to SMPTE / frame accurate playback: As > > far as I can tell there is nothing specified in the HTML5 specs that will > > allow us to determine the actual frame rate (FPS) of a movie? In order to do > > proper time-code calculations it's essential to know both the video.duration > > and video.fps - and all I can find in the specs is video.duration, nothing > > in video.fps > > > > -Rob > > > > > > On Mon, Jan 10, 2011 at 9:32 PM, Kevin Marks wrote: > > > >> If you really want to test timecode, you need to get into SMPTE drop-frame > >> timecode too (possibly the single most annoying standards decision of. all > >> time was choosing 3/1001 as the framerate of NTSC video) > >> > >> Eric, can you make BipBop movie for this? - Like the ones used in this > >> demo: > >> > >> > >> http://developer.apple.com/library/mac/#documentation/NetworkingInternet/Conceptual/StreamingMediaGuide/UsingHTTPLiveStreaming/UsingHTTPLiveStreaming.html > >> > >> http://devimages.apple.com/iphone/samples/bipbopgear3.html > >> > >> > >> On Mon, Jan 10, 2011 at 11:18 AM, Rob Coenen wrote: > >> > >>> Thanks for the update. > >>> I have been testing with WebKit nightly / 75294 on MacOSX 10.6.6 / 13" > >>> Macbook Pro, Core Duo. > >>> > >>> Here's a test movie that I created a while back. Nevermind the video > >>> quality- the burned-in timecodes are 100% correct, I have verified this by > >>> exploring each single frame by hand. > >>> > >>> > >>> http://www.massive-interactive.nl/html5_video/transcoded_03_30_TC_sec_ReviewTest.mp4 > >>> > >>> Please let me know once you guys have downloaded the file, I like to > >>> remove > >>> it from my el-cheapo hosting account ASAP. > >>> > >>> thanks, > >>> > >>> Rob > >>> > >>> > >>> On Mon, Jan 10, 2011 at 2:54 PM, Eric Carlson >>>> wrote: > >>> > >>>> > >>>> On Jan 9, 2011, at 11:14 AM, Rob Coenen wrote: > >>>> > >>>> I have written a simple test using a H264 video with burned-in timecode > >>>> (every frame is visually marked with the actual SMPTE timecode) > >>>> Webkit is unable to seek to the correct timecode using 'currentTime', > >>> it's > >>>> always a whole bunch of frames off from the requested position. I reckon > >>> it > >>>> simply seeks to the nearest keyframe? > >>>> > >>>> WebKit's HTMLMediaElement implementation uses different media engines > >>> on > >>>> different platforms (eg. QuickTime, QTKit, GStreamer, etc). Each media > >>>> engine has somewhat different playback characteristics so it is > >>> impossible > >>>> to say what you are experiencing without more information. Please file a > >>> bug > >>>> report at https://bugs.webkit.org/ with your test page and video file, > >>> and > >>>> someone will look into it. > >>>> > >>>> eric > >>>> > >>>> > >>> > >> > >> > > David Singer > Multimedia and Software Standards, Apple Inc. > > David Singer Multimedia and Software Standards, Apple Inc.
Re: [whatwg] HTML5 video: frame accuracy / SMPTE
why does the frame rate make any difference on the accuracy of seeking to a time? Imagine a video that runs at 1 frame every 10 seconds, and I seek to 25 seconds. I would expect to see 5 seconds of the third frame, 10 seconds of the 4th, and so on. On Jan 11, 2011, at 18:54 , Rob Coenen wrote: > just a follow up question in relation to SMPTE / frame accurate playback: As > far as I can tell there is nothing specified in the HTML5 specs that will > allow us to determine the actual frame rate (FPS) of a movie? In order to do > proper time-code calculations it's essential to know both the video.duration > and video.fps - and all I can find in the specs is video.duration, nothing > in video.fps > > -Rob > > > On Mon, Jan 10, 2011 at 9:32 PM, Kevin Marks wrote: > >> If you really want to test timecode, you need to get into SMPTE drop-frame >> timecode too (possibly the single most annoying standards decision of. all >> time was choosing 3/1001 as the framerate of NTSC video) >> >> Eric, can you make BipBop movie for this? - Like the ones used in this >> demo: >> >> >> http://developer.apple.com/library/mac/#documentation/NetworkingInternet/Conceptual/StreamingMediaGuide/UsingHTTPLiveStreaming/UsingHTTPLiveStreaming.html >> >> http://devimages.apple.com/iphone/samples/bipbopgear3.html >> >> >> On Mon, Jan 10, 2011 at 11:18 AM, Rob Coenen wrote: >> >>> Thanks for the update. >>> I have been testing with WebKit nightly / 75294 on MacOSX 10.6.6 / 13" >>> Macbook Pro, Core Duo. >>> >>> Here's a test movie that I created a while back. Nevermind the video >>> quality- the burned-in timecodes are 100% correct, I have verified this by >>> exploring each single frame by hand. >>> >>> >>> http://www.massive-interactive.nl/html5_video/transcoded_03_30_TC_sec_ReviewTest.mp4 >>> >>> Please let me know once you guys have downloaded the file, I like to >>> remove >>> it from my el-cheapo hosting account ASAP. >>> >>> thanks, >>> >>> Rob >>> >>> >>> On Mon, Jan 10, 2011 at 2:54 PM, Eric Carlson >>> wrote: >>> >>>> >>>> On Jan 9, 2011, at 11:14 AM, Rob Coenen wrote: >>>> >>>> I have written a simple test using a H264 video with burned-in timecode >>>> (every frame is visually marked with the actual SMPTE timecode) >>>> Webkit is unable to seek to the correct timecode using 'currentTime', >>> it's >>>> always a whole bunch of frames off from the requested position. I reckon >>> it >>>> simply seeks to the nearest keyframe? >>>> >>>> WebKit's HTMLMediaElement implementation uses different media engines >>> on >>>> different platforms (eg. QuickTime, QTKit, GStreamer, etc). Each media >>>> engine has somewhat different playback characteristics so it is >>> impossible >>>> to say what you are experiencing without more information. Please file a >>> bug >>>> report at https://bugs.webkit.org/ with your test page and video file, >>> and >>>> someone will look into it. >>>> >>>> eric >>>> >>>> >>> >> >> David Singer Multimedia and Software Standards, Apple Inc.
Re: [whatwg] Html 5 video element's poster attribute
x27;ve seen justify such complexity. >> >> >> On Mon, 20 Sep 2010, Chris Pearce wrote: >> > >> > Showing the poster at the end of playback is a matte... >> >> I think this would make sense if we see evidence that authors actually >> want this behaviour (e.g. they go out of their way to implement it). Do we >> see such evidence in Flash players, for instance? >> >> >> On Mon, 20 Sep 2010, Shiv Kumar wrote: >> > >> > I’ve explained earlier that that’s not a solution. In ... >> >> > Of course we wouldn’t want the user to see the poster during the time >> > it takes to switch so we ... >> >> That seems reasonable. You can also just use another element and >> fade it in over the top and then remove the old one. >> >> >> > In my mind, “load()” does not imply that the poster should also >> > show. The video stream and po... >> >> They're not independent. They're part of the same element. >> >> load() just tells the element to restart. load() is implicitly >> called when you create the element, it's what makes the video >> load in the first place. It makes sense that it would reset the playback >> position, poster, etc. >> >> >> > The other aspect is that the url to the video changes frequently (in >> > order to prevent bandwid... >> >> Using a changing URL to avoid someone referencing your video doesn't seem >> like an especially good design. I don't think we should optimise the spec >> to support such a design. >> >> >> > I fail to see why we can’t simply have a way to turn on the poster >> > without impacting anything... >> >> I'm not sure I agree with this premise. >> >> >> [I've snipped a number of e-mails repeating the same arguments with no new >> information -- please note that repeating arguments doesn't help!] >> >> >> On Tue, 21 Sep 2010, Silvia Pfeiffer wrote: >> > >> > I don't think you understand what load() does. It certainly does not >> > replace >> > a currently playing resource with a new one without glitches. When you load >> > a new resource, you ... >> >> The latter sounds like a bug. load() should set /paused/ to true per spec. >> >> >> On Tue, 21 Sep 2010, Shiv Kumar wrote: >> > >> > Can you give me a good reason/case for not having a si... >> >> That's not how standardisation works. We don't add all the features for >> which we can't find compelling arguments _against_, we only add features >> for which we can find compelling arguments _for_. Compelling arguments >> usually come in the form of use cases (e.g. large numbers of sites that >> are working around the lack of a feature), or compatibility (e.g. lots >> of browsers doing something). >> >> -- >> Ian Hickson U+1047E)\._.,--,'``.fL >> http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. >> Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' > David Singer Multimedia and Software Standards, Apple Inc.
Re: [whatwg] Bluetooth devices
On Dec 2, 2010, at 6:00 , Diogo Resende wrote: > I don't think Don was talking about mouse/kb/video/gps stuff. That > should be handled by the OS and reflected to the current APIs as wired > alternatives do. I think Don meant to be able to scan other types of > devices and be able to interact with them. > > For example, a medical device may have no interest to the OS but a web > app (just like a desktop app) could get some interesting information and > perhaps send some instructions. Maybe some API like the geolocation.. > But there is still a whole OS, and a piece of hardware (the bluetooth chip) between the browser and the bluetooth device. If the OS considers the device 'visible' or 'connected' then it's available to the browser. It doesn't matter what the means of connection is. If you're suggesting that we should have ways of browsing what devices/services you *might* connect to (the equivalent of the panels that OSes offer to set up pairing), on Bluetooth (or, I guess, the network), that raises a whole host of questions and issues. So I still think, if the OS thinks you can talk to it (it's paired or connected), the fact that Bluetooth is the 'wire' is irrelevant. If the OS does *not* think it's connected, then you're talking about establishing connectivity through some kind of browser/web-mediated interaction. David Singer Multimedia and Software Standards, Apple Inc.
Re: [whatwg] Bluetooth devices
I would repeat, that I think the form of the (logical) wire between the browser and the device is out of scope, and that (effectively) we *do* provide access to bluetooth devices. Heck, my bluetooth keyboard and mouse work today. Connect the devices however you like, we don't care. On Nov 30, 2010, at 15:01 , Ian Hickson wrote: > On Mon, 16 Aug 2010, Don Rosen wrote: >> >> Is there any intention to provide access to Bluetooth devices through >> the Device element? > > Not currently, but it might make sense in the future. The best way to move > forward with such a proposal would be to have an experimental > implementation show that it is possible, show that it can be done in a > secure fashion, show what a reasonable API for it would be, and show that > there is author demand for the feature. > > -- > Ian Hickson U+1047E)\._.,--,'``.fL > http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' David Singer Multimedia and Software Standards, Apple Inc.
Re: [whatwg] Autoplaying media elements not in a document
OK, you are right. If a script wants to annoy me, it can. And boy, do some web designers not know how annoying that can be :-( On Oct 18, 2010, at 16:59 , Robert O'Callahan wrote: > On Tue, Oct 19, 2010 at 12:57 PM, David Singer wrote: > isn't autoplaying a media element over which the user may well have no > control (unless the page offers a script to control it), inappropriate? > > Maybe, but elements not in a document can only be created by script in the > first place. If script wants to have a disconnected autoplay element, why not > let it? If it wants to be annoying it can just call play(). > > Rob > -- > "Now the Bereans were of more noble character than the Thessalonians, for > they received the message with great eagerness and examined the Scriptures > every day to see if what Paul said was true." [Acts 17:11] David Singer Multimedia and Software Standards, Apple Inc.
Re: [whatwg] Autoplaying media elements not in a document
isn't autoplaying a media element over which the user may well have no control (unless the page offers a script to control it), inappropriate? David Singer Multimedia and Software Standards, Apple Inc.
Re: [whatwg] Live video streaming with html5.
In HTML5, a URL (or a set of URLs) point at what you want the user-agent to display. From the spec's point of view, you can insert any protocol (that can be described by a URL) in there. You'll need it to be supported by your user-agent, of course. On Sep 21, 2010, at 12:15 , Pedro Fernandes Steimbruch wrote: > I don't know if it might be a noob question, maybe becouse I am noob. hehe > > I work in a company that do live video streaming. We are using the rtmp > protocol to do this streaming. My question is about how HTML5 handles > streaming. Is there already a specific solution in HTML5 for this kind of > streaming? > > Thank you! David Singer Multimedia and Software Standards, Apple Inc.
Re: [whatwg] Video with MIME type application/octet-stream
On Sep 9, 2010, at 16:38 , Andy Berkheimer wrote: > Much of this discussion has focused on the careless server operator. What > about the careful ones? > > Given the past history of content sniffing and security warts, it is useful - > or at least comforting - to have a path for the careful server to indicate "I > know this file really is intended to be handled as this type, please don't > sniff it". This is particularly true for a server handling sanitized files > from unknown sources, as no sanitizer will be perfect. > > Today we approximate this through accurate use of Content-Type and a recent > addition of X-Content-Type-Options: nosniff. > > Never sniffing sounds idyllic and always sniffing makes life a bit riskier > for careful server operators. The proposals of limiting video/audio sniffing > to a few troublesome Content-Types are quite reasonable. I think I agree. The minimum I can think of is sniff when (a) suspect types are supplied and (b) they are 'auto-generated' (e.g. by a web server). If either are not true, you shouldn't need to sniff. Someone who writes causes both tests to fail and deserves to be believed (and get the consequences). (Have you SEEN frubotziger format video :-)) > > -Andy > > On Thu, Sep 9, 2010 at 3:07 AM, Philip Jägenstedt wrote: > I think we should always sniff or never sniff, for simplicity. > > Philip David Singer Multimedia and Software Standards, Apple Inc.
Re: [whatwg] Video with MIME type application/octet-stream
I can't think why always sniffing is simple, or cheap, or desirable. I'd love to get to never-sniff, but am not sanguine. On Sep 9, 2010, at 0:07 , Philip Jägenstedt wrote: > I think we should always sniff or never sniff, for simplicity. > > Philip > > On Wed, 08 Sep 2010 19:14:48 +0200, David Singer wrote: > >> what about "don't sniff if the HTML gave you a mime type" (i.e. a source >> element with a type attribute), or at least "don't sniff for the purposes of >> determining CanPlay, dispatch, if the HTML source gave you a mime type"? >> >> >> On Sep 8, 2010, at 2:33 , Philip Jägenstedt wrote: >> >>> On Tue, 07 Sep 2010 22:00:55 +0200, Boris Zbarsky wrote: >>> >>>> On 9/7/10 3:29 PM, Aryeh Gregor wrote: >>>>> * Sniff only if Content-Type is typical of what popular browsers serve >>>>> for unrecognized filetypes. E.g., only for no Content-Type, >>>>> text/plain, or application/octet-stream, and only if the encoding is >>>>> either not present or is UTF-8 or ISO-8859-1. Or whatever web servers >>>>> do here. >>>>> * Sniff the same both for video tags and top-level browsing contexts, >>>>> so "open video in new tab" doesn't mysteriously fail on some setups. >>>> >>>> I could probably live with those, actually. >>>> >>>>> * If a file in a top-level browsing context is sniffed as video but >>>>> then some kind of error is returned before the video plays the first >>>>> frame, fall back to allowing the user to download it, or whatever the >>>>> usual action would be if no sniffing had occurred. >>>> >>>> This might be pretty difficult to implement, since the video decoder might >>>> consume arbitrary amounts of data before saying that there was an error. >>> >>> I agree with Boris, the first two points are OK but the third I'd rather >>> not implement, it's too much work for something that ought to happen very, >>> very rarely. >>> >>> -- >>> Philip Jägenstedt >>> Core Developer >>> Opera Software >> >> David Singer >> Multimedia and Software Standards, Apple Inc. >> > > > -- > Philip Jägenstedt > Core Developer > Opera Software David Singer Multimedia and Software Standards, Apple Inc.
Re: [whatwg] Video with MIME type application/octet-stream
On Sep 8, 2010, at 12:58 , Aryeh Gregor wrote: > > On Wed, Sep 8, 2010 at 1:14 PM, David Singer wrote: >> what about "don't sniff if the HTML gave you a mime type" (i.e. a source >> element with a type attribute), or at least "don't sniff for the purposes of >> determining CanPlay, dispatch, if the HTML source gave you a mime type"? > > What advantage does this serve? It both significantly reduces the footprint of sniffing (knocks out a whole load of cases), and clarifies that 'canplay' decisions don't need to sniff (so you don't sniff a whole bunch of different files). 'Non-configured servers' is a valid excuse for HTTP content-type being wrong (for a few cases), but I can't think of any reason to disbelieve the page author, can you? > > On Wed, Sep 8, 2010 at 3:13 PM, And Clover wrote: >> Perhaps I *meant* to serve a non-video >> file with something that looks a fingerprint from a video format at the top. > > Anything's possible, but it's vastly more likely that you just made a mistake. It may be possible to make one file that is valid under two formats. Kinda like those old competitions "write a single file that when compiled and run through as many languages as possible prints "hello, world!" :-). David Singer Multimedia and Software Standards, Apple Inc.
Re: [whatwg] Video with MIME type application/octet-stream
what about "don't sniff if the HTML gave you a mime type" (i.e. a source element with a type attribute), or at least "don't sniff for the purposes of determining CanPlay, dispatch, if the HTML source gave you a mime type"? On Sep 8, 2010, at 2:33 , Philip Jägenstedt wrote: > On Tue, 07 Sep 2010 22:00:55 +0200, Boris Zbarsky wrote: > >> On 9/7/10 3:29 PM, Aryeh Gregor wrote: >>> * Sniff only if Content-Type is typical of what popular browsers serve >>> for unrecognized filetypes. E.g., only for no Content-Type, >>> text/plain, or application/octet-stream, and only if the encoding is >>> either not present or is UTF-8 or ISO-8859-1. Or whatever web servers >>> do here. >>> * Sniff the same both for video tags and top-level browsing contexts, >>> so "open video in new tab" doesn't mysteriously fail on some setups. >> >> I could probably live with those, actually. >> >>> * If a file in a top-level browsing context is sniffed as video but >>> then some kind of error is returned before the video plays the first >>> frame, fall back to allowing the user to download it, or whatever the >>> usual action would be if no sniffing had occurred. >> >> This might be pretty difficult to implement, since the video decoder might >> consume arbitrary amounts of data before saying that there was an error. > > I agree with Boris, the first two points are OK but the third I'd rather not > implement, it's too much work for something that ought to happen very, very > rarely. > > -- > Philip Jägenstedt > Core Developer > Opera Software David Singer Multimedia and Software Standards, Apple Inc.
Re: [whatwg] Video with MIME type application/octet-stream
And like I said before, please be careful of assuming our intent and desires from the way things currently work. We are thinking, listening, and implementing (and fixing bugs, and re-inspecting older behavior in lower-level code), so there is some...flexibility...I think. On Sep 7, 2010, at 9:12 , Maciej Stachowiak wrote: > > On Sep 7, 2010, at 3:52 AM, Philip Jägenstedt wrote: > >> On Tue, 07 Sep 2010 11:51:55 +0200, And Clover wrote: >> >>> On 09/07/2010 03:56 AM, Boris Zbarsky wrote: >>> >>>> P.S. Sniffing is harder that you seem to think. It really is... >>> >>> Quite. It surprises and saddens me that anyone wants to argue for *more* >>> sniffing, and even enshrining it in a web standard. >> >> IE9, Safari and Chrome ignore Content-Type in a context and rely on >> sniffing. If you want Content-Type to be respected, convince the developers >> of those 3 browsers to change. If not, it's quite inevitable that Opera and >> Firefox will eventually have to follow. > > At least in the case of Safari, we initially added sniffing for the benefit > of video types likely to be played with the QuickTime plugin - mainly .mov > and various flavors of MPEG. It is common for these to be served with an > incorrect MIME type. And we did not want to impose a high transition cost on > content already being served via the QuickTime plugin. The QuickTime plugin > may be a slightly less relevant consideration now than when we first thought > about this, but at this point it is possible content has been migrated to > while still carrying broken MIME types. > > Ogg and WebM are probably not yet poisoned by a mass of unlabeled data. It > might be possible to treat those types more strictly - i.e. only play Ogg or > WebM when labeled as such, and not ever sniff content with those MIME types > as anything else. > > In Safari's case this would have limited impact since a non-default codec > plugin would need to be installed to play either Ogg or WebM. I'm also not > sure it's sensible to have varying levels of strictness for different types. > But it's an option, if we want to go there. > > Regards, > Maciej > David Singer Multimedia and Software Standards, Apple Inc.
Re: [whatwg] Video with MIME type application/octet-stream
On Sep 7, 2010, at 2:51 , And Clover wrote: > On 09/07/2010 03:56 AM, Boris Zbarsky wrote: > >> P.S. Sniffing is harder that you seem to think. It really is... > > Quite. It surprises and saddens me that anyone wants to argue for *more* > sniffing, and even enshrining it in a web standard. Yes. We should be striving for a world in which as little sniffing as possible happens (and is needed). Basically, we have the problem because of mis-configured or (from the author's point of view) unconfigurable web servers. So I wonder if * the presence of a element with a "type" attribute should be believed (at least for the purposes of dispatch and 'canplay' decisions)? If the author of the page got it wrong or lied, surely they can accept (and deal with) the consequences? * whether we should only really sniff the two types in HTTP headers that tend to get used as fallbacks (application/octet-stream and text/plain)? Though I note that I have sometimes *wanted* a file displayed as text (and not interpreted) and been defeated by sniffing (though not as often as watching binary dumped on my screen as if it were text). David Singer Multimedia and Software Standards, Apple Inc.
Re: [whatwg] default audio upload format (was Fwd: The Media Capture API Working Draft)
I agree that if the server says it accepts something, then it should cover at least the obvious bases, and transcoding at the server side is not very hard. However, I do think tht there needs to be some way to protect the server (and user, in fact) from mistakes etc. If the server was hoping for up to 10 seconds of 8kHz mono voice to use as a security voice-print, and the UA doesn't cut off at 10 seconds, records at 48 Khz stereo, and the user forgets to hit 'stop', quite a few systems might be surprised (and maybe charge for) the size of the resulting file. It's also a pain at the server to have to sample-rate convert, downsample to mono, and so on, if the terminal could do it. On Sep 3, 2010, at 14:08 , Roger Hågensen wrote: > On 2010-09-01 21:34, David Singer wrote: >> seems like a comma-separated list is the right way to go, and that audio/* >> should mean what it says -- any kind of audio (whether that is useful or not >> remains to be seen). >> >> I would suggest that this is likely to be used for short captures, and that >> uncompressed (such as a WAV file or AVI with PCM or u-law audio) should be >> the recommended format. >> >> If your usage is for longer captures or more specific situations, then >> indicate a suitable codec. >> >> Shouldn't there be statements about channels (mono, stereo, more), sampling >> rate (8 kHz speech, 16 kHz wideband speech, 44.1 CD-quality, 96 kHz >> bat-quality) and so on? >> > > Hmm! Channels, bits, frequency should be optional in my opinion, (and with a > recommendation for a default, stereo 16bit 44.1KHz which is the legacy > standard for audio in most formats I guess, or maybe 48KHz as most soundcards > seem to be these days?) > In most cases a service will either A. use it as it's received (since most > computer systems can play back pretty much anything), or B. it's > transcoded/converted into one or more formats by the service. (like Youtube > does etc.) > In other words I am assuming that if the server accept for example the WAV > format then it actually fully support the WAV format (at least the PCM audio > part). Ditto with MP3, AAC, Ogg, FLAC, Speex etc. > > So any quality, channels, bits, frequency specified in the accept would just > be what the server prefers (suggested default, or for best quality/best > effort scenario), but the full format should be supported and accepted if > asked for. > Now whether the service takes advantage of surround rear recording is up to > the service, if it simply discards that, takes the front channels and mix > them to mono then that is up to the service and the user to decide/negotiate > about rather than the browser. > > -- > Roger "Rescator" Hågensen. > Freelancer - http://EmSai.net/ > David Singer Multimedia and Software Standards, Apple Inc.
Re: [whatwg] Video with MIME type application/octet-stream
On Sep 3, 2010, at 12:48 , Aryeh Gregor wrote: >> Er... Where did I propose this? I proposed speccing that there MUST NOT be >> any sniffing, with browsers that sniff therefore being nonconformant. I >> didn't propose allowing ad-hoc sniffing. > > Right. But the spec never allowed sniffing, and two browsers do it > anyway. Ian has spoken to those browsers' implementers, and the > browsers have not changed, despite knowing that they aren't following > the spec. Do you have any particular reason to believe that they'll > change? If not, then the situation I described is exactly what your > proposal (i.e., the status quo) will result in, no? > Um, I think that in some cases the code that is supporting video/audio has ... historical artefacts ... which may not be entirely in line with the specs. I think it's dangerous to make assumptions in this area, especially if you then go and ask for a change in a spec. based on assumptions. David Singer Multimedia and Software Standards, Apple Inc.
Re: [whatwg] default audio upload format (was Fwd: The Media Capture API Working Draft)
seems like a comma-separated list is the right way to go, and that audio/* should mean what it says -- any kind of audio (whether that is useful or not remains to be seen). I would suggest that this is likely to be used for short captures, and that uncompressed (such as a WAV file or AVI with PCM or u-law audio) should be the recommended format. If your usage is for longer captures or more specific situations, then indicate a suitable codec. Shouldn't there be statements about channels (mono, stereo, more), sampling rate (8 kHz speech, 16 kHz wideband speech, 44.1 CD-quality, 96 kHz bat-quality) and so on? On Sep 1, 2010, at 8:21 , James Salsman wrote: > On Tue, Aug 31, 2010 at 11:24 PM, Roger Hågensen wrote: >> On 2010-08-31 22:11, James Salsman wrote: >>> >>> Does anyone object to form input type=file >>> accept="audio/*;capture=microphone" using Speex as a default, as if it >>> were specified >>> accept="audio/x-speex;quality=7;bitrate=16000;capture=microphone" or >>> to allowing the requesting of different speex qualities and bitrates >>> using those mime type parameters? >>> >>> Speex at quality=7 is a reasonable open source default audio vocoder. >>> Runner-up alternatives would include audio/ogg, which is a higher >>> bandwidth format appropriate for multiple speakers or polyphonic >>> music; audio/mpeg, a popular but encumbered format; audio/wav, a union >>> of several different sound file formats, some of which are encumbered; >>> etc. >> >> Actually, wouldn't accept="audio/*;capture=microphone" >> basically indicate that the server wish to accept anything as audio? > > Yes; that doesn't encourage implementors to implement. However, as it > was agreed on by two different browser developer representatives, it's > the best way forward. > >> The proper way however would be to do: >> accept="audio/flac, audio/wav, audio/ogg, audio/aac, >> audio/mp3;capture=microphone" >> indicating all the audio formats the server can handle. > > I agree that the specifications should allow a comma- or > space-separated list of MIME types. I have no idea why that was > specifically disallowed in the most recent HTML5 specification, and > think that decision should be reversed before publication. I also > think "capture" would work a lot better as an attribute of the input > type=file element than a MIME type parameter. > >> Although I guess that audio/* could be taken as a sign that the browser >> should negotiate directly with the server about the preferred format to use. >> (Is POST HEADER request supported even?) > > Not for multipart/form-encoded input type=file uploads, sadly. There's > a way to do that specified in http://w3.org/TR/device-upload with the > "alternates" form POST parameter which the browser would send back to > the server when the requested type(s) were unavailable. I guess that > is a content negotiation feature, but it seemed unlikely that people > would need it for that because ideally the server would specify all > the types it could accept, as you pointed out. > > Best regards, > James Salsman David Singer Multimedia and Software Standards, Apple Inc.
Re: [whatwg] Bluetooth devices
I am not sure whether the physical connectivity used has much bearing on what devices are connected and usable, honestly. Why does the 'virtual' wire matter? (USB, serial, Bluetooth, built-in, IEEE4888, )? On Aug 19, 2010, at 14:28 , Bjartur Thorlacius wrote: >> Is there any intention to provide access to Bluetooth devices through the >> Device element? > Addressing Bluetooth specifically might or might not be out of scope > of the element, depending on what the scope will be :) > > This is to low level for my taste; what would a web page want direct > communication over Bluetooth for? If RS-323 will be left out, Bluetooth > probably should be [left out] too. Higher level JavaScript interfaces > for accessing filesystems and user selected audio streams cover all use > cases I can think of. > > But then, I don't fully understand what use cases is trying to > solve in the first place. David Singer Multimedia and Software Standards, Apple Inc.
Re: [whatwg] HTML 5 : The Youtube response
I think it's interesting to look at these and ask to what extent they are in scope. > 1. Standard video format > 2. Robust video streaming > 3. Content Protection > 4. Encapsulation + embedding > 5. Fullscreen video > 6. Camera and Microphone access #1 has been debated a lot. #2 is rather out of scope. The beauty of HTML5 is that it is the presentational layer, and allows you to embed a video of any type (WebM, Ogg, MP4), delivered over any protocol (HTTP, RTSP, ...). There is nothing to stop a reference to a robust stream being the URL in a source element, and I don't think it's the W3C's job to make it happen. 3GPP has already defined a solution, and MPEG is also looking. Open IPTV Forum is basing their work on 3GPP, and others are looking closely at it. #3 is very easy to do if all you want is protection. It's when you multi-vendor systems that nonetheless have the appropriate degree of robustness that you get into problems. But it's like #2; it's below the presentation layer of HTML5. #4 is soluble 'on top of' HTML5 and the media formats, if needed. Web Archives, Web Apps, and so on. I think. #5 is a problem only if you care about phishing attacks...or indeed apps that have the gall to believe that you should be able to see nothing else when they are running. #6 is well, rather different from the problem of delivering a/v to a user. I'm not enthusiastic about web pages that can listen to me or watch me, myself... David Singer Multimedia and Software Standards, Apple Inc.
Re: [whatwg] Timestamp from video source in order to sync (e.g. expose OGG timestamp to javascript)
I think it rather important that the format define "where you are" in time, precisely so that temporal fragments, or syncing with other material, can work. For most video-on-demand, the program starts at zero and runs to its duration. But for 'streaming', knowing 'where you are' in a stream depends on a lot of things. The 3G HTTP streaming solution explicitly anchors the timeline, so that two players playing the same program at the same point in it will see the same time, no matter when they tuned it. On May 18, 2010, at 2:46 , Silvia Pfeiffer wrote: > On Tue, May 18, 2010 at 7:28 PM, Robert O'Callahan > wrote: >> On Tue, May 18, 2010 at 8:23 PM, Odin Omdal Hørthe >> wrote: >>> >>> Justin Dolske's idea looks rather nice: >>>> This seems like a somewhat unfortunate thing for the spec, I bet >>>> everyone's >>>> going to get it wrong because it won't be common. :( I can't help but >>>> wonder if >>>> it would be better to have a startTimeOffset property, so that >>>> .currentTime et >>>> al are all still have a timeline starting from 0, and if you want the >>>> "real" >>>> time you'd use .currentTime + .startTimeOffset. >>>> >>>> I'd also suspect we'll want the default video controls to normalize >>>> everything >>>> to 0 (.currentTime - .startTime), since it would be really confusing >>>> otherwise. >> >> >> That's exactly what I've advocated before. I lost the argument, but I forget >> why, probably because I didn't understand the reasons. > > > To be honest, it doesn't make much sense to display the "wrong" time > in a player. If a video stream starts at 10:30am and goes for 30 min, > then a person joining the stream 10 min in should see a time of 10min > - or better even 10:40am - which is in sync with what others see that > joined at the start. It would be rather confusing if the same position > in a video would be linked by one person as "at offset 10min" while > another would say "at offset 0min". And since the W3C Media Fragments > WG is defining temporal addressing, such diverging pointers will even > end up in a URL and how should that be interpreted then? > > Cheers, > Silvia. David Singer Multimedia and Software Standards, Apple Inc.
Re: [whatwg] Video with MIME type application/octet-stream
It's an error to have a parameter that isn't valid for the mime type, so are you suggesting (a) that you throw away the parameter as it's invalid or (b) since it's an error to supply application/octet-stream as the mime type in the first place, we may as well process its invalid parameter in an attempt to recover? On May 20, 2010, at 10:27 , Simon Pieters wrote: > On Thu, 20 May 2010 18:44:12 +0200, David Singer wrote: > >> Did anyone revise the registration of application/octet-stream to add >> parameters? > > No. It's just error handling. > > -- > Simon Pieters > Opera Software David Singer Multimedia and Software Standards, Apple Inc.
Re: [whatwg] forwarded: Google opens VP8 video codec
On May 19, 2010, at 21:48 , Sir Gallantmon (ニール・ゴンパ) wrote: > > Google's patent license states that anyone that attempts to sue over VP8 will > automatically lose their patent license. That's a huge deterrent. only to potential practitioners...not trolls :-( (i.e. non-practicing patent owners) > AFAIR, the VC-1 codec didn't have that kind of clause, which caused the > debacle that led to the VC-1 patent pool... I don't recall, but I would be surprised. This is a pretty common defensive clause. David Singer Multimedia and Software Standards, Apple Inc.
Re: [whatwg] Video with MIME type application/octet-stream
Did anyone revise the registration of application/octet-stream to add parameters? On May 20, 2010, at 3:36 , Simon Pieters wrote: > On Thu, 20 May 2010 11:55:01 +0200, Robert O'Callahan > wrote: > >> I just became aware that application/octet-stream is excluded from being a >> type "the user agent knows it cannot render". >> http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#a-type-that-the-user-agent-knows-it-cannot-render >> Apparently this was done in response to a bug report: >> http://www.w3.org/Bugs/Public/show_bug.cgi?id=7977 >> Neither the bug report nor the editor's response give any indication why >> this change was made. > > This bug report was about application/octet-stream *with parameters*, e.g. > application/octet-stream; codecs="theora, vorbis". The spec had the > requirement about application/octet-stream before that bug report. > > >> This change means files served with application/octet-stream will make it >> all the way to the step "If the media >> data<http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#media-data>can >> be fetched but is found by inspection to be in an unsupported format >> ...", so implementations have to add support for binary sniffing for all the >> types they support. We didn't need this before in Gecko. What was the >> motivation for adding this implementation requirement? >> >> Thanks, >> Rob > > > -- > Simon Pieters > Opera Software David Singer Multimedia and Software Standards, Apple Inc.
Re: [whatwg] Speech input element
I am a little concerned that we are increasingly breaking down a metaphor, a 'virtual interface' without realizing what that abstraction buys us. At the moment, we have the concept of a hypothetical pointer and hypothetical keyboard, (with some abstract states, such as focus) that you can actually drive using a whole bunch of physical modalities. If we develop UIs that are specific to people actually speaking, we have 'torn the veil' of that abstract interface. What happens to people who cannot speak, for example? Or who cannot say the language needed well enough to be recognized? David Singer Multimedia and Software Standards, Apple Inc.
Re: [whatwg] Timestamp from video source in order to sync (e.g. expose OGG timestamp to javascript)
On May 17, 2010, at 14:31 , Odin Omdal Hørthe wrote: > Hello! > > I filed bugs at mozilla and in chromium because I want to sync real > time data stream to live video. Some of them told me to send it here > as well. :-) > > It's only possible to get relative playtime with html5 in javascript. I > want absolute timestamp that's embeded in OGG. > > The spec only deals with relative times, and not getting out > information from the > > Here's the deal: > I stream conferences using Ogg Theora+Vorbis using Icecast2. I have built a > site that shows the video and then automatically shows the slides (as PNG > files) as well. I use orbited (COMET) to have the server PUSH my «next» > presses on my keyboard. > > The problem is that icecast does heavy buffering, and also the client, so > that while I switch the slides, the browser will go from slide 3 to 4 WAY > too early (from 10 second to 1 minute). Buffering should not make any difference to how far into a stream a time means. If the transition from slide 3 to slide 4 happens at 10 minutes in, then as the presentation time ticks from 9:59 to 10:00 you should flip the slide. It doesn't matter how much data is in any buffers, does it? > > If I could get the timestamp OR time-since-started-sending/recording from > the ogg file in javascript, I'd be able to sync everything. > > There are multiple way to sync this, may even an stream with the slide-data > INSIDE the ogg file, however, AFAIK there's also no way of getting out such > arbitrary streams. > > (PS: I had some problems, so sorry if you get this email many times! :-S) > > -- > Beste helsing, > Odin Hørthe Omdal > http://velmont.no David Singer Multimedia and Software Standards, Apple Inc.
Re: [whatwg] Dealing with Stereoscopic displays
I agree that this probably means that web elements that are 'flat' would be styled by CSS with a depth. This is important if other material presented to the user really is stereo (e.g. a left/right eye coded movie). The movie will be set so that the eyes are expected to have a certain 'convergence' (i.e. they are looking slightly inward towards some point) and it's important that if material is overlaid on that. it has the same convergence. Obviously, this is unlike the real world where focus distance and convergence distance are the same (focus distance is fixed at the screen distance), but the brain can get very confused if two things that are both in focus are at difference convergence distances. This is not a simple question, as I expect you are beginning to realize. David Singer Multimedia and Software Standards, Apple Inc.
Re: [whatwg] Fullscreen for HTML5 Video element
Kiosks and the like fall into the category where the user agent, hardware platform, and so on, are known in advance, so proprietary extensions or other special methods work just fine. On Mar 9, 2010, at 6:04 , Silvia Pfeiffer wrote: > On Tue, Mar 9, 2010 at 2:42 AM, Nils Dagsson Moskopp > wrote: >> Dawid Czyzewski schrieb am Mon, 8 Mar 2010 >> 16:05:00 +0100: >> >>> Full screen custom UI is very needed feature and it's need to be >>> solved somehow. Specially in times here HD video show up on Internet. >> >> This seems to be a presentational issue. Maybe that is a use case better >> solved with CSS media types or media queries. > > In what situations would we want automatic full-screen video? I can > think of Kiosks, or where a Web browser is used for watching TV. Is > this really something we can express through media queries? > > Cheers, > Silvia. David Singer Multimedia and Software Standards, Apple Inc.
Re: [whatwg] Video source selection based on quality (was: feedback)
I am by no means convinced that automatic selection of sources other than that based on the most obvious, automated, criteria, is wise or needed. We have had for many years, in QuickTime, this facility, and quite a few sites opted not to use it and allow the user a manual choice instead. For example, bit-rate is important when watching a streaming movie (it has to arrive in time), but many users wanting to watch a trailer loaded over HTTP apparently choose to put up with longer downloads in order to watch higher resolution content. Offering the user a 'quality' based selection is, in a sense, pointless; why not show the user the best quality (all other things being equal)? The answer is that they aren't - that bitrate (sometimes) matters. David Singer Multimedia and Software Standards, Apple Inc.
Re: [whatwg] Video source selection based on quality (was: feedback)
I think I agree with Tim here. When you ask to watch "360p" content, you are asking for content that has 360 lines of pixels to be displayed to you. You're not asking for whatever is displayed to you to occupy only 360 lines of pixels on your display. Yes, when it is shown larger, then filtering etc. is done to avoid pixel-doubling blocky artifacts; this does not increase (and, we hope, not decrease) the amount of information in the scene. With the advent of higher-resolution displays, and the ability to use CSS with HTML to set 'sensible' sizes of video relative to other page content, the assumption that video will always be displayed in a 1:1 ratio of source (coded, transmitted) pixel to display pixel is increasingly untenable. On Feb 15, 2010, at 17:03 , Hugh Guiney wrote: > On Mon, Feb 15, 2010 at 7:07 PM, Tim Hutt wrote: >> Erm, what? The 360p refers to the 'native' resolution of the video >> file youtube sends. If you play a 360p video fullscreen, it's still >> only got 360 lines; they're just scaled up. It would be meaningless if >> the number referred to the final playback size since that is >> independent of the video quality. > > By "lines", do you mean TV (or scan) lines? > > TV lines and pixels can both be used to describe image resolution, but > they aren't the same thing. The difference is very technical and isn't > relevant to this conversation but essentially, TV lines pertain to > analog systems and pixels pertain to digital systems. And in the > digital realm, magnification is achieved through interpolation: since > the source image has less pixels than the destination image, a > resizing algorithm must invent pixels to fill in all of the unknown > values in the target image, based on the known values in the source > image. The result is a "best guess" of what the image might look like > at that resolution. The pixel count has changed; it is therefore new > data and not the same as the input. > > The way YouTube has it now is meaningless since the player doesn't > expand when you change the height (that's what that number is supposed > to indicate). The older standard/HQ/HD made more sense. David Singer Multimedia and Software Standards, Apple Inc.
Re: [whatwg] api for fullscreen()
On Feb 4, 2010, at 16:53 , Kit Grose wrote: > I also develop kiosk and medical applications where fullscreen is not only > desirable but necessary behaviour. Crippling the API such that the developer > cannot determine whether or not the user permitted their application to run > fullscreen is unnecessary—it's up to developers to use the API in a usable > manner, and up to UAs to provide an easy "escape hatch" if the developer > fails to do so, just like in desktop environments. You're not crippled in this environment. In a kiosk, you write the content, choose your browser, OS and hardware platform. You can (and maybe should) use non-standard extensions to take a vice-like grip of the display and UI. David Singer Multimedia and Software Standards, Apple Inc.
Re: [whatwg] api for fullscreen()
On Feb 3, 2010, at 15:03 , Kit Grose wrote: > I feel that the user shouldn't have the ability to enter into some sort of > "pseudo-fullscreen". If the content needs to be displayed full-screen, I don't believe that there is any such 'need' and that the user should own that decision. I, for example, basically refuse to use applications that have the hubris to assume that they should own the screen and cover all the parts they don't need with gray. I didn't buy a large display to see grey painted everywhere; I bought it so I *could* see multiple things at once. > If the user does not wish to view the content in full-screen and the > developer feels that content can only be reasonably viewed full-screen, The developer has no idea how big my screen is, how many I have, or a host of other questions. > I feel the user has opted not to view that content at all. I don't mind at > all that the user has no choice but to skip that content; it's similar > behaviour to a user quitting a desktop application that insists on running > full-screen. Indeed. David Singer Multimedia and Software Standards, Apple Inc.
Re: [whatwg] Codecs for and
On Feb 1, 2010, at 14:02 , Silvia Pfeiffer wrote: > On Tue, Feb 2, 2010 at 4:05 AM, Chris McCormick wrote: >> I think I speak for all procedural audio people when I say, can't we get the >> browsers to allow sample-block access to audio? > > Sounds like a solid argument to me. But I'm not the one who counts. :-) I think that the browser vendors are currently trying to nail basic HTML5 multimedia, then accessibility, then they'll take a breath and ask what's next. But do you have ideas as to how? David Singer Multimedia and Software Standards, Apple Inc.
Re: [whatwg] img copyright attribute
And it is worth saying that a copyright notice is not a license. "Copyright Martin Luther 1517" doesn't tell you anything at all about what permissions Martin is granting you. And rights permissions languages are much more complex... On Jan 12, 2010, at 6:06 , timeless wrote: > On Sun, Jan 10, 2010 at 4:53 AM, will surgent wrote: >> It would be nice if there was a copyright attribute for the HTML 5 img tag. >> This would make it easy for users and search engines to filter out images >> that can not be used for certain purposes. > > external metadata on copyright is a disaster. it gets lost immediately. > > GIF and friends have supported embedding (c) into images for decades. > > As google is fully capable of caching images (and obviously does so), > I question how adding a tag to html will solve a problem which is > already solved by the native image formats themselves. > > For lack of a more useful reference about comment fields, i'll just > point to one application which is aware of them (although at the time > of the posting it only supported them for certain image types): > http://www.group42.com/ts-wi04.htm David Singer Multimedia and Software Standards, Apple Inc.
Re: [whatwg] Remove addCueRange/removeCueRanges
At 0:49 +1200 23/08/09, Robert O'Callahan wrote: On Mon, Aug 17, 2009 at 8:04 PM, Max Romantschuk <<mailto:m...@romantschuk.fi>m...@romantschuk.fi> wrote: Silvia Pfeiffer wrote: Precision is influenced more strongly by the temporal resolution of the decoding pipeline rather than the polling resolution for currentTime. I doubt the previous implementations of "start" and "end" gave you a 3 sample accurate resolution even for wav files. I'll chime in here, having done extensive work with audio and video codecs. With current codec implementations getting sample- or frame-accurate resolution is largely a pipe dream. (Outside of the realm of platforms dedicated to content production and playback.) Especially for video there can be several seconds between keyframes, frame-accurate jumps requiring complex buffering tricks. Those tricks aren't that hard, at least for Theora; we do them in Firefox. It's very easy in QuickTime or MP4. Timestamps of the frames can be sample accurate, so you decode the right frame, and trim the result. Rob -- "He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all." [Isaiah 53:5-6] -- David Singer Multimedia Standards, Apple Inc.
Re: [whatwg] Remove addCueRange/removeCueRanges
At 10:31 +0200 13/08/09, Philip Jägenstedt wrote: Hi, We would like to request that addCueRange/removeCueRanges be dropped from the spec before going into Last Call. We are not satisfied with it and want to see it replaced with a solution that includes (scriptless) timed text (a.k.a captions/subtitles). I don't think that this will be finished in time for Last Call however, because we need implementor experience to write a good spec. However, we have no intention of implementing both cue ranges and its replacement, so it is better if the spec doesn't provide any solution for now. I have been briefly in contact with other browser vendors and while I cannot speak for them here, I hope those that agree will chime in if necessary. We reluctantly agree. We suggested a re-think a year ago, and though that got some support, it didn't get the editor's support. We do not have an implementation of the current spec., and don't expect to. <http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-July/015284.html> We do think the functionality is important, and are saddened to agree with this proposal, however. -- David Singer Multimedia Standards, Apple Inc.
Re: [whatwg] Alt attribute for and
At 11:22 +1000 10/08/09, Silvia Pfeiffer wrote: I'd be curious to hear what those problems and provisions are for and . I'm just referring to the rather extensive disciussion of 'alt' for images, and the concern some have with attributes that 'most' people don't see. I do agree that we need to think about both timed-media alternatives and accessibility provisions (captions, audio description of video, etc.) and untimed-media accessibility provisions (alternative text, titles, summaries, links to transcripts etc.). I'm just not sure what the best tools are, etc. Even though I'm a strong supporter of solving the subtitles/captions/i18n/sign language/audio annotation a11y issues of and , I still believe that "alt" may have a use similar to what it is used for with images. I agree there is a need, I'm just not sure how best to satisfy it. Discussion is good, but let's start with the problems and opportunities, then look at existing structures (such as ARIA) or parallels (such as alt), and see how well we can do. -- David Singer Multimedia Standards, Apple Inc.
Re: [whatwg] Alt attribute for and
At 1:12 +0200 10/08/09, Remco wrote: Shouldn't s and s (and maybe s too?) also have an alt attribute? A quick Google search tells me this has not been discussed before. Your search was too quick...we are discussing accessibility provisions for video and audio in general. Have a look under that. I think alt has been shown to have problems as well as provisions...perhaps we can find a better way? -- David Singer Multimedia Standards, Apple Inc.
Re: [whatwg] Dates BCE
At 18:19 -0400 30/07/09, Joshua Cranmer wrote:
David Singer wrote:
Against that, one has to realize that "the label of the day before
X" is well-defined for the day before the introduction of the
Gregorian calendar, and iteratively going back to year 1, year 0,
year -1, and so on.
In neither the Gregorian nor the Julian calendars is there a year 0,
as used in conventional speech (formats designed for machine
computation treat the issue a little differently).
Right. I was specifically referring to Proleptic Gregorian Calendar
in the specification ISO 8601, which does. This makes arithmetic
('how many years') and leap calculations ('is X a leap year') simpler.
Wikipedia:
'Mathematically, it is more convenient to include a year zero and
represent earlier years as negative, for the specific purpose of
facilitating the calculation of the number of years between a
negative (BC) year and a positive (AD) year. This is the convention
used in astronomical year numbering and in the international standard
date system, ISO 8601. In these systems, the year 0 is a leap year.
ISO 8601:
NOTE In the proleptic Gregorian calendar, the calendar year [] is
a leap year.
--
David Singer
Multimedia Standards, Apple Inc.
Re: [whatwg] Dates BCE
At 11:16 -0500 30/07/09, Tab Atkins Jr. wrote: > 1) Machine readability. This begs the question. raises the question. begging questions is assuming the answer in the premise of the question. Why do you need machine readability for the dates in the Darwin journals? More specifically, why do you need machine readability in a standardized fashion currently expected to be used primarily for adding dates to calendars? It allows you to build databases with timelines, that span documents on the web from diverse sources. 2) Consistency across websites that mark up dates. What form of consistency? Date format consistency? This varies by use-case, region, and language. Machine-format consistency? You then have to answer why such consistency is important - what does it let you *do*? It would allow you to determine that *this* event reported in an arabic text with a date referring to a caliphate was actually almost certainly *before* this *other* event reported in a byzantine text with a date that is on the indiction cycle. The experts in arabic and byzantine texts individually might well have the skills to convert these dates to a uniform day-labelling system, whereas the interested reader might have the skills in one or the other, but maybe not both (or perhaps even, neither). -- David Singer Multimedia Standards, Apple Inc.
Re: [whatwg] Dates BCE
At 17:12 +0100 30/07/09, Sam Kuper wrote: 2009/7/30 Tab Atkins Jr. <<mailto:jackalm...@gmail.com>jackalm...@gmail.com> On Thu, Jul 30, 2009 at 10:34 AM, Sam Kuper<<mailto:sam.ku...@uclmail.net>sam.ku...@uclmail.net> wrote: > Not for BCE; I'm not working on that period at the moment, but excepting that, here are a couple of good examples with ranges: <http://www.darwinproject.ac.uk/darwinletters/calendar/entry-10762.html>http://www.darwinproject.ac.uk/darwinletters/calendar/entry-10762.html <http://www.darwinproject.ac.uk/darwinletters/calendar/entry-295.html>http://www.darwinproject.ac.uk/darwinletters/calendar/entry-295.html <http://www.darwinproject.ac.uk/darwinletters/calendar/entry-6611f.html>http://www.darwinproject.ac.uk/darwinletters/calendar/entry-6611f.html Now, either there should be markup available for ranges, or it should at least be possible to specify components of a date independently of each other, and to imply (at least for humans) a "range" spanning these different date elements as appropriate. Now, here's the million-dollar question: Why do you need or something like it for these dates? You seem to have them marked up quite fine as it is. 1) Machine readability. 2) Consistency across websites that mark up dates. Quite. We've had this debate before and Ian decided that it might be confusing to apply a dating system to days when that dating system was not in effect on those days, I think. Against that, one has to realize that "the label of the day before X" is well-defined for the day before the introduction of the Gregorian calendar, and iteratively going back to year 1, year 0, year -1, and so on. And it would be nice to have a standard way of labelling dates in historical documents so that they are comparable; I am reminded of Kilngaman's book in which he has parallel chapters for China and Rome in the first century CE <http://www.amazon.com/First-Century-Emporers-Gods-Everyman/dp/0785822569/ref=sr_1_1?ie=UTF8&s=books&qid=1248970679&sr=8-1>. It would be nice if one could determine that two events in separate documents were essentially contemporary, despite being labeled in the original text in different ways. However, whether the spec. formally blesses using like this may not be very relevant, as it can be done textually with or without the blessing. -- David Singer Multimedia Standards, Apple Inc.
Re: [whatwg] HTML5 Definition of week (section 2.4.5.6)
At 10:45 + 19/07/09, Ian Hickson wrote: On Fri, 3 Jul 2009, SJ Kissane wrote: I am concerned by the wording of this section. There are different systems of week number -- as far as I can work out, this is the same as ISO 8601 week numbering. But it nowhere explicitly says that. I think, the spec should have a normative reference to ISO 8601 for the definition of week numbering. Then, if the spec wants to give an informative recap of what ISO 8601 says, for the benefit of those who don't have a copy (especially since it isn't free), that's fine. But I'm worried, by inserting some complicated definition into the spec, does it match exactly ISO 8601's definition? (I'm sure it does, but "are the definitions the same?" is not immediately obvious from inspection.) They are not the same. ISO8601 doesn't define how you parse a week string, how you handle errors in such a string, and so forth. The numbers are compatible, and a valid HTML5 week string is an ISO8601 week string (though I don't know if the opposite is the case), but that's about it. While we could have an non-normative reference, in practice, it wouldn't add much, since (a) the HTML5 spec defines everything you might get from ISO8601, and (b) we don't want to have implementors think "oh, it's the same as ISO8601, I'll just use an ISO8601 date library", since such a library might get the parsing details wrong in terms of what HTML5 says. an informative note to that effect might be a good idea. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' -- David Singer Multimedia Standards, Apple Inc.
Re: [whatwg] Thoughts on video accessibility
At 8:36 +1000 17/07/09, Silvia Pfeiffer wrote: I just noticed that the "media" attribute is already part of the "source" element definition in HTML5. I wonder which browsers have implemented this attribute. After having looked at http://www.w3.org/TR/css3-mediaqueries/, my understanding is that media queries specify the different presentation media that the html page's different stylesheets were built for and thus allow choosing between these stylesheets through the "link" element and its "media" attribute where the query goes. Also, IIUC, the list of presentation media is currently restricted to 'print', 'screen' , 'aural', 'braille', 'handheld', 'print', 'projection', 'screen', 'tty', 'tv', and 'all' and the queries cover only the features width, height, device-width, device-height, orientation, aspect-ratio, device-aspect-ratio, color, color-index, monochrome, resolution, scan, and grid. This is different for the "source" elements though: instead of specifying different presentation media and choosing between stylesheets, the "media" attribute specifies different user requirements and chooses between video source files. This makes it independent from CSS, IIUC. Is the intention to extend the specification of "media queries" to include generic means of selecting between alternative files to load into a HTML page? Is there a W3C activity that actually extends the media queries to audio and video files? If this is the case, it could also be used for the associated "text" elements that Ian and I discussed earlier in this thread. The alternatives there would be based on a combination of languages and the different categories of time-aligned text. The language would choose between different text files to load, and the text category would choose between different default styles to apply. I can imagine that that would work, but has anyone started extending existing media query specifications for this yet? you have it. I was wondering aloud whether media queries could be used to express this kind of presentation need; it's not such a stretch from "screen and print are different" to "screen and braille are different" to "plain screen and sub-titled screen are different"... I am thinking aloud here, you understand. But I think a *framework* for media accessibility "this is what can work, using features in HTML, CSS, media engines, scripting, etc." is important to work out. Getting basic captions working is important, but it should not be a one-off, but part of a conscious effort to treat accessibility as an integral part of the design. -- David Singer Multimedia Standards, Apple Inc.
Re: [whatwg] Thoughts on video accessibility
At 23:28 +1000 16/07/09, Silvia Pfeiffer wrote: > 2) I think the environment can and should help select and configure type-1 resources, where it can. It shouldn't need to be always a manual step by the user interacting with the media player. That is, I don't see why we cannot have the markup express "this source is better for people who have accessibility need X" (probably as a media query). However, media queries are CSS, not HTML... Would you mind providing an example that demonstrates the use of media queries? I cannot currently imagine what that could look like and how it could work. Feels free to use CSS in addition to any require HTML (and javascript?). Since I cannot imagine what that would look like and how it could work, I cannot start to understand it as an alternative. sure. using deliberately vague way of writing the media queries xx-O has open (burned in captions), uses the same codecs etc. It gets selected if the user says they want captions, otherwise XX-N (no captions) is selected. xx-S has a sign-language overlay capability. It gets selected for those users expressing a positive preference for sign language; otherwise we don't waste the bandwidth loading that, and we load the plain xx file. It may be that the media part of the UA also detects this user preference and automatically enables sign language in xx-S. Basically, I think we should have a framework which attempts to select and configure the appropriate source, so we get it right most of the time by default. This (accessibility) is a subject that covers multiple groups, of course... -- David Singer Multimedia Standards, Apple Inc.
Re: [whatwg] Thoughts on video accessibility
Thanks for the analysis, but two pieces of feedback: 1) Though sub-titles and captions are the most common accessibility issue for audio/video content, they are not the only one. There are people: -- who cannot see, and need audio description of video -- who cannot hear, and prefer sign language -- who have vision issues and prefer high or low contrast video -- who have audio issues and prefer audio that lacks background music, noise, etc. This is only a partial list. Note that some content is only available with open captions (aka burned-in). Clearly sub-optimal, but better than nothing. 2) I think the environment can and should help select and configure type-1 resources, where it can. It shouldn't need to be always a manual step by the user interacting with the media player. That is, I don't see why we cannot have the markup express "this source is better for people who have accessibility need X" (probably as a media query). However, media queries are CSS, not HTML... -- David Singer Multimedia Standards, Apple Inc.
Re: [whatwg] Codecs for and
Thank you, Ian, for the summary. I just wanted to say that we're not happy with the situation. We continue to monitor it, to take what action we can, and we continue to hope that we will, at some time, find a solution that reaches consensus. -- David Singer Multimedia Standards, Apple Inc.
Re: [whatwg] HTML 5 video tag questions
At 18:12 +0200 16/06/09, Kristof Zelechovski wrote: The first video source that can be played wins. You cannot provide alternative versions for different languages or resolutions in one VIDEO element. Chris but there are media queries, and I have posted a couple of times that we should considering allowing source selection based on accessibility needs. we should probably also make it possible to select on language, it's a common need. -- David Singer Multimedia Standards, Apple Inc.
Re: [whatwg] / feedback
At 12:09 +1000 13/05/09, Silvia Pfeiffer wrote: On Wed, May 13, 2009 at 5:01 AM, Jonas Sicking wrote: On Sun, May 10, 2009 at 6:56 PM, David Singer wrote: At 14:09 +1000 9/05/09, Silvia Pfeiffer wrote: Of course none of the discussion will inherently disallow seeking - scripts will always be able to do the seeking. But the user may not find it easy to do seeking to a section that is not accessible through the displayed timeline, which can be both a good and a bad thing. How easy a particular user interface is to use for various tasks is (I hope) not our worry... I'm not sure I agree. If the spec provides a feature set that no one is able to create a useful UI for, then there definitely might be a problem with the spec. I still have not received any comments on my previous assertion that there are essentially two separate use cases here. One for bringing attention to a specific point in a larger context, one for showing only a smaller range of a video. Just to confirm: yes, there are two separate use cases. (I was under the impression that the discussion had brought that out). Yes, that's fine. I think it's clear that we could have a 'verb' in the fragment "focus-on", "select" etc. to indicate that. I think it's also clear that no matter what verb is used, the entire resource is 'available' to the UA, that scripts can (if they wish) navigate anywhere in the entire resource, and that UAs can optimize the interface for the given verb, but the interface can still permit access to the entire resource. -- David Singer Multimedia Standards, Apple Inc.
Re: [whatwg] / feedback
At 14:09 +1000 9/05/09, Silvia Pfeiffer wrote: > you might try loading, say, the one-page version of the HTML5 spec. from the WhatWG site...it takes quite a while. Happily Ian also provides a multi-page, but this is not always the case. That just confirms the problem and it's obviously worse with video. :-) The reason I want clarity is that this has ramifications. For example, if a UA is asked to play a video with a fragment indication #time="10s-20s", and then a script seeks to 5s, does the user see the video at the 5s point of the total resource, or 15s? I think it has to be 5s. I agree, it has to be 5s. The discussion was about what timeline is displayed and what can the user easily access through seeking through the displayed timeline. A script can access any time of course. But a user is restricted by what the user interface offers. Sure. I think we are probably in agreement. Logically, the UA is dealing with the whole resource -- which is why it's 5s in this case. The UA is also responsible for focusing the user on the fragment, and (implicitly) for optimizing the network for what the user is focusing on. For example, some UAs would essentially invoke the same code if the user immediately did a seek to a time, if the javacsript did a seek to a time, or the initial URI had a fragment indicator starting at a time. In all three cases, the UA tries to start at that time as best it can, optimizing network access to do that. > But we can optimize for the fragment without disallowing the seeking. What do you mean by "optimize for the fragment"? I mean, the UA can get support from the server for time-based access, helping optimizing the network access for the fragment to be presented, while at the same time allowing seeking outside that fragment. Of course none of the discussion will inherently disallow seeking - scripts will always be able to do the seeking. But the user may not find it easy to do seeking to a section that is not accessible through the displayed timeline, which can be both a good and a bad thing. How easy a particular user interface is to use for various tasks is (I hope) not our worry... -- David Singer Multimedia Standards, Apple Inc.
Re: [whatwg] / feedback
At 23:46 +1000 8/05/09, Silvia Pfeiffer wrote: On Fri, May 8, 2009 at 9:43 AM, David Singer wrote: At 8:45 +1000 8/05/09, Silvia Pfeiffer wrote: On Fri, May 8, 2009 at 5:04 AM, David Singer wrote: At 8:39 +0200 5/05/09, KÞi"tof Îelechovski wrote: If the author wants to show only a sample of a resource and not the full resource, I think she does it on purpose. It is not clear why it is vital for the viewer to have an _obvious_ way to view the whole resource instead; if it were the case, the author would provide for this. IMHO, Chris It depends critically on what you think the semantics of the fragment are. In HTML (the best analogy I can think of), the web page is not trimmed or edited in any way -- you are merely directed to one section of it. There are critical differences between HTML and video, such that this analogy has never worked well. could you elaborate? At the risk of repeating myself ... HTML is text and therefore whether you download a snippet only or the full page and then do an offset does not make much of a difference. Even for a long page. you might try loading, say, the one-page version of the HTML5 spec. from the WhatWG site...it takes quite a while. Happily Ian also provides a multi-page, but this is not always the case. In contrast, downloading a snippet of video compared to the full video will make a huge difference, in particular for long-form video. there are short and long pages and videos. But we're talking about a point of principal here, which should be informed by practical, for sure, but not dominated by it. The reason I want clarity is that this has ramifications. For example, if a UA is asked to play a video with a fragment indication #time="10s-20s", and then a script seeks to 5s, does the user see the video at the 5s point of the total resource, or 15s? I think it has to be 5s. So, the difference is that in HTML the user agent will always have the context available within its download buffer, while for video this may not be the case. I'm sorry, I am lost. We could quite easily extend HTTP to allow for anchor-based retrieval of HTML (i.e. convert a 'please start at anchor X' into a pair of byte-range responses, for the global material, and then the document from that anchor onwards). This admittedly technical difference also has an influence on the user interface. If you have all the context available in the user agent, it is easy to just grab a scroll-bar and jump around in the full content manually to look for things. This is not possible in the video case without many further download actions, which will each incur a network delay. This difference opens the door to enable user agents with a choice in display to either provide the full context, or just the fragment focus. But we can optimize for the fragment without disallowing the seeking. -- David Singer Multimedia Standards, Apple Inc.
Re: [whatwg] / feedback
At 8:45 +1000 8/05/09, Silvia Pfeiffer wrote: On Fri, May 8, 2009 at 5:04 AM, David Singer wrote: At 8:39 +0200 5/05/09, KÞi"tof Îelechovski wrote: If the author wants to show only a sample of a resource and not the full resource, I think she does it on purpose. It is not clear why it is vital for the viewer to have an _obvious_ way to view the whole resource instead; if it were the case, the author would provide for this. IMHO, Chris It depends critically on what you think the semantics of the fragment are. In HTML (the best analogy I can think of), the web page is not trimmed or edited in any way -- you are merely directed to one section of it. There are critical differences between HTML and video, such that this analogy has never worked well. could you elaborate? > Given both of these, I tend towards using # as a focus of attention; if trimming is desired, the server should probably do it (maybe using ?). Just making sure I understand your suggestion correctly: I assume you are saying that both # and ? would be able to only deliver the data fragment that relates to the given specified temporal fragment, but you are suggesting that by using "#" the user agent is being told to present the context, while by using "?" the user agent would focus attention on the fragment only. Is that what you're saying or am I misunderstanding? Roughly, yes. I am saying that ? -- the author of the URI has to know that the server he points the URI at supports the ? syntax. The server essentially makes a resource using the query instructions, and delivers it to the UA. # -- the UA focuses the user's attention on, and optimizes the network usage for that focus of, the indicated fragment. It does this (a) visually, using whatever indicator it likes (we don't specify what the 'controller' looks like) and (b) using whatever network support it can get from the server (time-range, byte-range, or no support at all). A reason I say this is that technically I believe that # is stripped by the UA; we cannot then put a delivery requirement in, because that would apply to the server, which doesn't even get to see the # in all likelihood. -- David Singer Multimedia Standards, Apple Inc.
Re: [whatwg] / feedback
At 8:39 +0200 5/05/09, KÞitof Îelechovski wrote: If the author wants to show only a sample of a resource and not the full resource, I think she does it on purpose. It is not clear why it is vital for the viewer to have an _obvious_ way to view the whole resource instead; if it were the case, the author would provide for this. IMHO, Chris It depends critically on what you think the semantics of the fragment are. In HTML (the best analogy I can think of), the web page is not trimmed or edited in any way -- you are merely directed to one section of it. I am also aware that browsers that don't implement fragments will also show the whole resource; so authors can't rely on he trimming. Given both of these, I tend towards using # as a focus of attention; if trimming is desired, the server should probably do it (maybe using ?). -- David Singer Multimedia Standards, Apple Inc.
Re: [whatwg] / feedback
At 11:42 +1000 1/05/09, Silvia Pfeiffer wrote: re c): It depends on how the UA displays it. If the UA displays the 5s offset as the beginning of the video, then the user cannot easily jump to 0s offset. I thought this was the whole purpose of the discussion: whether we should encourage UAs to display just the addressed segment in the timeline (which makes sense for a 5sec extract from a 2 hour video) or whether we encourage UAs to display the timeline of the full resource only. I think we came to a slightly more abstract conclusion, that the UA focuses the user's initial attention on the indicated fragment. [And we are silent about how it does that, and also about how easy it is to look elsewhere.] I only tried to clarify the differences for the UA and what the user gets, supporting an earlier suggestion that UAs may want to have a means for switching between full timeline and segment timeline display. Ultimately, it's a UA problem and not a HTML5 problem. Exactly, agreed. -- David Singer Multimedia Standards, Apple Inc.
Re: [whatwg] Start position of media resources
At 16:45 + 30/04/09, Ian Hickson wrote: On Thu, 30 Apr 2009, David Singer wrote: If the resource is 'seekable' then time is relevant, and I agree that time should be a normal play time and run from 0 to duration. That wouldn't address the use case of files that were split with non-zero start times, though, where the author wants the original range to be the one visible in the UI. The complexity of edited files is only really dealt with by embedded time-codes. A single segment is the beginning of a large can of worms; what do you want to have happen when there are two segments played consecutively? Following your logic, there would be a time-jump. If it's not seekable (live), then the UA is free, of course, to buffer and allow seeking in that buffer, but that's a UA thing. Duration is indefinite, and the origin value of current time is also so. The concern is with resources that are seekable yet indefinite -- and in fact, the spec encourages browsers to make streaming resources seekable (much like how a DVR makes streaming live TV seekable). OK, in the case of server-supported DVR-like functionality, I agree there is a question. -- David Singer Multimedia Standards, Apple Inc.
Re: [whatwg] / feedback
At 23:15 +1000 30/04/09, Silvia Pfeiffer wrote: > On Thu, 30 Apr 2009, Silvia Pfeiffer wrote: > On Wed, 8 Apr 2009, Silvia Pfeiffer wrote: >> >> Note that in the Media Fragment working group even the specification >> of http://www.example.com/t.mov#time="10s-20s"; may mean that only the >> requested 10s clip is delivered, especially if all the involved >> instances in the exchange understand media fragment URIs. > > That doesn't seem possible since fragments aren't sent to the server. The current WD of the Media Fragments WG http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-reqs/ specifies that a URL that looks like this http://www.w3.org/2008/WebVideo/Fragments/media/fragf2f.mp4#t=12,21 is to be resolved on the server through the following basic process: 1. UA chops off the fragment and turns it into a HTTP GET request with a newly introduced time range header e.g. GET /2008/WebVideo/Fragments/media/fragf2f.mp4 HTTP/1.1 Host: www.w3.org Accept: video/* Range: seconds=12-21 2. The server slices the multimedia resource by mapping the seconds to bytes and extracting a playable resource (potentially fixing container headers). The server will then reply with the closest inclusive range in a 206 HTTP response: e.g. HTTP/1.1 206 Partial Content Accept-Ranges: bytes, seconds Content-Length: 3571437 Content-Type: video/mp4 Content-Range: seconds 11.85-21.16 That seems quite reasonable, assuming the UA is allowed to seek to other parts of the video also. > On Thu, 9 Apr 2009, Jonas Sicking wrote: >> >> If we look at how fragment identifiers work in web pages today, a >> link such as >> >> http://example.com/page.html#target >> >> this displays the 'target' part of the page, but lets the user scroll >> to anywhere in the resource. This feels to me like it maps fairly >> well to >> >> http://example.com/video.ogg#t=5s >> >> displaying the selected frame, but displaying a timeline for the full >> video and allowing the user to directly go to any position. > > Agreed. This is how the spec works now. This is also how we did it with Ogg and temporal URIs, but this is not the way in which the standard for media fragment URIs will work. It sounds like it is. I don't understand the difference. Because media fragment URIs will not deliver the full resource like a HTML page does, but will instead only provide the segment that is specified with the temporal region. http://example.com/video.ogg#t=5s only retrieves the video from 5s to the end, not from start to end. So you cannot scroll to the beginning of the video without another retrieval action: which is fine. I don't see the problem; given a fragment we a) focus the user's attention on that fragment b) attempt to optimize network traffic to display that fragment as quickly as possible Neither of these stop c) the user from casting his attention elsewhere d) more network transactions being done to support this i.e. assuming we displaying the full video timeline for a http://example.com/video.ogg#t=5s";..> element, and then the user clicks on the beginning of the video, a http://example.com/video.ogg#t=0s request would be sent. The difference is the need for the additional retrieval action, which, if the full resource was immediately downloaded for http://example.com/video.ogg#t=5s would not be necessary. But that's not how media fragments work, so I tried pointing this out. Cheers, Silvia. -- David Singer Multimedia Standards, Apple Inc.
Re: [whatwg] Start position of media resources
At 6:21 + 30/04/09, Ian Hickson wrote:
On Thu, 30 Apr 2009, Robert O'Callahan wrote:
On Thu, Apr 30, 2009 at 1:04 PM, Ian Hickson wrote:
>
> I have left the spec as is (except for adding startTime), which means
> that currentTime can be greater than duration if startTime is not
> zero.
I think it would be safer to have the invariant that 0 <= currentTime <=
duration. Most resources will probably have startTime==0 so authors will
write scripts expecting these invariants, and their scripts will break
when confronted with unusual resources with startTime>0.
So I think a safer design would be to interpret currentTime as relative
to the startTime, perhaps renaming startTime to 'timeOffset' instead?
I considered that, but it seems that in the streaming video ("DVR-like")
case, in the steady state where the data in the buffer is being thrown
away at the same rate as the video is being played you'd end up in a weird
position of the currentTime not changing despite the video playing, which
would likely be even more confusing.
If the resource is 'seekable' then time is relevant, and I agree that
time should be a normal play time and run from 0 to duration.
If it's not seekable (live), then the UA is free, of course, to
buffer and allow seeking in that buffer, but that's a UA thing.
Duration is indefinite, and the origin value of current time is also
so.
--
David Singer
Multimedia Standards, Apple Inc.
Re: [whatwg] Start position of media resources
At 22:30 +1000 9/04/09, Silvia Pfeiffer wrote: On Thu, Apr 9, 2009 at 4:46 AM, Ian Hickson wrote: On Wed, 8 Apr 2009, David Singer wrote: > > Navigation outside the indicated range could be done in several ways - > it does not have to be through indicating the full length of the > resource in the timeline. surely. but which one can the URL/page author expect? If I pick an innocuous scene out of an R-rated movie and put it on a web page for children, can they easily see other parts of the movie or not? I think the answer to this should be "yes". I agree thus far. For example if someone on reddit links to a particular part of a video, as a user I should trivially (by dragging the scrubber) be able to see the context. I don't think we should be changing the timeline just because the author set a start and end position somehow. I understand that this makes sense in a lot of cases - e.g. in something like http://www.youtube.com/watch?v=kHXuXWznFgk#t=5s . However, I would actually prefer if we make the full resource available in a different manner. The reason is that when you link to a small segment that is part of a long resource - e.g. 30 seconds out of a 5 hour long video - your selection on the timeline is not visible and it is unclear where the segment is playing and you're unable to scrub around the segment properly. Maybe we can introduce a toggle button that allows the timeline to show/hide context, in particular for long resources? Or we could introduce a attribute that says context="true/false" depending on what the page author prefers is being done with the segment? This would also allow to hide the context in cases such as the one that David described. Not that it can be completely hidden - anyone who understands URLs will be able to load the full resource. But it will make it more difficult. I think the spec. merely needs to say that the UA focuses the initial attention of the user on this segment of the media resource, and should optimize network usage to that end; but neither the UA nor the user are restricted to this section if they don't wish to be. How they handle that, how good their navigation/scroll-bar etc. is, is up to them in this case - we've said as much as we need to for the author and server to know what's happening. -- David Singer Multimedia Standards, Apple Inc.
Re: [whatwg] Start position of media resources
At 15:46 +1000 8/04/09, Silvia Pfeiffer wrote: On Wed, Apr 8, 2009 at 8:37 AM, David Singer wrote: > But there is a huge difference between a) the UA MUST optimize for the chosen fragment, and may/should offer the rest of the resource to the user (at the possible expense of more network traffic) and b) the UA MUST only offer the chosen fragment to the user, and optimize network traffic and downloads for just that section, and MUST NOT allow navigation outside the indicated range Unfortunately, it does make a difference to the page author which of these is talked about (and, lacking anything else, (a) is probably what is expected). Navigation outside the indicated range could be done in several ways - it does not have to be through indicating the full length of the resource in the timeline. surely. but which one can the URL/page author expect? If I pick an innocuous scene out of an R-rated movie and put it on a web page for children, can they easily see other parts of the movie or not? -- David Singer Multimedia Standards, Apple Inc.
Re: [whatwg] Start position of media resources
At 8:29 +1000 8/04/09, Silvia Pfeiffer wrote: > My mental analogy was HTML, where an acnhor takes you to that part of the page as a convenience, but nothing stops you from navigating away. And in the case where the UA optimizes for showing that section (by suitable handshakes/translations with the server), again, it could present a UI which offers other times -- at the expense of more handshakes. Yes, I understand that analogy. But because video can be a very long resource, media fragment URIs cannot be restriced to client-side offsetting. Think e.g. about wanting the last 2 minutes out of a 5 hour discussion downloaded to your mobile phone. The media fragment WG decided that fragment addressing should be done with "#" and be able to just deliver the actual fragment. (BTW: this is in contrast to the temporal URIs that were specified for Annodex, where chopping happened in the UA for "#" and on the server for "?"). But there is a huge difference between a) the UA MUST optimize for the chosen fragment, and may/should offer the rest of the resource to the user (at the possible expense of more network traffic) and b) the UA MUST only offer the chosen fragment to the user, and optimize network traffic and downloads for just that section, and MUST NOT allow navigation outside the indicated range Unfortunately, it does make a difference to the page author which of these is talked about (and, lacking anything else, (a) is probably what is expected). -- David Singer Multimedia Standards, Apple Inc.
Re: [whatwg] Start position of media resources
At 8:02 +1000 8/04/09, Silvia Pfeiffer wrote: Note that in the Media Fragment working group even the specification of http://www.example.com/t.mov#time="10s-20s"; may mean that only the requested 10s clip is delivered, especially if all the involved instances in the exchange understand media fragment URIs. During a transition period, while the infrastructure does not support media fragment URIs yet, the full resource will be delivered and it is up to the UA to deal with the consequences. It could either terminate the connection and decide that the resource is too long to accept and report an error to the user. Or it could receive the full resource, but decide to just play back the requested segment. Since ultimately the aim is to have only the requested clip downloaded, I think the UI presentation should be identical to the one where a query is used. BTW: the media fragment WG will make suggestions as to what a UA should do, but ultimately every application may have its own motivations for what to display, so you will not see definite specifications for what a UA is supposed to do UI-wise with media fragments. Think, e.g., about a playlist that consists of fragments from multiple Web resources (including different servers). Such a mash-up should probably best be represented with on continuous timeline that overrides the original timing of each clip. Only when you drill into the clip will you actually get the original in and out times. Ah, OK. I agree that telling UAs what they should do, ought to be for the most part, out of scope. But if there is material that the page author does NOT want to have shown, they probably need to know whether the # syntax will assure them that the user is restricted. (Always understanding that if they copy-paste the URL, neitehr # nor ? syntax stops them from changing the selection range). Think of presenting a K-12 class with a clip from a movie... My mental analogy was HTML, where an acnhor takes you to that part of the page as a convenience, but nothing stops you from navigating away. And in the case where the UA optimizes for showing that section (by suitable handshakes/translations with the server), again, it could present a UI which offers other times -- at the expense of more handshakes. -- David Singer Multimedia Standards, Apple Inc.
Re: [whatwg] Start position of media resources
At 19:20 +0200 7/04/09, KÞitof Îelechovski wrote: OTOH, if the media player scroll bar has zoom function, the problem of navigation deficiency in a short interval disappears. When the browser displays a fragment, it can just zoom the scroll bar to the fragment displayed. IMHO, Chris That's a semantic problem I hope that the media fragments group will clarify. If a URL asks for http://www.example.com/t.mov?time="10s-20s"; it's clear that all I have at the UA is a 10s clip, so that's what I present; the ? means the trimming is done at the server. However, if I am given http://www.example.com/t.mov#time="10s-20s"; which means the UA does the selecting; should the UA present a timeline representing all of t.mov, but start at 10s into it and stop at 20s, allowing the user (if they wish) to seek outside that range, or should the UA present (as in the query case) only a 10s clip? -- David Singer Multimedia Standards, Apple Inc.
Re: [whatwg] Start position of media resources
I think that there is a very real difference between the zero-to-duration 'seek bar' that the UI presents, and which users understand, from the 'represented time' of the content. That might be a section of a movie, or indeed might be a section of real time-of-day (think of one of the millions of british surveillance cameras..., or not if you'd prefer not to). Getting "what time is this media resource talking about" is a metadata question... -- David Singer Multimedia Standards, Apple Inc.
Re: [whatwg]
he user wants. At 15:59 +0200 16/03/09, Mikko Rantalainen wrote: How about specifying that the content of element will be parsed for the date only if 'datetime' attribute is empty. In addition, the spec should explicitly say that if the content is time in any other calendar system but Proleptic Gregorian calendar then the datetime MUST contain equivalent time in standard format (whatever the spec for 'datetime' will be). Don't forget that there are plenty of cases where, alas, the exact day referred to is uncertain and cannot be mapped to any other calendar. -- David Singer Multimedia Standards, Apple Inc.
Re: [whatwg]
At 19:26 -0500 13/03/09, Robert J Burns wrote: The chief accomplishments of ISO 8601 is the ability to represent dates in a uniform manner and in defining the Gregorian calendar from 1582 to in an unambiguous way. Beyond those dates it leaves things imprecise and ambiguous. You keep saying this, but I have yet to hear what is imprecise or ambiguous. Could you be more clear? Apart from the topics we're actually disputing? :-) The issue of year opens a can of worms. Negative numbers open a can of worms. What can of worms? In what way is labelling the day before 1 jan 0001 as 31 dec unclear? 1) HTML is often hand-coded and so it places an undue burden on authors to convert non-Gregorian calendar dates to Gregorian calendars dates so it's better to place that burden on the many readers rather than the one writer? I don't follow you. 3) ISO 8601 says nothing about the interpretation of non-positive years and so the meaning within ISO 8601 is left ambiguous without further normative criteria It says it uses consecutive integers as year labels, allows a minus sign, and, in case you are in any doubt, has an example of year . What is ambiguous? 1) doesn't even reference ISO 8601, I agree that would be better. 2) allows without attaching sufficient meaning to it ? and does not allow any further dates before , yes, the reason for this prohibition is unclear, as they are well-defined. 3) does not clearly define the era, 8601 does, or do you mean something else? 4) and does not provide sufficient document conformance norms for the contents of the 'time' element. again, details? -- David Singer Multimedia Standards, Apple Inc.
Re: [whatwg]
At 17:02 +0100 13/03/09, Leif Halvard Silli wrote: I struggle to understand why it is better to ask *authors* to use One True Calendar instead of e.g having a scheme attribute through which the author can specify the date/time format. You might want to read <http://www.cs.tut.fi/~jkorpela/iso8601.html> where it is stated "Automatic processing of data is easier to program if dates and times are expressed in a uniform, preferably fixed-length notation." Also, you might consider our own <http://www.w3.org/QA/Tips/iso-date> and how much harder it might be to represent dates in other calendar systems and languages (Japanese is given here) if the source format could vary. If your alternative format can be converted to other date systems, it is highly likely it can be converted to 8601, and then it should be at source. If it can't be converted to other formats, it is way less useful as an markup value. Can we drop this topic? Apart from suggesting a) that the fully delimited date format be required (extended format); b) that year and before be allowed; c) that parsing the body text as 8601 may be dangerous if it's notated the same way but not (possibly proleptic) Gregorian; otherwise we don't seem to have made much progress on 'improving' this side-line in HTML, despite the rather large volume of posts. -- David Singer Multimedia Standards, Apple Inc.
Re: [whatwg]
At 16:24 -0500 12/03/09, Robert J Burns wrote: That was my point: we cannot get a clear answer out of ISO 8601. ISO 8601 only covers dates between 1582 and without supplemental norms. No, it says mutual *agreement*, not supplemental norms. ISO 8601:2004 seems perfectly clear that the year before 0001 is , and that -0002-04-12 means "The twelfth of April in the second year before the year [] " (example directly from ISO 8601). The HTML spec. can constitute such agreement. I see no reason to forbid such uses in HTML. Can you? If we're only interested in the representation of dates - and not their comparison - then I would agree with what you say here. However, then supporting Julian dates are available for free (since there are absolutely no differences in the representation of a Julian date and a Gregorian date). They are nothing like free if you want UAs to support them. As I said above this seems inconsistent with your position on year zero. If we're only interested in date representations and not in date comparisons then supporting Julian dates requires no more implementation support than supporting Gregorian dates. No. If my UA wants to present dates to the user in his preferred form or calendar system, it helps iut enormously if there is only one way to represent a date, from which it has to convert. If there are two, and the conversion of the second is a pain (which Julian is), this is a problem. However, if we're interested in comparing dates within a machine readable attribute than it is very important how year zero and other non-positive years are handled. I'm not trying to say gotcha here, I'm trying to understand how you see these machine readable dates being used. Are we interested in only date representation or also in date comparison? I don't think there is any legitimate reason to add support for multiple calendars in the timestamp. It's bad enough that we have *two* competing time formats (the current spec format and unix timestamps) for encoding dates over the wire. Just convert your date into the supported timestamp format, then represent it however you want within your page. However, this places a burden on authors that could be more easily handled by implementations. When an author cites a historical date they are often interested in it as the Julian date. Why should an author need to go convert the date to Gregorian date every time the author wants to use this HTML feature? So the UA can display it. If they don't care, leave off the datetime attribute. If you are unsure of the conversion, say so in the text: Especially if date representation is the goal and not date comparison, there should be no reason an author cannot use the same ISO 8601-style representations for Julian dates. Representation is a minor issue. Definition of the name "julian", of the valid values of the attribute, and of the calendar "julian", are, and the cost to UAs of implementing it. -- David Singer Multimedia Standards, Apple Inc.
Re: [whatwg]
At 17:53 +0100 12/03/09, Julian Reschke wrote: Geoffrey Sneddon wrote: ... Ultimately, why is the Gregorian calendar good enough for the ISO but not us? I'm sure plenty of arguments were made to the ISO before ISO8601 was published, yet that still supports only the Gregorian calendar, having been revised twice since it's original publication in 1988. Is there really any need to go beyond what ISO 8601 supports? ... Indeed. We aren't the subject matter experts on calendars and date formats, so why do we pretend we are? I agree. As I said before, if we want a tag to express that a date is in a different calendar system, we are not going either to invent those tags or define the notation and conversion of those calendar systems here. We can and should rely on groups like ISO. -- David Singer Multimedia Standards, Apple Inc.
Re: [whatwg]
At 20:11 -0500 10/03/09, Robert J Burns wrote: Indeed. That's one of the ways it can be done. IMHO it meets a huge set of the possible use cases. And it has the sort of simplicity that tends to be the defining characteristic of the best of HTML5. (Well, parsing isn't simple and is clearly part of the best of, but I am sure you get my drift...) Moving to a common calendaring system is important for comparing dates and perhaps searching for events in a uniform manner. However, it actually places a burden on authors to shoehorn dates into the Gregorian calendar and in terms of UTC when they would otherwise be expressed in some other calendar (or where UTC makes no sense whatsoever). Well, not shoehorn: translate if they can. Hasan of the blacksheep being Khan two years, in the month of the collection of walnuts, the third day after the full moon -- the author worked out when this was (good for them). Leave off the attribute, and you're saying it's a time and the author could not (or did not) translate it. I think this is what the draft says, to be honest. Get it from the attribute if it's there, try to get it from the content, and if that fails, the date is unknown. The only possible downside with the current drafts are: a) there is no attribute to say what the content format is. But until someone comes up with a uniform descriptive set of tags for the possible date formats, I'd leave this alone. b) if the content is not a Gregorian proleptic date, and yet can be parsed as such, and the datetime attribute is absent, then the user may be misled. I wonder why the 'try to parse the content' step is in there? -- David Singer Multimedia Standards, Apple Inc.
Re: [whatwg]
At 3:22 +0100 10/03/09, Charles McCathieNevile wrote: That format has some serious limitations for heavy metadata users. In particular for those who are producing information about historical objects, from British Parliamentary records to histories of pre-communist Russia or China to museum collections, the fact that it doesn't handle Julian dates is a big problem - albeit one that could be solved relatively simply in a couple of different ways. The trouble is, that opens a large can of worms. Once we step out of the Gregorian calendar, we'll get questions about various other calendar systems (e.g. Roman ab urbe condita <http://en.wikipedia.org/wiki/Ab_urbe_condita>, Byzantine Indiction cycles <http://en.wikipedia.org/wiki/Indiction>, and any number of other calendar systems from history and in current use). Then, of course, are the systems with a different 'year' (e.g. lunar rather than solar). And if we were to introduce a 'calendar system designator', we'd have to talk about how one converted/normalized. I'd rather have the historical pages say "In the 4th year of the first Indiction cycle of the second reign of the Emperor Justinian called the golden-nosed, in the 3rd day following the nones of August, at the hour of dawn in the city of Chrysopolis" (and then they give the Gregorian translation, e.g. 6am on the 12th of August 707 CE). The other issue is the one of precision - while you can name a single year, which will deal with a lot of use cases there are a lot left out because the precision required is a period. Ranges are included in 8601, and making a range syntax that handled almost all the relevant use cases is pretty straightforward. Adding a range construct to 8601, or having a range construct ourselves using 2 8601 dates, seems like something we could ask for or do. -- David Singer Multimedia Standards, Apple Inc.
Re: [whatwg] Dates and coordinates in HTML5
At 13:59 -0500 24/02/09, WeBMartians wrote: It's back! It won't die! :-) Although it can be argued that a standard should not consider the work required for implementation, many of the trade-offs in reference to times and dates do indeed take the present state of code into consideration. One reason for not supporting BCE is a disagreement between historians and, say, astronomers, on how to represent the year immediately preceding year one. Is it year -1 (1 BCE) or year zero? Currently, the text states that all dates and times since the beginning of the common era (0001-01-01 00:00:00Z) must be supported. Yes, the Javascript values can specify dates and times before this epoch. However, there is no way to interrogate the environment as to whether or not such values can be used with . That would require much more work. Thus, the limitation of common era. I'd love to see support for BCE and even for prolepsis and non-Gregorian calendars. ...but I do see the "no BCE" compromise as a workable one. ISO 8601 is quite precise on this issue. Since these are both machine and human-readable, why is this precision a problem? Why would we not use ISO 6709 (Annex H, text string) as the format for location? -- David Singer Multimedia Standards, Apple Inc.
Re: [whatwg] Synchronized play/seek of multiple elements?
At 10:20 + 18/02/09, Ian Hickson wrote: On Wed, 18 Feb 2009, Emil Tin wrote: However, I've been unable to find any information on how to trigger several audio files in a synchronized manner. Does the html 5 specification provide any way to to this? Not currently. Yes. We felt it would be a major complication to the spec., and wanted to keep things simple for the first iteration. -- David Singer Multimedia Standards, Apple Inc.
