yuvi

Safari will strip identical title prefixes in tab names for exactly that case.

Perhaps other browsers should copy this.

CDBaby and tunecore are pretty close I guess, they'll get you on iTunes and more (physical copies too in CDBaby's case)

> You can set the pointer to any address, which includes future stack.

This is wrong. Attempting to use random pointers to outside of what your compiler and malloc allocated is undefined.

And indeed, aliasing issues like in your example will prevent gcc from optimizing out excess strlen; it can only do so if it can prove that both global memory and the buffer passed to strlen have not been modified. Local variables and return values cannot alias anything, and part of the guarantee of pure functions like strlen is that they have no side effects.

Were you using gcc?

I wouldn't be surprised if e.g. MSVC didn't perform that optimization since it doesn't have the pure function attribute.

That isn't hardware decode, that's hardware scaling.

http://blogs.adobe.com/penguin.swf/2008/05/flash_uses_the_gp...

Also, Flash does not use any of the multiple hardware decode APIs on linux yet due to it needing readback support which apparently they don't have yet.

http://blogs.adobe.com/penguin.swf/2010/01/solving_different...

You can disable compilation of MPEG codecs if it makes you feel safer.

But I don't see what that has to do with my comment.

Chrome uses FFmpeg, which already has a good amount of ARM optimizations and is around 10% faster than Theorarm on my Cortex-A8.

Maybe it's in the same vein as summer of code?

I think cover.jpg came from doom9 [1]

I guess robux4 was talking about the old system, which I honestly didn't know existed before you brought it up. If the new system doesn't use the 16 bit format then yeah, it isn't well specified.

[1] http://forum.doom9.org/showthread.php?p=388815#post388815

No clue what the depreciated version might be, as far as I know what I linked to hasn't changed since sometime around 2005 (which would explain any broken links.)

Cover art wasn't specifically defined in mkv I think, but it became standard to do an attachment named cover.jpg for it.

The spec on ReplayGain seems pretty clear to me: it's the 16-bit binary format defined at http://replaygain.hydrogenaudio.org/rg_data_format.html which is two links away from the mkv spec.

You can't do that in ogg either, you need the header packets.

Flash has never supported VP7, and the only VP6 on youtube was on self-encoded sponsored channels.

1. Probably true in that most demuxers don't read matroska tags, but it's standardized (and has been for the past 5 years or so) at http://www.matroska.org/technical/specs/tagging/index.html

Whereas ogg metadata is codec-dependant. In practice though, most (not all!) codecs in ogg just use vorbis comments, where the only official tags are http://xiph.org/vorbis/doc/v-comment.html

2. Mozilla's C++ style guide hasn't been updated since like 1996, when C++ was still grossly compiler-dependant. It shouldn't be taken as anything other than a sign that that's the era in which Mozilla is stuck.

And actually Safari supports AVI in <video>.

The 9400 is still active when the 9600 is; you can use both at the same with with OpenCL for instance.

And I'd imagine that there's only one video decode ASIC between the two of them, no need to uselessly duplicate hardware.

By not overriding Apple's decoder for baseline and main profile H.264

The best explanation I've seen is http://www.kaourantin.net/2010/02/core-animation.html when you also realize that for video playback and animation in general, OpenGL > Core Animation > Quartz 2D > QuickDraw for OS X 10.2 and newer (I think QuickDraw was better pre-compositing.)

Useful error messages. Even in C gcc is lacking, let alone C++, and I'd imagine that fixing this in gcc wouldn't be/have been much easier than writing clang.

Develop all you want for free: as long as you only want to run your application on a simulated iPhone. You can't load apps onto your own device without paying $100/year or jailbreaking. Heck, you can't even use XCode to compile an app for the iPhone (not simulator) without a license.

Anyway, an additional multitasking use-case is IRC and other apps where you're in constant contact with a server. With Colloquy, for instance, right now you need to setup a server to bounce off of or else you leave all channels every time you switch apps. Of course, this class of uses is one that you don't want running when the device is off or else the battery drains quickly.

I've always felt that Apple was waiting both for their hardware to become powerful enough (the original iPod touch consistently ran out of RAM with 2 open webpages + music for instance, and page rendering wasn't exactly snappy) and also to come up with a good way of limiting the number of background processes without user involvement. You don't want every other app you launch hanging around so that when you run out of resources, the OS kills the music player which you actually wanted open.

Elliptic curve cryptography and LDPC codes are two that come to mind.

Though afaik the latter hasn't really been improved since ~1960 and were only patented after rediscovering them in 1993, and I have no clue whether progress in elliptic curve cryptography stalled due to patents or because they don't offer any practical benefits over RSA.

My guess is that the author wasn't the one who encoded either video, and the guy who did didn't know what hinting meant but enabled it anyway when exporting from QuickTime. (hinting is only ever used by Darwin Streaming Server, and only if you're doing live streaming from a pre-recorded file.)

The bad encoder comes from QuickTime having the lowest quality H.264 encoder out of any commercial encoder (and all of them being worse than x264.)

Encoding it with a good encoder would require access to the source, which I don't feel like finding if it even exists on the internet.

So instead, here's the same file with the junk stripped out: http://www.mediafire.com/?yuwj5zmmw4m

Technically, ogg, ogm, ogv, and oga all follow RFC 3533 and can legitimately be called the same file format, namely ogg. The only difference between all those extensions the codecs used; Xiph intentionally left the definition of how to map a given codec into ogg up to the codec.

Tech-wise, I don't remember any devices with a 3.5" capacitive touchscreen + multitouch before the iPhone came out. That was imo the most important hardware feature of the iPhone, given that the "accepted" mode of interaction with similar devices was a stylus on a resistive screen.

Similarly, there aren't any shipping devices with a 7-10" capacitive touchscreen. Whether or not any of the various tablets with one announced at CES beats Apple's to market, the kinks in said displays weren't ironed out before this year.

Off the top of my head:

http://www.axiotron.com/index.php?id=modbook if you want to pretend that Apple makes tablets.

http://www.alwaysinnovating.com/ smaller screen and thicker chassis but longer battery life for $300.

Various Windows laptops, harder to find since noone wanted to pay the premium for a touchscreen.

If you want a browser-only tablet, install Chrome OS or something.

$200 still is in the land of magic ponies and unicorns though.

>it's nicely coherent, has nicely orthogonal features

Obviously with exceptions, especially with the instructions added after armv4.

For instance, the allowed addressing modes vary depending on instruction: ldr allows a 12 bit offset, ldrd only an 8 bit, ldm and vld allow none, though vld allows a strided increment. Only ldr* non-exclusive allow a register offset.

Thumb-1/2 and exclusive load/store change things a bit more, but they aren't generally stuff to care about unless you're doing kernel or compiler programming. Also, none of the neon instructions can be conditionally encoded, but there isn't much reason to do that.

As for desktop arm, a massively multicore machine would be nice, but the average user doesn't care much about desktop CPU power consumption nor make good use of more than two cores. Netbooks have to watch out though.

There are really two separate issues with SEO:

1. The little legitimate stuff they do that would increase pagerank (better website design, alt text, metadata, etc.) is incredibly overpriced for the actual value, especially compared against SEO claims. But companies that don't shell out for a website designer that can do this in the first place deserve to be ripped off.

2. The even shadier SEOs will use botnet linkspam and the like. This is actively destroying the web and companies that do this do not deserve to exist period.

I re-read C99, and the reason this is allowed is not because of §6.5.2.2 p10, but rather §6.5.16 p4 as far as I can tell. Though it's weird to me that the expression (x = 2) can ever be evaluated as anything but 2.

Also, it's not illegal C, it's undefined C and compilers are only allowed to do whatever they want within the undefined area (which is larger than I expected.)

clang gives 7 9 9 7 2 2 as well. gcc gives 7 10 9 7 3 2 when targeting arm.

2,3,7 are all valid possibilities for the 4th and 6th numbers, but apparently gcc interprets the 5th as 2 + 1 somehow, which I can't see as being valid whatsoever.

You skipped over 26, 27, and 34...

There are a couple reasons you wouldn't know that (for an entire inline asm function):

1. x86_64 vs. x86_32. It's possible that you'd want to use more registers than 32-bit has. In this case, it's usually optimal to use memory operands on x86_32 but registers on x86_64.

2. gcc _will not_ allow you to use ebx in inline asm with PIC code. Likewise with ebp with frame pointer. There's no technical reason gcc couldn't just save+restore those registers around the block, but it doesn't.

3. The case in the bugreport: you have various locations in memory you want to address, and you want gcc to figure out their addresses for you. Without analysis that eliminates identical registers, the naive implementation of using 1-2 new registers per operand will quickly fail.