Diary Of An x264 Developer

07/13/2010 (3:06 am)

VP8: a retrospective

Filed under: DCT,speed,VP8 ::

I’ve been working the past few weeks to help finish up the ffmpeg VP8 decoder, the first community implementation of On2′s VP8 video format.  Now that I’ve written a thousand or two lines of assembly code and optimized a good bit of the C code, I’d like to look back at VP8 and comment on a variety of things — both good and bad — that slipped the net the first time, along with things that have changed since the time of that blog post.

These are less-so issues related to compression — that issue has been beaten to death, particularly in MSU’s recent comparison, where x264 beat the crap out of VP8 and the VP8 developers pulled a Pinocchio in the developer comments.  But that was expected and isn’t particularly interesting, so I won’t go into that.  VP8 doesn’t have to be the best in the world in order to be useful.

When the ffmpeg VP8 decoder is complete (just a few more asm functions to go), we’ll hopefully be able to post some benchmarks comparing it to libvpx.

1.  The spec, er, I mean, bitstream guide.

Google has reneged on their claim that a spec existed at all and renamed it a “bitstream guide”.  This is probably after it was found that — not merely was it incomplete — but at least a dozen places in the spec differed wildly from what was actually in their own encoder and decoder software!  The deblocking filter, motion vector clamping, probability tables, and many more parts simply disagreed flat-out with the spec.  Fortunately, Ronald Bultje, one of the main authors of the ffmpeg VP8 decoder, is rather skilled at reverse-engineering, so we were able to put together a matching implementation regardless.

Most of the differences aren’t particularly important — they don’t have a huge effect on compression or anything — but make it vastly more difficult to implement a “working” VP8 decoder, or for that matter, decide what “working” really is.  For example, Google’s decoder will, if told to “swap the ALT and GOLDEN reference frames”, overwrite both with GOLDEN, because it first sets GOLDEN = ALT, and then sets ALT = GOLDEN.  Is this a bug?  Or is this how it’s supposed to work?  It’s hard to tell — there isn’t a spec to say so.  Google says that whatever libvpx does is right, but I doubt they intended this.

I expect a spec will eventually be written, but it was a bit obnoxious of Google — both to the community and to their own developers — to release so early that they didn’t even have their own documentation ready.

2.  The TM intra prediction mode.

One thing I glossed over in the original piece was that On2 had added an extra intra prediction mode to the standard batch that H.264 came with — they replaced Planar with “TM pred”.  For i4x4, which didn’t have a Planar mode, they just added it without replacing an old one, resulting in a total of 10 modes to H.264′s 9.  After understanding and writing assembly code for TM pred, I have to say that it is quite a cool idea.  Here’s how it works:

1.  Let us take a block of size 4×4, 8×8, or 16×16.

2.  Define the pixels bordering the top of this block (starting from the left) as T[0], T[1], T[2]…

3.  Define the pixels bordering the left of this block (starting from the top) as L[0], L[1], L[2]…

4.  Define the pixel above the top-left of the block as TL.

5.  Predict every pixel <X,Y> in the block to be equal to clip3( T[X] + L[Y] – TL, 0, 255).

It’s effectively a generalization of gradient prediction to the block level — predict each pixel based on the gradient between its top and left pixels, and the topleft.  According to the VP8 devs, it’s chosen by the encoder quite a lot of the time, which isn’t surprising; it seems like a pretty good idea.  As just one more intra pred mode, it’s not going to do magic for compression, but it’s a cool idea and elegantly simple.

3.  Performance and the deblocking filter.

On2 advertised for quite some that VP8′s goal was to be significantly faster to decode than H.264.  When I saw the spec, I waited for the punchline, but apparently they were serious.  There’s nothing wrong with being of similar speed or a bit slower — but I was rather confused as to the fact that their design didn’t match their stated goal at all.  What apparently happened is they had multiple profiles of VP8 — high and low complexity profiles.  They marketed the performance of the low complexity ones while touting the quality of the high complexity ones, a tad dishonest.  More importantly though, practically nobody is using the low complexity modes, so anyone writing a decoder has to be prepared to handle the high complexity ones, which are the default.

The primary time-eater here is the deblocking filter.  VP8, being an H.264 derivative, has much the same problem as H.264 does in terms of deblocking — it spends an absurd amount of time there.  As I write this post, we’re about to finish some of the deblocking filter asm code, but before it’s committed, up to 70% or more of total decoding time is spent in the deblocking filter!  Like H.264, it suffers from the 4×4 transform problem: a 4×4 transform requires a total of 8 length-16 and 8 length-8 loopfilter calls per macroblock, while Theora, with only an 8×8 transform, requires half that.

This problem is aggravated in VP8 by the fact that the deblocking filter isn’t strength-adaptive; if even one 4×4 block in a macroblock contains coefficients, every single edge has to be deblocked.  Furthermore, the deblocking filter itself is quite complicated; the “inner edge” filter is a bit more complex than H.264′s and the “macroblock edge” filter is vastly more complicated, having two entirely different codepaths chosen on a per-pixel basis.  Of course, in SIMD, this means you have to do both and mask them together at the end.

There’s nothing wrong with a good-but-slow deblocking filter.  But given the amount of deblocking one needs to do in a 4×4-transform-based format, it might have been a better choice to make the filter simpler.  It’s pretty difficult to beat H.264 on compression, but it’s certainly not hard to beat it on speed — and yet it seems VP8 missed a perfectly good chance to do so.  Another option would have been to pick an 8×8 transform instead of 4×4, reducing the amount of deblocking by a factor of 2.

And yes, there’s a simple filter available in the low complexity profile, but it doesn’t help if nobody uses it.

4.  Tree-based arithmetic coding.

Binary arithmetic coding has become the standard entropy coding method for a wide variety of compressed formats, ranging from LZMA to VP6, H.264 and VP8.  It’s simple, relatively fast compared to other arithmetic coding schemes, and easy to make adaptive.  The problem with this is that you have to come up with a method for converting non-binary symbols into a list of binary symbols, and then choosing what probabilities to use to code each one.  Here’s an example from H.264, the sub-partition mode symbol, which is either 8×8, 8×4, 4×8, or 4×4.  encode_decision( context, bit ) writes a binary decision (bit) into a numbered context (context).

8×8: encode_decision( 21, 0 );

8×4: encode_decision( 21, 1 ); encode_decision( 22, 0 );

4×8: encode_decision( 21, 1 ); encode_decision( 22, 1 ); encode_decision( 23, 1 );

4×4: encode_decision( 21, 1 ); encode_decision( 22, 1 ); encode_decision( 23, 0 );

As can be seen, this is clearly like a Huffman tree.  Wouldn’t it be nice if we could represent this in the form of an actual tree data structure instead of code?  On2 thought so — they designed a simple system in VP8 that allowed all binarization schemes in the entire format to be represented as simple tree data structures.  This greatly reduces the complexity — not speed-wise, but implementation-wise — of the entropy coder.  Personally, I quite like it.

5.  The inverse transform ordering.

I should at some point write a post about common mistakes made in video formats that everyone keeps making.  These are not issues that are patent worries or huge issues for compression — just stupid mistakes that are repeatedly made in new video formats, probably because someone just never asked the guy next to him “does this look stupid?” before sticking it in the spec.

One common mistake is the problem of transform ordering.  Every sane 2D transform is “separable” — that is, it can be done by doing a 1D transform vertically and doing the 1D transform again horizontally (or vice versa).  The original iDCT as used in JPEG, H.263, and MPEG-1/2/4 was an “idealized” iDCT — nobody had to use the exact same iDCT, theirs just had to give very close results to a reference implementation.  This ended up resulting in a lot of practical problems.  It was also slow; the only way to get an accurate enough iDCT was to do all the intermediate math in 32-bit.

Practically every modern format, accordingly, has specified an exact iDCT.  This includes H.264, VC-1, RV40, Theora, VP8, and many more.  Of course, with an exact iDCT comes an exact ordering — while the “real” iDCT can be done in any order, an exact iDCT usually requires an exact order.  That is, it specifies horizontal and then vertical, or vertical and then horizontal.

All of these transforms end up being implemented in SIMD.  In SIMD, a vertical transform is generally the only option, so a transpose is added to the process instead of doing a horizontal transform.  Accordingly, there are two ways to do it:

1.  Transpose, vertical transform, transpose, vertical transform.

2.  Vertical transform, transpose, vertical transform, transpose.

These may seem to be equally good, but there’s one catch — if the transpose is done first, it can be completely eliminated by merging it into the coefficient decoding process.  On many modern CPUs, particularly x86, transposes are very expensive, so eliminating one of the two gives a pretty significant speed benefit.

H.264 did it way 1).

VC-1 did it way 1).

Theora (inherited from VP3) did it way 1).

But no.  VP8 has to do it way 2), where you can’t eliminate the transpose.  Bah.  It’s not a huge deal; probably only ~1-2% overall at most speed-wise, but it’s just a needless waste.  What really bugs me is that VP3 got it right — why in the world did they screw it up this time around if they got it right beforehand?

RV40 is the other modern format I know that made this mistake.

(NB: You can do transforms without a transpose, but it’s generally not worth it unless the intermediate needs 32-bit math, as in the case of the “real” iDCT.)

6.  Not supporting interlacing.

THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU.

Interlacing was the scourge of H.264.  It weaseled its way into every nook and cranny of the spec, making every decoder a thousand lines longer.  H.264 even included a highly complicated — and effective — dedicated interlaced coding scheme, MBAFF.  The mere existence of MBAFF, despite its usefulness for broadcasters and others still stuck in the analog age with their 1080i, 576i , and 480i content, was a blight upon the video format.

VP8 has once and for all avoided it.

And if anyone suggests adding interlaced support to the experimental VP8 branch, find a straightjacket and padded cell for them before they cause any real damage.

52 Responses to “VP8: a retrospective”

  1. Mikko Rauhala Says:

    You mentioned the goldenalt thing on #vp8 before and jimbankoski said he’d make sure it gets fixed. That not happen yet, then?

  2. Dark Shikari Says:

    @Mikko

    Not sure. I was mainly citing it as an example of something where it isn’t immediately obvious what the right thing to do is — on the one hand, Google says libvpx is always right — on the other hand, it’s clearly blatantly wrong.

    Fortunately this particular case isn’t a real big problem, as the official encoder doesn’t generate streams that use that feature.

  3. Amadeus Says:

    With the huge amount of work that have been put into the decoder now in ffmpeg.

    What’s your take on implementing the encoder? Harder/easier when the decoder is in place?

  4. Red Says:

    This seems like a real mess. How come that Opera managed to release a (supposedly) compatible WebM decoder?

  5. Pegasus Says:

    Just an aftertought, since you guys are the experts … have you tought about an ideal video codec outside of the frames of current patents, standards and specs and what it would look like?

  6. Dark Shikari Says:

    @Amadeus

    Well, now that we have a decoder, we’re more confident with respect to what libvpx actually does. Google is *already* referring people to libavcodec as a VP8 reference!

    I don’t think it’ll make an encoder much easier though.

    @Red

    Are you sure they didn’t just adapt Google’s libvpx?

  7. Kierank Says:

    @Red

    Opera uses libvpx through GStreamer.

  8. onitake Says:

    no interlacing? this is really fantastic.
    such a “feature” is a definite thing of the past and has simply no place in the age of digital video. if someone requires interlaced frames, they should interlace at the last stage of the video decoding process, not when authoring content. you easily avoid breaking it for everyone else that way.

  9. D3C0D3R Says:

    >>>>It’s effectively a generalization of gradient prediction to the block level — predict each pixel based on the gradient between its top and left pixels

    something similar i’ve seen in H.265 proposals, but there it was more sophisticated and compression-wise.
    And even more sophisticated is JCTVC-A025 with their LIP and RIP.

    >>>Google is *already* referring people to libavcodec as a VP8 reference!
    *ROFL*,

    P.S. Dark, what means “pull a Pinocchio” ?

  10. skal Says:

    about horizontal transform: mpeg2/4 implementation of the 8×8 transform was transpose-free (hi Walken!), using some cool pmaddwd artillery for doing its horizontal thing. Might even be easier to do the same for vp8′s 4×4 horizontal pass, all the more it’s just a butterfly + rotation + butterfly.

  11. skal Says:

    also: by vertically working on 4 coefficients only, you under-utilize modern CPUs 8-words register width. Doing the vertical idct with SSE2 register, you only use half of their width. By doing a real SSE2 horizontal idct instead, you can process two 4-coeffs rows at a time, as they all fit into 1 reg and the exact same ops are needed for both. Might offset the transposing work.

    ps: 486 is a cool id for a post :)

  12. yaowu Says:

    Take a look at http://review.webmproject.org/#patch,sidebyside,267,4,vp8/encoder/x86/dct_sse2.asm. It shows how to do the transform without transpose. It is forward dct, but should not be difficult to do the same given the similarity between the forward and inverse.

  13. Relgoshan Says:

    @Red: Opera began with a simple, flat port of libvpx wrapped to work inside GStreamer’s framework. It’s not fast at all but it works just fine on most PCs. They are working out a better solution for a later release, and they are donating to (collaborating with?) the main GStreamer libraries.

    If you run Linux, Opera can play anything you’ve GStreamer libs for. But in addition, any GStreamer-capable media player on your system will now play WebM using Opera’s lib.

    On complexity of coding and speed of execution, there is plenty to be gained with the assumption of multicore 64-bit CPUs. Only thing is, lots of people don’t have one. The most efficiency is more important in the encoder, with redundancy an acceptable cost to the programmer. For decoding, simplicity is best (esp if you can at least ensure smooth framerates for 95% of the people using it).

    Dark, how rough is that intensive deblocking filter? Is there any hope of porting it to an existing general-hardware solution, or are stream processors totally incapable of being adapted for such complexity?

  14. Pengvado Says:

    @skal:
    pmaddwd-based idct is a win only if you want 32bit intermediates. I have written a 16bit sse2 1D/transpose/1D idct, and it’s faster than Walken’s. I haven’t committed it to ffmpeg because it would add to the proliferation of different rounding modes.
    4×4: do 2 idcts at once.

  15. Dark Shikari Says:

    @Relgoshan

    It’s not horrifically complicated instruction-wise; any SIMD implementation is just going to be a ton of compares, maxes, mins, saturating arithmetic, and bitmath. If there’s any problem, it might stem from the fact that the loopfilter was written in assembly first and then backported to C — thus it was designed entirely for x86 assembly, and so might not do as well on other architectures.

    I doubt it though. It doesn’t do anything particularly insane. If anything, it might run better on other architectures due to it needing a decently large register count.

  16. mofle Says:

    Vote for more posts on mistakes in modern codecs. Really interesting to read.

  17. Amadeus Says:

    How come you know so much about Assembly? have you been coding Amiga demos or games?

    In regards to optimization. Have OpenCL been considered in FFMPEG? Or are GPU’s not good at codec arithmetic?

    Or is OpenCL not a direction FFMPEG don’t want to go?

  18. Dark Shikari Says:

    @Amadeus

    I know about assembly because any video or audio processing ends up including a lot of SIMD. It’s not that hard to learn.

    OpenCL is generally not suited to decoding workloads, as they aren’t highly parallel.

  19. Amadeus Says:

    @Dark Shikari:

    I’ll be damn! I though compression and decompression scaled perfectly with the number of cores.

    I then assume that new codecs (H.265?) are structured to parallelize well?

  20. Dark Shikari Says:

    @Amadeus

    No, they generally aren’t. Entropy decoding, which makes up quite a bit of decoding time, is an inherently linear process. Slices and such can allow parallelization, but that doesn’t help OpenCL because the whole mechanism by which GPUs work is having a lot of threads doing the same thing. Entropy decoding is inherently branchy, so that won’t work.

  21. Amadeus Says:

    @Dark Shikari

    Thanks for clearing that out.

  22. I.K. Says:

    @post 20.

    a few years back there were an MPlayerMP. Are that still in the works, now that you brought up that codecs can be optimized for many branches?

  23. Jim Leonard Says:

    Until I can put 1080p @ 60fps content on a blu-ray, I love interlacing. I say that with gritted teeth, but it’s the only way to get 1920-pixel-wide video onto a blu-ray at 60 images per second.

  24. techer Says:

    @Dark Shikari:

    I don’t know how much you’ve examined the libvpx encoder, but do you know if there’s room for improvement in video quality, and if so, how much? Looking at the results on compression.ru, libvpx seems to perform approximately as well as DivX H.264, but worse than x264, indicating encoder implementation is important.

    The libvpx is *very* slow in the tests; is this due to the implementation, or inherent to the “bitstream guide”?

  25. Dark Shikari Says:

    @techer

    libvpx being slow is entirely an implementation problem — there’s no reason you couldn’t write an encoder of similar speed to x264.

    Note that DivX H.264, like all the other encoders tested that were given a score, did reach the speed targets. Thus, “libvpx performs approximately as well as DivX H.264″ is disingenuous, as you’re comparing to a much slower encoder (libvpx), and slower means that it has time to use significantly better algorithms.

    There’s definitely room for improvement in libvpx. PSNR-wise, probably not too much; I doubt they’ll get more than 5-10% more out of it. SSIM-wise, there’s a lot more to be gained, due to the lack of adaptive quantization. Psy-wise, there’s even more to be gained, since they have no psy optimizations at all. Of course, the graphs by MSU don’t capture psy optimizations either.

  26. Reimar Says:

    About the “TM prediction mode”. May I suggest a look at libavcodec/truemotion*.c? I think tm2_apply_deltas might be it.
    That should be enough to figure out the name…

  27. Pengvado Says:

    tm2_apply_deltas is a form of LPC, not a block prediction. i.e. it does T+L-TL where those represent immediate neighbors, not block edges.

  28. Relgoshan Says:

    Dark, what I recalled hearing was that current general-use graphics processing aids (like the HW video logic in some (many?) smartphones) could not easily be programmed to assist the decoding of VP8 video? Or if so, more of the work would need to be done by the general-use ARM CPU due to structural incompatibility in the dedicated graphics accelerator?

    It’s one thing to say that decoding is not compatible with multitudes of tiny CPUs, but many graphics cards enable low-demand viewing of BLuRay discs using drivers that leverage their 512+ cores. Obviously something is going on here, so what parts of the process CAN be offloading to dumb pixel processors?

  29. Orthochronous Says:

    @Relgoshan:

    I don’t know if it’s used in any smartphones yet, but one of the things I’ve found that’s frustrating is that the Tegra ARM-derived chips deliberately don’t have the SIMD (called NEON) hardware that other modern ARM cores do. So it’s unlikely to be possible to do VP8 processing logic at acceptable speed. Other ARM chips may be fast enough with careful programming.

    (The official NVidia line is apparently that Tegra has integrated graphics that you should use for decoding output graphical output. To which I say: Yeah, but I want to analyse images [for use in augmented reality] rather than decode a standard format, so the GPU isn’t a suitable replacement for NEON in the CPU. Gahh.)

  30. Relgoshan Says:

    So NVidia wants all SIMD to be done with the graphics core, meaning non-graphic apps which could benefit will instead totally suck?

    I guess it depends whether this Tegra will contain a subset of CUDA-style logic, or some other programmable system. By extension it will be either the Best or Worst for implementing VP8 in mobile. Sounds harsh.

  31. Orthochronous Says:

    Personally I think the bigger problem is that Tegra and SIMD-capable ARM chips are going to require very different codebases, which is going to mean more coding man-hours and that regression testing has to be done in larger contexts (again increasing man-hours). Dark Shikari posted on this blog a while ago about how figuring out a way to generate both x86 and x86-64 assembly code from one code base rather than having two separate ones eased a lot of headaches the x264 developers were having: this has the potential to be just as time-sapping.

  32. IL Says:

    I kind of agree with Jim Leonard – Blu-Rays and most digital TV is limited to level 4 or 4.1. So your options are:

    * 1080p at 30frames/s
    * 720p at 60frames/s
    * 1080i at 60fields/s

    I’ve tested all of them, even with different resizers for 720 including very sharp ones (Lanczos with 3 or 4 taps), and 1080i is definitely the best for stuff that’s 60fps to begin with. The deinterlacers in modern TVs and graphics cards are incredible, you really can’t tell it was interlaced in the first place. Thin 1px horizontal lines are perfectly stable, both horizontal end vertical pans look perfect, there’s never a single trace of stairsteping in diagonal lines or combing.

    Interlacing is a pretty clever compression method which selectively gives you spatial or temporal resolution as needed, I guess it’s a conceptually similar idea to mbtree / temporal RDO. Without it you need to double the number of pixels/second to be compressed, which surely is more expensive in terms of computation and bitrate (even if progressive stuff is simpler to encode).

    The “must-deinterlace-everything-before-encoding” craze has ruined enough digital videos, as most people do half-framerate deinterlacing, and 30fps are utterly disgusting. Even bob() is better than that shit.

  33. Relgoshan Says:

    Incidentally you just answered that other guy’s question from earlier. x264 has figured out how to optimize for both x86 and x86-64 with minimal changes? That’s great!

    But I agree with you on the issue itself; Tegra will be a serious problem for coders, probably even if it CAN show a performance leap in specially written apps. The point of combining both SIMD and CUDA is to multiply the available computing power; switching one for the other is a dirty trick that doesn’t help any programmers.

  34. Orthochronous Says:

    The relevant post is

    http://x264dev.multimedia.cx/?p=191

  35. Kelly Clowers Says:

    I thought Tegra2 was supposed to be coming out soon with an A8 or A9 core (and thus NEON) instead of Tegra1′s ARM11 core (no NEON)?

  36. Orthochronous Says:

    I’m not an expert (I really only care about programming the bloomin’ things) but I gather the situation with every ARM design is that it’s designed to be modular and licensees can choose to drop bits very easily. Down this thread someone from nvidia developer relations says Tegra2 has no SIMD.

    http://tegradeveloper.nvidia.com/tegra/forum/tegra-250-devkit-hw-documentation

  37. Dark Shikari Says:

    @IL

    The hardware/CPU power necessary to do good enough deinterlacing is much greater than the hardware necessary to just decode 1080p60 in the first place.

    Furthermore, having worked at a broadcast company, every single 1080i stream we ever received, ever, was shit. I would have happily exchanged every single 1080i stream for 720p60: the bitrate was simply not high enough to make it worth it.

  38. Relgoshan Says:

    Thanks for the links. That helped me a great deal.

  39. tinef Says:

    …every 1080i stream was sh_t??? where were the streams received from and what was the bit rate? I can’t believe “every single” 1080 stream received at 40+ Mbps MPEG2 all looked like sh_t.

    Deinterlacing in consumer stuff is not great but it has improved, however it’s not come as far in cost sensitive items such as cable boxes.

    Your point about processing power is well taken, and is true not only for deinterlace but format/standards conversion as well.

    As for exchanging 1080 for 720 giving, up horizontal resolution is never a good idea!

  40. Dark Shikari Says:

    @tinef

    Who broadcasts in 40mbit MPEG-2? Broadcast is generally 5mbit-7mbit H.264 or 12-18mbit MPEG-2. At those rates, “HD” is a joke to begin with; 1080i just exacerbates it.

  41. anonymous Says:

    Do you think interlacing will also be supported by h.265?

  42. Relgoshan Says:

    I’ll just be happier when they stop using makeup and lights designed for analog broadcast. :) And run a few shows worth watching.

  43. tinef Says:

    @DS

    agree, no one broadcasts at those rates, we collect and distribute at high rates where 1080 HD is very good.

    also agree at the rates you note HD delivered to the home is a joke and it’s only going to get worse.

    Your work is excellent, I’m enjoying a being schooled and entertained -

  44. Relgoshan Says:

    I just noticed that VLC is now up to 1.1.1, is it using the scratch-built webm driver that you folks have been working on? Or if not, is this something that will come in the future?

  45. funman Says:

    Usually the FFmpeg library shipped with Windows and OSX binaries of VLC isn’t upgraded on minor versions to avoid regressions, but it should come with VLC 1.2

    That is unless VLC devs think upgrading FFmpeg in the next 1.1.x is worth the potential regressions.

  46. Relgoshan Says:

    Just curious, the 1.1.x apparently has many changes to the actual codecs.

  47. yesgrey Says:

    @DS,
    You say that: “if told to “swap the ALT and GOLDEN reference frames”, overwrite both with GOLDEN, because it first sets GOLDEN = ALT, and then sets ALT = GOLDEN.”
    but that means that both are overwritten with ALT, not GOLD… Am I missing something?

  48. Mike Says:

    I hated interlacing ever since I first had the misfortune to deal with it on Amiga. Watching that flickering piece of hell made me a very unhappy camper. It caused me to promptly buy an überfast monitor with more radiation than a nuclear meltdown. When I later in life read about 1080i on consoles I was like whaaat? This is post 2000 and there is no justification for using interlace anymore. There was no reason back in 1995 either, certainly not now. All references to that hideous piece of history should be collected into a huge spaceshuttle aimed at the sun. CRT is dead, and with it interlacing. Get over it.

  49. Dark Shikari Says:

    @yesgrey

    I reversed the two, my mistake. Point still stands though.

  50. Dino Says:

    @DS,

    can you give us a comment about recent new release of VP8?
    http://blog.webmproject.org/2010/10/vp8-codec-sdk-aylesbury-release.html
    Really improved? Fruit of your suggestions?

  51. Dark Shikari Says:

    @Dino

    Most of the improvements are largely fixing stupid things and adding a few missing features like trellis quantization. There haven’t been any psychovisual optimizations yet, but there’s a patch from a Theora dev for basic activity masking (though it’s been sitting in their review tool for a month now…)

  52. Damien Says:

    Like it or not, 1080i60 is the most ubiquitous video format of our time. It’s the format used by every current camcorder, HD sports broadcast etc. I’ll take it over 720p60 every time. Obviously 1080p60 would be much better but unfortunately it’s not part of the current specs and isn’t likely to be any time soon so dismissing interlacing is pig-headed, short-sighted and shows a fundamental lack of understanding of the video landscape.

Leave a Reply