

Encoder Is Not a State Machine - zoul
http://www.subfurther.com/blog/2011/01/13/an-encoder-is-not

======
gosub
«[...] 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".

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

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

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

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

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

------
ZeroGravitas
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._

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

