Encoder Is Not a State Machine | Hacker News Reader

Encoder Is Not a State Machine

subfurther.com

29 pointszoul10 comments

«[...] an encoder is not a state machine. Meaning that there need not, and probably should not be, a single base encoder.» This is not the meaning of "State machine". What I think the author means is "Two encoders for the same video codec can and should be two different state machine", or simply "The developers of video codec encoders have many different algorithmic choices, both in video quality and encoding performance".

Mirrors my worries regarding VP8. Many people don't understand the codec world, but generally there is a standard, and several implementations of that standard. An example - the standard: MPEG4 Part 2. Most people have no idea what that is, but if you tell them "DivX", they know. But if you encode a film with the DivX encoder, you will find that the XviD decoder can decode it, because they both implement the same standard.

Why is this great? Well, compare an MP3 made by the FHG encoder with one made by LAME at comparable low bitrates. Despite the fact that they both play fine on your MP3 player, phone, pc, et al, the quality per bit is so different you would expect them to be a different codec. Having separation between spec and implementation allows others to make better, faster, more effecient (not necessarily all at the same time) implementations, and if VP8 needs anything right now, it's a better implementation.

As it stands, this can't happen, and imo calling VP8 competitive with h.264 is charitable.

1) Xvid cannot decode Divx as it is and vice versa. Althrough in theory they are both implementations of MPEG-4 ASP, they both have quirks that are their own only. The decoder has to deal specifically with Divx quirks and Xvid quirks, or else there's no picture.

2) There are two independent software VP8 decoders - libvpx (Google's original) and ffvp8 (ffmpeg). As for encoder, one is libvpx, which is usable today and the other is xvp8, which is in development. So yes, there will be independent implementations. There are also other, hardware-based decoders and encoders.

1) Yes, they can. If they couldn't my DirectShow stack would need to be a lot more complicated. I have decoded XviD with DivX and vice-versa without hassle. Maybe this is to do with profiles or something? I am happy to believe you could encode something with one that doesn't decode with the other, but in theory and in practice it seems to work out in most cases.

2) My worry is how different these can be without causing problems down the line. VP8 as a specification seems comparable to early days HTML, whereas MPEG-4 part 2 or part 10 (h.264) is more like HTML4.

1) In the end, both xvid and divx (and other, like ffmpeg or nero) decoders contain fixes for divx/xvid quirks. In software, it is easy. For extra fun, get your hands on some dvd players, that claim divx support. Yes, they can decode divx, but decoding xvid is much bigger problems for them (it is not about profiles, but about bugs in produced bitstreams).

Perhaps the standard is most aptly defined in a language other than English; maybe it is best to define it in code.

Maybe. But a standard should be free from language-specific hacks and optimised code, VP8's "standard" is free from neither.

Quoted in the article from another source:

I also know that whatever leverage Google uses, they still haven’t created any positive reason to distribute video in WebM format. They haven’t created any new revenue opportunities, opened any new markets or increased the size of the pie. They’ve just made it more expensive to get your share, all in the highly ethereal pursuit of “open codec technologies.” So, if you do check your wallet, sometime soon, you’ll start to see less money in it, courtesy of Google.

How very wrong. If you make it cheaper for people to consume your video, that increases the share you can charge for yourself. Cheaper not only meaning royalty free, but also easier, more flexible, available in more places, etc., all things that are helped by an open, royalty free standard.

In theory that is. The thing is that licensing H.264 seems to be not much of a hurdle for non-open source appliances. At least I heard no one clamoring about outrageous license fees for that. If that leads to more or less universal spreading of H.264, then there is nothing to win from an open codec for producers or consumers, and only to loose for open source projects. Which in itself might be a good reason to try and hurdle H.264 adaptation.

Isn't it a bit weird to quote a review from before VP8 was open sourced that has exactly two complaints, neither of which now apply (licence costs and source availability)?

The great benefit of ISO standards like VC-1 and H.264 is that anyone can go get a reference encoder or reference decoder, with the full source code, and hack on their own product.

I don't think state machine means what this writer thinks it means.

Reply on news.ycombinator.com