> An interesting feature where coefficients were pre-aligned to mod-8 widths to presumably allow for SIMD optimisations
I have seen protocols implemented in such a way that when described on paper, they look convoluted, especially how they specify alginment "this will have this much padding, this one will be aligned on this boundary. Little endian encoding for integer values...".
However I quickly realized they basically picked a particular memory layout in a C struct generated on x86-64 architecture, by a particular compler (gcc 4), and particular OS (Linux). I imagine at some point someone implemented it like that, then they went back and wrote into a standard. It would have been nice to at least mention that in the docs footnote ("Encode these as C structs on this combination of arch/compiler/os and cast binary blobs to the struct to serialize/deserialize data in this format)
> I imagine at some point someone implemented it like that, then they went back and wrote into a standard. It would have been nice to at least mention that in the docs footnote ("Encode these as C structs on this combination of arch/compiler/os and cast binary blobs to the struct to serialize/deserialize data in this format)
That footnote could cause multiple problems. Someone might just use that C struct and expect the layout to match, which would introduce portability problems (such as if using a different target OS, as Windows and Linux have different struct layout rules). Or, conversely, someone might see that line in a proposed standard and reject it as non-portable, whereas a precise description of memory layout would not come across as such. (In particular, the memory layout of structs by GCC on x86-64 Linux matches the memory layout of structs by any compatible compiler targeting several different 64-bit architectures on several POSIXy platforms.)
> Or, conversely, someone might see that line in a proposed standard and reject it as non-portable, whereas a precise description of memory layout would not come across as such.
Yap that makes sense, I din't think of it that way first but that probably explains it.
> However, real-world files didn’t seem to match a lot of the document which was odd. All of this was buried in the small-print of course: “the core technology behind the GoPro CineForm Codec has been standardized [sic]”. So in reality existing files were not decodable by a VC-5 decoder.
This is why open source is often so much better than open standards (though the latter the was used to help create the former, in this case).
Huge kudos to the author for doing this work, as well as explaining the process.
Not sure what open source would accomplish here - without a standards paper you can't get multiple conformant players for a format, because the company can just constantly move goalposts around as much as they will.
The best way to implement video standards until now has (as pretty much everywhere else) been a good tight specification coupled with a several conforming decoders without any monopolizing the market. It keeps the vendors honest.
> This is why open source is often so much better than open standards (though the latter the was used to help create the former, in this case).
Personally, I prefer both: a standard to give documentation, motivation, and clarification, and an Open Source reference implementation (written for maximum clarity rather than optimization).
I've downloaded so much junk from the internet trying to do this but just couldn't and now I find it's so simple! Again, Thanks for sharing it. Who would have thought it would be so simple.
I'd actually be more interested in the database files that Spotify uses to manage cached tracks on Android - at the moment the UI is terrible, especially when you have 200+ tracks downloaded and are running out of space on your device.
My goal is to write an 'ncdu' application to show what files/albums are using the most space.
Apparently they actually tried unlike Grooveshark. [0] I don't think Grooveshark would have minded if someone cracked their "DRM" even while they were still in business. :)
> An interesting feature where coefficients were pre-aligned to mod-8 widths to presumably allow for SIMD optimisations
I have seen protocols implemented in such a way that when described on paper, they look convoluted, especially how they specify alginment "this will have this much padding, this one will be aligned on this boundary. Little endian encoding for integer values...".
However I quickly realized they basically picked a particular memory layout in a C struct generated on x86-64 architecture, by a particular compler (gcc 4), and particular OS (Linux). I imagine at some point someone implemented it like that, then they went back and wrote into a standard. It would have been nice to at least mention that in the docs footnote ("Encode these as C structs on this combination of arch/compiler/os and cast binary blobs to the struct to serialize/deserialize data in this format)