
Reverse Engineering the GoPro Cineform Codec - ingve
https://medium.com/@kierank_/reverse-engineering-the-gopro-cineform-codec-7411312bfe1c
======
rdtsc
Pretty cool, I like these kinds of articles.

> 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)

~~~
JoshTriplett
> 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.)

~~~
rdtsc
> 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.

------
dankohn1
> 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.

~~~
izacus
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.

------
c-slice
Fascinating post. I wonder if anyone has tried to decode the Audible audiobook
format - ".aa"?

~~~
noobie
Spotify's ".file" has been a tough one to crack.

~~~
Wingman4l7
The only work I've seen on breaking Spotify DRM encryption was this[1], back
in 2014 and discussed on HN here[2].

[1]: [http://moyix.blogspot.com/2014/07/breaking-spotify-drm-
with-...](http://moyix.blogspot.com/2014/07/breaking-spotify-drm-with-
panda.html) [2]:

~~~
noobie
That is...genius!

------
userbinator
Wavelet image compression is itself interesting and quite intuitively simple
(if looked at in the right way):

[http://www.iquilezles.org/www/articles/wavelet/wavelet.htm](http://www.iquilezles.org/www/articles/wavelet/wavelet.htm)

------
rphl
FEC stands for forward error correction

~~~
detaro
You can edit and delete your comments, no reason to spam one-liners,
especially not without connection.

------
rphl
Http://rphlo.github.com/ there is a go pro repo

------
rphl
Interlaced stream of RTP h.264, audio stream, and FEC channel

------
rphl
[https://github.com/rphlo/GoProLiveProxy](https://github.com/rphlo/GoProLiveProxy)

------
rphl
[https://tools.ietf.org/html/rfc6184](https://tools.ietf.org/html/rfc6184)

