> 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.
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.
Q: Is it perfectly alright to incorporate the whole FFmpeg core into my own commercial product?
A: You might have a problem here. There have been cases where companies have used FFmpeg in their products. These companies found out that once you start trying to make money from patented technologies, the owners of the patents will come after their licensing fees. Notably, MPEG LA is vigilant and diligent about collecting for MPEG-related technologies.
Sorry I thought you were suggesting that ffmpeg means that products developed by Google are not subject to license fees. We were talking about the future landscape of video not what happens now: Google are investing in the future.
E264 contains MPEG LA technology. Using ffmpeg for E264 would still mean that Google will pay fees/license the technology.
I'm sure Google's action is to encourage a practical replacement for E264. Then, at least, there is grounds to negotiate better licensing terms.
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.
It's been a while since I looked at the metadata standards, but it's my memory that there are two: one that is "deprecated", supports only a few tags, and is supported by libraries,, and the "new" format you linked to, which is the "way forward" but so far completely unsupported by anything.
The specific problems I remember are that the ReplayGain tag contents are unspecified (decimal, like Vorbis/FLAC? IEEE754 half, single, double in some endianness?), there's no support for cover art, and the "examples" are all broken links. In my opinion, FLAC has the best metadata support -- Vorbis is close, but its cover art support is a catastrophe.
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 "original" 9-bit fixed-point encoding isn't widely used; most formats use a 32- or 64-bit float, or the number encoded as a string. One of the Matroska developers posted on the HydrogenAudio forums[1] saying they use a 32-bit float, but the spec he quotes later[2] is different than what's on the actual Matroska site.
Do you know if the cover.jpg standard is documented anywhere? Searching for "matroska cover.jpg" just yields a bunch of bittorrent sites.
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.
Perhaps other browsers should copy this.