Re: [whatwg] canvas, img, file api and blobs
2010/2/16 Joel Webber j...@google.com: On Tue, Feb 16, 2010 at 2:25 PM, Stefan Haustein haust...@google.com wrote: Constructing ints / longs from bytes in Javascript will probably be slow, so in addition to the typed arrays, we'd love to have some kind of access that would be similar to Java's DataInput (+DataOutput, see http://java.sun.com/j2se/1.4.2/docs/api/java/io/DataInput.html ), but with endianess support Agreed with Stefan's point, although technically you could implement getByte(), getShort(), et al with a bunch of TypedArray views onto a single ArrayBuffer. But this is really, really ugly, because in the general case you'd need 4 ByteArrays, 2 ShortArrays, etc. to deal with arbitrary offsets. A mini language that describes arbitrary sequences of data types in binary data is the one used by the Python module struct (http://docs.python.org/3.1/library/struct.html). E.g. 3b x 2i represents 3 signed chars, one byte of padding and 2 signed 32-bit ints, little-endian. It can be an inspiration for functions or methods that extract data out of byte arrays and convert JS variables back to binary. Another thing that people will probably ask is the possibility of converting binary data to and from strings. Obviously for both directions the user has to provide an encoding (e.g. UTF-8). -- Lino Mastrodomenico
Re: [whatwg] HTML 5 video tag questions
2009/7/13 Ian Hickson i...@hixie.ch: On Fri, 10 Jul 2009, Jeff Walden wrote: And if a site wants to publish H.264-only with Flash or QuickTime as the fallback, they have to use scripting to make it work in Firefox. We presumably don't want to make the use of uncumbered codecs easier. I agree. Moreover there are already two stable and widely used browsers that implement the current spec and websites are starting to use it. Since this fallback would be an incompatible change, please don't do it unless there's a *really* good reason for it. -- Lino Mastrodomenico
Re: [whatwg] Chipset support is a good argument
2009/7/6 Kristof Zelechovski giecr...@stegny.2a.pl: Small authors are hardly an alternative to YouTube because they use YouTube (or a similar service) to publish their content. [snip] In short, if you do not have the know-how to serve your video content, you will just use YouTube and never bother. I am a small author and I have basic knowledge about how to encode a video. it's really not hard using a GUI frontend for ffmpeg2theora; it's pretty much only a matter of selecting a good compromise between encoding quality, resolution and bitrate, checking the result and trying again with different resolution or quality until you get what you want. You usually get subsequent videos right at the first try. But in the past I've used YouTube to host my videos because I don't have the know-how to write a Flash video *player* that works on different browsers, with workarounds for bugs that may crash old (but still widely used) versions of the plugin, alternative encodings for old plugins that don't support H.264, etc. The problem is not that I don't know how to encode a video, it's that I don't know how to write a video player that works as well as the YouTube one. I know that there are free ones around, but in my limited tests they don't work well with old Flash versions and are more complicated than a simple video tag. HTML5 solves this problem because now the player is embedded in the browser, so I started using video src=whatever.ogv and hiding the YouTube object blurb inside it as a fallback. This should work with every browser (except maybe Safari without XiphQT???), gives me the freedom to choose exactly the resolution I want and a bit of Independence from YT, which is good (think about cases like a troll flagging my videos: AFAIK YouTube automatically removes videos after a certain number of flags). With HTML5 video I can also get better quality because the videos don't have to go through two lossy encodings and I can also push the bitrate up a bit, since my website doesn't have a billion visitors each day. And if you do have, you will not begin with reading the HTML specification either. I did. And after reading it I decided to use the autoplay and controls attributes. Except the missing reference to Ogg/Theora, I found the spec much more informative and useful than other tutorials found on the interwebs that suggested using autoplay=false to disable autoplay (completely wrong, of course) or presented examples using WMV-encoded videos. Yes I'm talking about w3schools. ciao -- Lino Mastrodomenico
Re: [whatwg] Chipset support is a good argument
2009/7/6 Maciej Stachowiak m...@apple.com: Here's an example of some markup that will work on a wide range of browsers, if you provide Ogg and MP4 versions of your video: http://camendesign.com/code/video_for_everybody. The MP4 version can be played either through video in browsers that support that, or by Flash or QuickTime or Windows Media Player. This actually results in video that works better in more browsers than Flash alone. My first goal is to get as much as possible of my users to watch my videos, but my secondary goal is to do so in a way that encourages a sustainable video ecosystem on the web. I don't think that including an easy and always available fallback to H.264 gives Apple and Microsoft any incentive to support Theora or other free alternatives. Moreover, while MP3, MPEG-4 ASP and H.264 are entirely fine and widely used for pirated music and movies (which is illegal anyway), I prefer not to put any H.264-encoded file on my website, things like these scare me: http://www.streaminglearningcenter.com/articles/46/1/H264-Royalties-what-you-need-to-know/Page1.html and: http://www.streamingmedia.com/article.asp?id=11011page=1c=7 Apparently the MPEG LA has not yet decided if and how much they want me to pay from january 2011. I'm sorry if this sounds like FUD, but I will not use H.264 until is available without fees for the websites (guaranteed forever, not in a we-may-change-our-mind-anytime way) and with an open-source-like patent licence for encoding and decoding. I'm not asking to the MPEG LA to kill their business, they can sell a single patent licence to the open source/free software community for a ridiculously high price. Insanely high. If it's applicable to derived works, the community may well pay for it, and if it uses (for patents) terms similar to the ones that the GNU GPL uses (for copyright) then the MPEG LA will still be able to make more money by selling traditional lower-priced licences to proprietary software vendors. I hope they change their mind soon, but until the MPEG LA keeps H.264 captive, it's simply not an option for me as a web developer. (Personally I'd recommend putting the H.264 source first instead of last, so browsers that support both H.264 and Theora will pick the higher-quality video.) I use a high enough bitrate (roughly 0.2-0.25 bits per pixel, but it changes a lot depending on the material and the resolution) that most people can't tell the difference even on side-by-side comparisons. And if they did I don't want to penalize browsers that chose to support only Theora, since they IMO did the right thing for a sustainable future of the video on the web. Anyway I tried deinstalling XiphQT on my Mac and Safari doesn't play the YouTube fallback inside video, so I'll include a small JS that detects the situation and completely removes video leaving only the YT object (BTW, canPlayType in Safari 4.0 seems buggy: it always returns no, even with XiphQT installed). -- Lino Mastrodomenico
Re: [whatwg] Codecs for audio and video
[Maciej, sorry for sending this to you twice] 2009/7/1 Maciej Stachowiak m...@apple.com: It's not clear if a similar virtuous cycle would repeat for other codecs. Might happen, but it took a lot of industry coordination around H.264 to build the ecosystem around it that exists today. So I don't think it's reasonable to assume that hardware implementations will just appear. Even without any apparent industry coordination around Vorbis, many portable music players (not the ones produced by Apple, admittedly) can play Ogg audio files. Note that many of them do *not* say this on the tin: e.g. my cheap noname MP4 player is advertised as being able to play only MP3 and WMA audio and AMV video files, but it also supports Ogg/Vorbis just fine. When Vorbis files reached a small critical mass a few years ago many hardware manufacturers without much fanfare started supporting it. Having a free implementation with a very liberal licence may have helped. This player is also a good example of how some DSPs can be used for different tasks: its DSP is exactly the same that has been used only for MP3 decoding in earlier players, but in these new models it decodes the video part of AMV (a modified MJPEG). Obviously I'm not suggesting that this particular model can also decode Theora (the main CPU is an 8-bit Z80 at 60 MHz max). Anyway I think that the spec can be made more informative for web authors by pointing out (in a non-normative section) the fact that there's one and only one format that can be played by all browser that support the video element: Ogg/Theora+Vorbis. Safari can play Theora if the Xiph Quicktime component is installed, while Firefox cannot play H.264. -- Lino Mastrodomenico
Re: [whatwg] Codecs for audio and video
2009/7/1 timeless timel...@gmail.com: I have no idea about purchasing costs (again, we work on software), but I think people will accept that the cost for an FPGA is orders of magnitudes higher than and not commercially viable in contrast to ASICs. I think we can all agree that a FPGA is being used only for development and debugging of a Theora hardware decoder (http://www.students.ic.unicamp.br/~ra031198/theora_hardware/), while the final design will be burned to an ASIC if/when there's commercial demand for it. Sadly, Apple gets no points for being Pluggable on Desktop (QT has an open API). If I were to complain about Mozilla not being open, they'd claim oh, we're open source, anyone can contribute. That isn't true btw, if I were to write a pluggable module for video, their benevolent dictator has every right to veto it. I fear that wide support for pluggable codecs for the video element may end up putting end users in a codec hell. If there's only one or at most two supported video formats/codecs, then it's obviously responsibility of the websites to correctly encode their videos. But if Firefox starts supporting any codec that happens to be installed on the system, many small and medium websites will probably start using videos in a lot of different formats (that works on the computer of the web developer) and the burden of finding and installing the correct codecs for each site will shift on the end user. Not good for interoperability, non-x86 platforms, and a good opportunity for spreading malware using trojan codecs. So please browser vendors, don't do this. The only exception is Safari, since it wouldn't otherwise support Theora. -- Lino Mastrodomenico
