Break all video frames into blocks, say, 4x4 ones, as usual.
Run a clustering on those blocks (lots of them!) using, say, Frobenius 
norm for distance.

Find mean or median for each such cluster.

For each block of each frame we need to find and encode cluster 
identifier. Our first video approximation will be a mean image of that 
cluster.

Cluster ids can be encoded efficiently by taking into account position 
in image (say, blocks on top are likely to be sky) and previous frame. 
(In many cases cluster id doesn't change).

This crude image approximation can be further refined by calculating 
difference between actual block and cluster mean and encoding this 
difference using KLT. KLT will be different for each cluster.

....

Now tell me why it won't work :). I know that modern video compression 
algorithms use some clever frame decorrelation and psychovisual models, 
but would something like I described above work at least as some crappy 
video codec?

....

Rationale: with scheme described above drawing actual pixels on screen 
is incredibly simple and can easily be accelerated even with old 
versions of OpenGL: for each block you draw a bunch of textured rectangles.

It is also easily scalable: if hardware capabilities or bandwidth is 
lacking, just skip low-energy components of KLT which encode block 
difference. So you'll never see lagging video with this scheme, just 
loss of details.

Motivation: I'm kinda shocked that I cannot comfortably watch youtube 
videos on my 1.6 GHz laptop. Sometimes it lags, sometimes I need to 
switch quality, sometimes I have to run it in a small window. Ugh...
I want to make a proof-of-concept codec which would provide smooth video 
playback under any conditions.

On 6/29/2012 5:35 AM, Alex Mizrahi wrote:
> Break all video frames into blocks, say, 4x4 ones, as usual.
> Run a clustering on those blocks (lots of them!) using, say, Frobenius
> norm for distance.
>
> Find mean or median for each such cluster.
>
> For each block of each frame we need to find and encode cluster
> identifier. Our first video approximation will be a mean image of that
> cluster.
>
> Cluster ids can be encoded efficiently by taking into account position
> in image (say, blocks on top are likely to be sky) and previous frame.
> (In many cases cluster id doesn't change).
>
> This crude image approximation can be further refined by calculating
> difference between actual block and cluster mean and encoding this
> difference using KLT. KLT will be different for each cluster.
>
> ...
>
> Now tell me why it won't work :). I know that modern video compression
> algorithms use some clever frame decorrelation and psychovisual models,
> but would something like I described above work at least as some crappy
> video codec?
>

it "could" work, but whether or not it would get good performance, 
compress well, and not look like crap, is a bit more debatable.


there is a reason that most major video codecs use at least vaguely 
JPEG-like and MPEG-like strategies (8x8 DCT blocks, color decorrelation, 
and motion-compensation).

partly as they actually compress reasonably well and are not too costly 
to decode in real-time.


meanwhile:
I had recently imagined (once again) doing something similar to PNG but 
for video;
basically, using scanline filtering and motion prediction rather than 
block-based (note that for x-offset, likely the scanline would wrap 
around or similar);
my current motivation was more related to codec decode speed though 
(mostly, since multiple videos will be streamed in at the same time).

I hadn't really gotten to it, mostly as for now things work "well 
enough" with MJPEG (in a somewhat hacked/extended form), whereas with a 
custom codec, no one would be able to see the videos apart from needing 
a special player or similar.


IOW: each scanline has:
1 or 2 bytes for the filter;
1/2 byte x-offset, 1/2 byte y-offset (VLI);
filtered scanline pixels.

the filters would likely differ from those in PNG, and likely include 7 
sample points:
A,B,C,- (like in PNG)
E,F,G,H (likewise, but prior frame).

the 2nd filter byte would likely be for color-filtering modes (possibly 
including some lossy options).

back-end storage would likely use a deflate-like compression scheme 
(likely adapted from my current network protocol, it uses LZ77 and a 
64kB sliding window, but differs mostly in that it uses markers and 
disjoint Huffman tables more like JPEG, albeit still using a more 
Deflate-like table representation, albeit using rice-coding in place of 
Huffman coding for the tables).

possibly, AVI would be used as the container format.


I tried a vaguely similar idea before, but this prior version was not 
significantly smaller than a collection of individually-coded PNG frames.

MJPEG later won out as it worked and it was at least "sort of" common, 
but the JPEG decoding is itself a little costly.

PNG decoding itself also has a bottleneck (namely, given the Paeth 
filter has several conditional jumps, it itself can eat a lot of 
clock-cycles, itself becoming actually the main time-waster in PNG 
decoding vs even inflating the data, so probably a simpler "(A+B)-C" or 
similar filter would be used instead).

so, it is more a tradeoff of either going this route (considering a 
custom/non-standard codec), or seeing about trying to optimize my MJPEG 
decoder more (eventually) and staying with this.


> ...
>
> Rationale: with scheme described above drawing actual pixels on screen
> is incredibly simple and can easily be accelerated even with old
> versions of OpenGL: for each block you draw a bunch of textured rectangles.
>

not actually likely to perform better than simply loading the video 
frames into a texture and drawing said texture.

this is typically how I do video-streaming onto surfaces, and it 
actually seems to perform moderately well if one knows what they are 
doing (note: no mipmaps or texture compression, say, using GL_NEAREST 
for the minimization filter).


> It is also easily scalable: if hardware capabilities or bandwidth is
> lacking, just skip low-energy components of KLT which encode block
> difference. So you'll never see lagging video with this scheme, just
> loss of details.
>

theoretically could also be done with a DCT-based codec.

in practice, this is unlikely, and either way it is likely that the 
codec will display a full-resolution framebuffer.


> Motivation: I'm kinda shocked that I cannot comfortably watch youtube
> videos on my 1.6 GHz laptop. Sometimes it lags, sometimes I need to
> switch quality, sometimes I have to run it in a small window. Ugh...
> I want to make a proof-of-concept codec which would provide smooth video
> playback under any conditions.
>

this is likely because people keep going for H.264 and similar, which 
tends to be fairly costly to decode.

a lot of this isn't due to the "basic" compression technology, but due 
to some of the added things they put onto it (improve compression and 
perceptual quality, such as CABAC and mandatory deblocking filters and 
so on).


if it were MPEG-1, there probably wouldn't be nearly so much of an issue 
here regarding decoder performance.

> it "could" work, but whether or not it would get good performance,
> compress well, and not look like crap, is a bit more debatable.

Right after posting this I realized it sounds a lot like vector 
quantization, and quick google search revealed that there were indeed 
some vector quantization-based codecs.

Notably, Cinepack, it could easily decode videos on 25 MHz CPUs (and 
even slower ones), but video quality and bitrate weren't good at all.

So my intuition was more-or-less right.

But I think it might be possible to implement much better VQ based codec 
now.

> there is a reason that most major video codecs use at least vaguely
> JPEG-like and MPEG-like strategies (8x8 DCT blocks, color decorrelation,
> and motion-compensation).

These standards are made with streaming in mind. Also real-time encoding 
is a big thing.

But I would argue that if you target digital distribution via Internet 
or playing files on disk it might lead to different design decisions.

For example, you might want to use a large codebook which is used for 
whole file or even a set of files: its size would still be negligible 
compared to whole size of video. But as this codebook is required by 
everybody who watches video it can be downloaded faster due to caching 
and/or P2P distribution.

But you cannot have such codebook if you target TV streaming, for example.

> partly as they actually compress reasonably well and are not too costly
> to decode in real-time.

Sure.

> meanwhile:
> I had recently imagined (once again) doing something similar to PNG but
> for video;

At 1 Mbit/sec and 24 fps you have only 5200 bytes to encode a frame.
For 640x480 frames it means 0.135 bits per pixel. That's... not much.
If you send delta for each pixel, at least 98% of deltas must be zeros.

With block-based codecs errors are represented mostly as block, ripple 
and wrong color visual artifacts, which are usually not very noticeable 
in a moving picture.

But with a pixel-based one, as I understand, you only have a choice to 
update a pixel or not update it, so errors will be represented as a 
'stale' pixels.

It might look really weird, frames would be seen as torn apart.

Or maybe I'm missing something?

> back-end storage would likely use a deflate-like compression scheme
> (likely adapted from my current network protocol, it uses LZ77 and a
> 64kB sliding window,

Do you think it would work much better than encoding each delta value 
individually using some entropy coder? It might be better for base 
frames, but are deltas going to have some distinctive patterns?

> so, it is more a tradeoff of either going this route (considering a
> custom/non-standard codec), or seeing about trying to optimize my MJPEG
> decoder more (eventually) and staying with this.

Try Cinepak :)
Wikipedia mentions other VQ-based codecs, maybe they will suit your needs.

>> Rationale: with scheme described above drawing actual pixels on screen
>> is incredibly simple and can easily be accelerated even with old
>> versions of OpenGL: for each block you draw a bunch of textured
>> rectangles.

> not actually likely to perform better than simply loading the video
> frames into a texture and drawing said texture.

KLT decoding is slow because it requires multiply and add for each pixel 
color for each KLT vector element.

I.e. with 4x4 RGB blocks you need 4x4*3 = 48 multiplies and adds for 
each pixel. (For a lossless decoding which doesn't truncate any components.)

If you're decoding 2 megapixel video on 1 GHz CPU with 24 fps, you have
10^9/(2*10^6)/24 = 20.83 cycles per pixel

So it's rather hard to do this, if not impossible.

OTOH for video card hardware it's just texturing, and it can do a lot of it.

Note that it can also work with WebGL or maybe even simpler JS-based 
APIs. Which could be a killer feature -- video codec done in JS, no

> theoretically could also be done with a DCT-based codec.

It's much harder, as I understand. Predictive coding assumes that you've 
correctly reconstructed previous frames, if you've cut corners you'll 
get some bad artifacts.

Also I'm not sure that zeroing out some components would make DCT 
calculation much faster, although I know embarrassingly little about it.

> this is likely because people keep going for H.264 and similar, which
> tends to be fairly costly to decode.

Well, I guess so.
But bandwidth is a problem too. youtube often get congested, so only 
low-quality streams can be played smoothly.

I think it's kinda embarrassing that they don't use auto quality scaling.

Actually there is a technology for this: 
http://en.wikipedia.org/wiki/Scalable_Video_Coding
But I guess it's too advanced for youtube to use :)

On 7/1/2012 6:55 AM, Alex Mizrahi wrote:
>> it "could" work, but whether or not it would get good performance,
>> compress well, and not look like crap, is a bit more debatable.
>
> Right after posting this I realized it sounds a lot like vector
> quantization, and quick google search revealed that there were indeed
> some vector quantization-based codecs.
>
> Notably, Cinepack, it could easily decode videos on 25 MHz CPUs (and
> even slower ones), but video quality and bitrate weren't good at all.
>
> So my intuition was more-or-less right.
>
> But I think it might be possible to implement much better VQ based codec
> now.
>

there was the RoQ codec used some by id Software (this was VQ based).

I was using MJPEG-AVIs for roughly similar stuff which id used RoQ for.


>> there is a reason that most major video codecs use at least vaguely
>> JPEG-like and MPEG-like strategies (8x8 DCT blocks, color decorrelation,
>> and motion-compensation).
>
> These standards are made with streaming in mind. Also real-time encoding
> is a big thing.
>
> But I would argue that if you target digital distribution via Internet
> or playing files on disk it might lead to different design decisions.
>

I disagree that they are "necessarily" different.

for example, they are commonly used with the AVI container format, which 
is poorly designed for streaming.


> For example, you might want to use a large codebook which is used for
> whole file or even a set of files: its size would still be negligible
> compared to whole size of video. But as this codebook is required by
> everybody who watches video it can be downloaded faster due to caching
> and/or P2P distribution.
>
> But you cannot have such codebook if you target TV streaming, for example.
>

I don't personally like codebooks in-general (especially ones not stored 
with the video).


>> partly as they actually compress reasonably well and are not too costly
>> to decode in real-time.
>
> Sure.
>
>> meanwhile:
>> I had recently imagined (once again) doing something similar to PNG but
>> for video;
>
> At 1 Mbit/sec and 24 fps you have only 5200 bytes to encode a frame.
> For 640x480 frames it means 0.135 bits per pixel. That's... not much.
> If you send delta for each pixel, at least 98% of deltas must be zeros.
>

my use-case is different:
most videos are 256x256 or 512x512, and may consist of multiple 
"component layers":
RGBA, Normal-map XYZ + Depth, Specular, Luma.

typically, I don't worry about fixed bit-rate, but at MJPEG am getting 
around 133kbps with 256x256 @ 10Hz for these sorts of videos.

granted, the encoder does do a little trickery, mostly along the lines 
of omitting Huffman tables for many images (allowed by MJPEG), and 
skipping out on component layers for which it does not detect a change 
(the decoder will simply skip out on updating the frame image for this 
layer if this is the case). given the way JPEG works though, all frames 
require the RGB layer.

something more MPEG-like (with deltas) could be better, but none would 
be terribly convenient to implement and hack extensions onto (near the 
top of the list would probably be the Theora codec).


the issue though is that at present, a lot of decoding time goes into 
the process of taking the block-value pixels, re-assembling them into 
scanlines, and doing the YUV->RGB conversion.

this could be made a little faster, say, by hard-coding for 4:2:0 and 
similar, but this is only likely to be a modest speedup.

(ironically, the IDCT isn't really a large time-waster, but in this case 
has already been micro-optimized into a pile of fixed-point integer math).

some of this "could" be faster by using SSE stuff, but as of yet this 
isn't really done.


> With block-based codecs errors are represented mostly as block, ripple
> and wrong color visual artifacts, which are usually not very noticeable
> in a moving picture.
>
> But with a pixel-based one, as I understand, you only have a choice to
> update a pixel or not update it, so errors will be represented as a
> 'stale' pixels.
>
> It might look really weird, frames would be seen as torn apart.
>
> Or maybe I'm missing something?
>

lossless is possible.

for a PNG-like codec, if lossly, it involves a little bit more work, 
mostly that the encoder has to simulate the decoded output and base most 
calculations off of this.

say, for encoding, one has 2 image buffers:
one for the input image being encoded;
the other for the simulated output image (used for predictions).

it is possible to, after calculating deltas, to quantize them, and then 
calculate the value for the output image based on this quantized value.

in this case, losses introduced will be manifested in the predictor, 
which will in turn produce results based on the "degraded" version of 
the image.


the decoder will work about the same regardless of whether the encoding 
is lossy or lossless.

it is in-fact possible to implement lossy-PNG as well (using a similar 
strategy), but there isn't generally as much point in doing so.


the main advantage would be that a PNG-like codec could be potentially 
be made to have somewhat higher decoder speeds than an MJPEG or 
MPEG-like codec, at the big downside that the compression will probably 
be worse (especially if lossless).


>> back-end storage would likely use a deflate-like compression scheme
>> (likely adapted from my current network protocol, it uses LZ77 and a
>> 64kB sliding window,
>
> Do you think it would work much better than encoding each delta value
> individually using some entropy coder? It might be better for base
> frames, but are deltas going to have some distinctive patterns?
>

if all works well, deltas will be mostly 0s, so the LZ77 compressor 
works mostly as a glorified RLE encoder (the usual goal is to get as 
much of the frame to be runs of 0 as possible, or failing that, getting 
values "near zero" so that the Huffman compressor can do its thing).

note that LZ77+Huffman still does well even in the case where it is 
functioning primarily as an entropy coder, and does extra well in that 
it can deal better with "long runs of 0s" than the scheme used in JPEG.


technically, inter-frame patterns may exist, but require a much-larger 
LZ77 window to exploit (several MB or more), and with a 64kB window, the 
codec is likely only seeing patterns over the past several scan-lines.

but, in my case (256x256 32bpp 4 layers), a 2MB window would be able to 
see the prior frame (and a 4MB window would be able to see about 3 prior 
frames).

the cost though is then needing to spend about 4MB per video-decoder 
context (+ the size of the frame-buffers, ...).

another potential cost is that a larger LZ77 window will less easily fit 
in cache, meaning a drop in decoder speed.

I have experimented some with LZ78 variants, but personally I had a hard 
time getting them to be anywhere near as fast on the decoder end as LZ77 
variants (which can IME operate pretty much nearly as fast as they can 
copy stuff around in memory).

actually: IME it is actually faster to read/write deflated data to disk, 
as the process of compressing/decompressing the data can be somewhat 
faster than the disk-IO speed (say, the inflater pulls off around 800MB 
to 1GB/s, but the disk IO is typically only about 50-75MB/s).

compression speed is harder (mostly due to the costs of looking up LZ 
matches), but using smaller searches and optimization heuristics can 
help speed this up, at the cost of reducing the compression (basically, 
rather than searching for the "best" match, it tries to more quickly 
find a "good enough" match).


>> so, it is more a tradeoff of either going this route (considering a
>> custom/non-standard codec), or seeing about trying to optimize my MJPEG
>> decoder more (eventually) and staying with this.
>
> Try Cinepak :)
> Wikipedia mentions other VQ-based codecs, maybe they will suit your needs.
>

not sure I want to bother with it.

I tend to write my own code for any codecs I use (due partly to "special 
requirements"), and the concern over "common" codecs is more due to the 
case of "if people might want to look at the basic video in a video 
player" or similar.

for example, my MJPEG codec uses my own code, and some extensions, but 
the output videos remain compatible with existing players (despite them 
ignoring any extended component-layers).


if accessible, one can try here:
http://cr88192.dyndns.org:8080/wiki/index.php/JPEG
or maybe:
http://cr88192.dyndns.org/wiki/index.php/JPEG

where I did write a little bit about some of the current extensions.


>>> Rationale: with scheme described above drawing actual pixels on screen
>>> is incredibly simple and can easily be accelerated even with old
>>> versions of OpenGL: for each block you draw a bunch of textured
>>> rectangles.
>
>> not actually likely to perform better than simply loading the video
>> frames into a texture and drawing said texture.
>
> KLT decoding is slow because it requires multiply and add for each pixel
> color for each KLT vector element.
>
> I.e. with 4x4 RGB blocks you need 4x4*3 = 48 multiplies and adds for
> each pixel. (For a lossless decoding which doesn't truncate any
> components.)
>
> If you're decoding 2 megapixel video on 1 GHz CPU with 24 fps, you have
> 10^9/(2*10^6)/24 = 20.83 cycles per pixel
>
> So it's rather hard to do this, if not impossible.
>
> OTOH for video card hardware it's just texturing, and it can do a lot of
> it.
>

yes, but polygons are not free either.

it replaces one cost with another, such as calculating pixel values, vs 
updating ones' VBOs or similar, as well as complicating the drawing 
process and limiting where one can use it.

if it maps such that one can draw tiles, it should also map such that 
one can use some memcpy operations or similar, which may not necessarily 
be that much more costly.


in my case, I prefer simply streaming the video frames into textures, as 
then I can quickly/easily use it on whatever sort of surface I feel like 
using it with (especially with multi-layer textures, where then the 
usual shaders can do their magic, and don't actually need to care that 
the textures are being streamed-in from a video source).


> Note that it can also work with WebGL or maybe even simpler JS-based
> APIs. Which could be a killer feature -- video codec done in JS, no
>

not much experience with WebGL, mostly I have experience with more 
full-featured OpenGL.


>> theoretically could also be done with a DCT-based codec.
>
> It's much harder, as I understand. Predictive coding assumes that you've
> correctly reconstructed previous frames, if you've cut corners you'll
> get some bad artifacts.
>
> Also I'm not sure that zeroing out some components would make DCT
> calculation much faster, although I know embarrassingly little about it.
>

actually, a property of DCT is that one can actually "ignore" some of 
the DCT coefficients, say, they can replace the usual 8x8 IDCT with a 
variant of a 4x4 IDCT, which then ignores a lot of the coefficients, and 
produces a reduced-resolution block.

so, it isn't that making them 0 makes them faster, but they can be left 
out of the math altogether.


note that a codec could also be built around the assumption of instead 
using 4x4 DCT blocks, which could allow higher decoder performance than 
an 8x8 block.


>> this is likely because people keep going for H.264 and similar, which
>> tends to be fairly costly to decode.
>
> Well, I guess so.
> But bandwidth is a problem too. youtube often get congested, so only
> low-quality streams can be played smoothly.
>
> I think it's kinda embarrassing that they don't use auto quality scaling.
>
> Actually there is a technology for this:
> http://en.wikipedia.org/wiki/Scalable_Video_Coding
> But I guess it's too advanced for youtube to use :)
>

well, buffering/bandwidth and playback performance are different matters.

it is sad, but I have a few times ran across some videos in 
1920x1080x30fps using H.264, which can cause lag on modern desktop PCs 
("oh crap! this video has rain effects!" as the video playback rate 
suddenly goes all to hell).

older MPEG codecs would simply turn the rain into a fuzzy mess, where 
honestly I would prefer the rain to be fuzzy than the lag to render the 
video nearly unwatchable.

On 29 Jun., 12:35, Alex Mizrahi wrote:
> Break all video frames into blocks, say, 4x4 ones, as usual.
> Run a clustering on those blocks (lots of them!) using, say, Frobenius
> norm for distance.

Yes, it sounds like VQ.

> Find mean or median for each such cluster.

Since you didn't say anything about weighting, just "Frobenius norm",
each Voronoi region would approximate a hyper sphere.

> [...]
> This crude image approximation can be further refined by calculating
> difference between actual block and cluster mean and encoding this
> difference using KLT. KLT will be different for each cluster.

Having lots of sphere-like clusters results in rather uncorrelated
residuals which makes the KLT pointless for residual coding.

> I want to make a proof-of-concept codec which would provide smooth video
> playback under any conditions.

Good luck! Don't forget some kind of motion compensation. You can save
*lots* of bits doing it well.

SG

Alex Mizrahi wrote: [video compression idea]

There are several active video comp experts in the doom9 forums.
You might want to lurk/post there:

http://forum.doom9.org/forumdisplay.php?f=54

On Friday, June 29, 2012 5:04:31 PM UTC, BGB wrote:
> this is likely because people keep going for H.264 and similar, which 
> tends to be fairly costly to decode.
> 
> a lot of this isn't due to the "basic" compression technology, but due 
> to some of the added things they put onto it (improve compression and 
> perceptual quality, such as CABAC and mandatory deblocking filters and 
> so on).

Stop spreading bullshit BGB. My old 1.5 ghz Pentium 4 could decode 640x480 H.264 video and my current i7 can decode 1920x1080 with 6.25% CPU usage.

I get hangups on YouTube as well. This has nothing to do with H.264 but with browsers being bloated like a hippo's ass and Java sucking balls in general.

I never thought there would be a time I would have to ditch Firefox for IE for the same reason I ditched IE 8 years ago.

If you really intend to watch whatever shit you're watching on JewTube in high quality, just download the video instead and watch it normally, and you won't get the hangups.

On 7/2/2012 6:32 AM, Industrial One wrote:
> On Friday, June 29, 2012 5:04:31 PM UTC, BGB wrote:
>> this is likely because people keep going for H.264 and similar, which
>> tends to be fairly costly to decode.
>>
>> a lot of this isn't due to the "basic" compression technology, but due
>> to some of the added things they put onto it (improve compression and
>> perceptual quality, such as CABAC and mandatory deblocking filters and
>> so on).
>
> Stop spreading bullshit BGB. My old 1.5 ghz Pentium 4 could decode 640x480 H.264 video and my current i7 can decode 1920x1080 with 6.25% CPU usage.
>

I am not saying that it can't be decoded in real-time, for "normal" 
playback, but that it seems a bit more costly to decode, say, than 
MPEG-1 was.


the issue is mostly with high resolutions on older hardware (me thinking 
a bit older than a "1.5 GHz P4"), more like stuff you would find in 
laptops from 10-15 years ago (IOW: late 90s era).

hell, my 10 year old laptop has trouble running modern Visual Studio 
without notable lag (and, ironically, it has comparable stats to a more 
recently bought Android tablet).


hell, the computer I was having the laggy rain issues on had a slower 
CPU than 1.5GHz, more like 1.2GHz or so (likewise, I have seen laggy 
playback issues at 1920x1080 on 1.8GHz systems as well).

on newer HW, things tend to work a bit better though.


> I get hangups on YouTube as well. This has nothing to do with H.264 but with browsers being bloated like a hippo's ass and Java sucking balls in general.
>
> I never thought there would be a time I would have to ditch Firefox for IE for the same reason I ditched IE 8 years ago.
>
> If you really intend to watch whatever shit you're watching on JewTube in high quality, just download the video instead and watch it normally, and you won't get the hangups.
>

depending, one can still have issues playing back videos in standalone 
video players as well, so it isn't all the blame of FF and Flash, though 
yes, they do quite a bit of lagging as well sometimes.

On Jul 1, 6:55=A0am, Alex Mizrahi <alex.mizr...@gmail.com> wrote:
> Notably, Cinepack, it could easily decode videos on 25 MHz CPUs (and
> even slower ones), but video quality and bitrate weren't good at all.
>
> So my intuition was more-or-less right.
>
> But I think it might be possible to implement much better VQ based codec
> now.

Don't be so quick to dismiss Cinepak; "video and bitrate" were better
than most other codecs of its time period (1992-1994) that were
optimized for playback speed.

You are right that there are better VQ codecs out there:
http://en.wikipedia.org/wiki/Vector_quantization#Video_codecs_based_on_vect=
or_quantization

The "state of the art" of vector quantizers was probably a toss up
before RoQ (http://wiki.multimedia.cx/index.php?title=3DROQ) and
Sorenson Video 1 (http://wiki.multimedia.cx/index.php?
title=3DSorenson_Video_1).

On 7/2/2012 2:04 PM, Jim Leonard wrote:
> On Jul 1, 6:55 am, Alex Mizrahi <alex.mizr...@gmail.com> wrote:
>> Notably, Cinepack, it could easily decode videos on 25 MHz CPUs (and
>> even slower ones), but video quality and bitrate weren't good at all.
>>
>> So my intuition was more-or-less right.
>>
>> But I think it might be possible to implement much better VQ based codec
>> now.
>
> Don't be so quick to dismiss Cinepak; "video and bitrate" were better
> than most other codecs of its time period (1992-1994) that were
> optimized for playback speed.
>
> You are right that there are better VQ codecs out there:
> http://en.wikipedia.org/wiki/Vector_quantization#Video_codecs_based_on_vector_quantization
>
> The "state of the art" of vector quantizers was probably a toss up
> before RoQ (http://wiki.multimedia.cx/index.php?title=ROQ) and
> Sorenson Video 1 (http://wiki.multimedia.cx/index.php?
> title=Sorenson_Video_1).
>

yeah. I have messed with RoQ before, and had used it for video-mapping 
in the past (but can't currently use it, as I don't have a decoder for 
it available which isn't GPL).


since then, I have been using MJPEG, but the performance isn't as good.

(although potentially I could use lower resolutions, such as 64x64 and 
128x128 rather than 256x256 and 512x512).


I did recently (yesterday) experiment with an idea for (yet another) 
loosely PNG-based codec, but the compression wasn't very good (30-40% 
worse than MJPEG), making it a lot harder to justify.

granted, it could maybe compress better if it were a lossy codec, but 
alas. (for testing I was actually mostly just using a hacked-over 
version of my PNG encoder, with some more filters and similar thrown on).

the predictors which seemed to be being used most often were:
"Paeth", "Linear" (A+B-C), "Past-Pixel" (the same pixel from the prior 
frame following motion compensation, 'H' in this case), 
"Average-Past-Paeth" ((Paeth+H)/2), and "Average-Past-Linear" 
(((A+B-C)+H)/2).

I wrote in code for a number of other predictors, but they were rarely 
chosen.

I have doubts though as I haven't in the past really got much "good" 
going this route.


did sit around micro-optimizing the JPEG decoder, got it about 2x faster 
(mostly based on fiddling around with the logic for re-assembling the 
image and doing the YUV->RGB conversion).

performance could still be a bit better though.


or such...

> Stop spreading bullshit BGB. My old 1.5 ghz Pentium 4 could decode 640x480 H.264 video and my current i7 can decode 1920x1080 with 6.25% CPU usage.

Do you realize that H.264 might be coded in a multitude of different ways?

> This has nothing to do with H.264 but with browsers being bloated like a hippo's ass and Java sucking balls in general.

You don't know anything about software engineering, do you? Size of 
program does not affect its performance.

Java isn't used for video decoding, Flash is. It's very well possible 
that video decoder in Flash and Flash-browser integration plays a 
significant role in a disappointing performance.

> If you really intend to watch whatever shit you're watching on JewTube in high quality, just download the video instead and watch it normally, and you won't get the hangups.

This reminds me Soviet joke:
  "Why there is no sausages or meat in shops?"
  "Party have determined that currently there is no need in sausages or 
meat".

Yeah, sure, there is no need...

On 7/4/2012 2:23 AM, Alex Mizrahi wrote:
>> Stop spreading bullshit BGB. My old 1.5 ghz Pentium 4 could decode
>> 640x480 H.264 video and my current i7 can decode 1920x1080 with 6.25%
>> CPU usage.
>
> Do you realize that H.264 might be coded in a multitude of different ways?
>

yeah.

a partial issue here is that often the defaults seems to go for best 
quality/bitrate tradeoff, which can hurt performance some on the decoder 
end.


for example, the use of arithmetic coding allows more quality at a lower 
bit-rate, yes, but it is slower to decode than Huffman.

decoding Huffman can mostly be reduced to:
shift bit window (by bit-offset) into a "peek" value;
look up coded value using an index table (1);
add found symbol length to bit offset;
check bit-offset, shift in another byte and adjust offset if-needed.

which can actually go fairly fast.

1: granted, this requires essentially using a table which has the same 
width as the widest coded symbol (often 15 or 16 bits), whereas using an 
8 or 12 bit prefix allows a smaller index table, it does add the need to 
check for an "escape case" where a slower lookup is used for 
low-probability symbols (such as walking a list of symbols which have 
this prefix).


although AC need not be "dead slow" either, it still tends to be slower 
than the use of Huffman coding.


for example, a "bit at a time" arithmetic coder may work something like:
get current bit probability;
calculate mid-value for the window (a few calculations involving the 
probability);
compare bitstream-word with mid-value (to get output bit);
use mid-point as new low or high value for window (depending on bit);
check for window convergence, adjusting window and shifting in more 
bytes as-needed.

this may then be repeated multiple times to decode a given symbol.


but, there may be something I am missing here...


>> This has nothing to do with H.264 but with browsers being bloated like
>> a hippo's ass and Java sucking balls in general.
>
> You don't know anything about software engineering, do you? Size of
> program does not affect its performance.
>
> Java isn't used for video decoding, Flash is. It's very well possible
> that video decoder in Flash and Flash-browser integration plays a
> significant role in a disappointing performance.
>

AFAIK, the video decoders for Flash are provided by the Flash VM using 
native code, where in this case the Flash serves mostly to provide the 
video player's UI.

I could be wrong on this, not personally being much of an expert on Flash.

however, even as such, Flash is GC'ed, and things like the YouTube video 
player also seem to be prone to memory leaks, so a lot of the lag/stalls 
on YT and similar are likely due to these issues.


however, the particular issue of "high-res video + rain or 
fancy-graphical-effects = lag" is more due to the codec (especially when 
in the case of stand-alone media players).

this is usually limited though to the case of watching high-res anime 
videos, which will play fine for the most part, but have playback go all 
to hell in the case where "some gigantic brightly colored/high-contrast 
swirly thing with lots of clockwork" or similar comes on screen.


I have made the (at least informal) observation that this tends to 
coincide with what codec was used, with typically getting a fuzzy mess 
for older codecs (including Xvid and similar), whereas more often 
getting severe lag for H.264, though this tends to only (normally) be a 
major issue at higher resolutions (typically 1080p).


>> If you really intend to watch whatever shit you're watching on JewTube
>> in high quality, just download the video instead and watch it
>> normally, and you won't get the hangups.
>
> This reminds me Soviet joke:
>   "Why there is no sausages or meat in shops?"
>   "Party have determined that currently there is no need in sausages or
> meat".
>
> Yeah, sure, there is no need...
>

yeah.

I also think that the use of a racial slur in this case was uncalled 
for. people may potentially take offense at such a comment.

"BGB" <cr88192@hotmail.com> wrote in message 
news:jt1smq$68a$1@news.albasani.net...
> On 7/4/2012 2:23 AM, Alex Mizrahi wrote:
>>> Stop spreading bullshit BGB. My old 1.5 ghz Pentium 4 could decode
>>> 640x480 H.264 video and my current i7 can decode 1920x1080 with 6.25%
>>> CPU usage.
>>
>> Do you realize that H.264 might be coded in a multitude of different 
>> ways?
>>
>
> yeah.
>
> a partial issue here is that often the defaults seems to go for best 
> quality/bitrate tradeoff, which can hurt performance some on the decoder 
> end.
>
>
> for example, the use of arithmetic coding allows more quality at a lower 
> bit-rate, yes, but it is slower to decode than Huffman.
>
> decoding Huffman can mostly be reduced to:
> shift bit window (by bit-offset) into a "peek" value;
> look up coded value using an index table (1);
> add found symbol length to bit offset;
> check bit-offset, shift in another byte and adjust offset if-needed.
>
> which can actually go fairly fast.
>
> 1: granted, this requires essentially using a table which has the same 
> width as the widest coded symbol (often 15 or 16 bits), whereas using an 8 
> or 12 bit prefix allows a smaller index table, it does add the need to 
> check for an "escape case" where a slower lookup is used for 
> low-probability symbols (such as walking a list of symbols which have this 
> prefix).
>
>
> although AC need not be "dead slow" either, it still tends to be slower 
> than the use of Huffman coding.
>
>
> for example, a "bit at a time" arithmetic coder may work something like:
> get current bit probability;
> calculate mid-value for the window (a few calculations involving the 
> probability);
> compare bitstream-word with mid-value (to get output bit);
> use mid-point as new low or high value for window (depending on bit);
> check for window convergence, adjusting window and shifting in more bytes 
> as-needed.
>
> this may then be repeated multiple times to decode a given symbol.
>
>
> but, there may be something I am missing here...
>
>
>>> This has nothing to do with H.264 but with browsers being bloated like
>>> a hippo's ass and Java sucking balls in general.
>>
>> You don't know anything about software engineering, do you? Size of
>> program does not affect its performance.
>>
>> Java isn't used for video decoding, Flash is. It's very well possible
>> that video decoder in Flash and Flash-browser integration plays a
>> significant role in a disappointing performance.
>>
>
> AFAIK, the video decoders for Flash are provided by the Flash VM using 
> native code, where in this case the Flash serves mostly to provide the 
> video player's UI.
>
> I could be wrong on this, not personally being much of an expert on Flash.
>
> however, even as such, Flash is GC'ed, and things like the YouTube video 
> player also seem to be prone to memory leaks, so a lot of the lag/stalls 
> on YT and similar are likely due to these issues.
>
>
> however, the particular issue of "high-res video + rain or 
> fancy-graphical-effects = lag" is more due to the codec (especially when 
> in the case of stand-alone media players).
>
> this is usually limited though to the case of watching high-res anime 
> videos, which will play fine for the most part, but have playback go all 
> to hell in the case where "some gigantic brightly colored/high-contrast 
> swirly thing with lots of clockwork" or similar comes on screen.
>
>
> I have made the (at least informal) observation that this tends to 
> coincide with what codec was used, with typically getting a fuzzy mess for 
> older codecs (including Xvid and similar), whereas more often getting 
> severe lag for H.264, though this tends to only (normally) be a major 
> issue at higher resolutions (typically 1080p).
>
>
>>> If you really intend to watch whatever shit you're watching on JewTube
>>> in high quality, just download the video instead and watch it
>>> normally, and you won't get the hangups.
>>
>> This reminds me Soviet joke:
>>   "Why there is no sausages or meat in shops?"
>>   "Party have determined that currently there is no need in sausages or
>> meat".
>>
>> Yeah, sure, there is no need...
>>
>
> yeah.
>
> I also think that the use of a racial slur in this case was uncalled for. 
> people may potentially take offense at such a comment.

    Ignorance is as unappealing a trait as the inability to recognize the 
flaming murderous hate the Jews have for all non-Jews.  Do you know what 
happens when you come to a fight for which you are not even aware is 
occurring (thanks to the media - owned majorly by... guess who) with no 
weapons or even the instinct to protect yourself? It's called a trip to the 
slaughterhouse and you're playing the role of the soon-to-be slaughtered 
cattle.

    Now bow your head to the altar of multi-deathcult-uralism  and say 
"MOOO" while the Rabbi slits your throat like a good little idiot. Since 
you've been conquered by the same Jewish genetic-psychopaths that routinely 
have mass-murdered over 120 million human beings in the past 100 years, I 
see that you have surrendered without even a whimper.

Kapparot (ritual chicken slaughter) in Los Angeles, CA
http://www.youtube.com/watch?v=aZ3YDsnmFJM

    You see kiddies, the Jews ritually murder animals (often humans) and 
under the delusions of Kapparot (and other Jewish moon-voodoo ceremonies) 
that their sins for the year are transferred by a Rabbi into the animal and 
then the animal is ritually-slaughtered, therein taking the sins of the Jew 
to the grave. Of course, there is some nonsense about swinging the chicken 
in a circle above the head of the evil Jew prior to the ritual slaughter, 
but that's just the usual genetic-psychopathy of the Forever-Genocidal 
Jewish-Geneline.  After all, when the Haitians slaughter and cannibalize 
another human, that's not Voodoo, it's "Traditional African Cuisine". When 
Jews ritually slaughter animals for imaginary sin-transfer, it's not 
Violently Psychopathic Voodoo, it's just Ancient Jewish Tradition, oh no not 
Violent Psychopathic Voodoo, are you going to believe your brain & eyes or 
what the Jews insist you believe or be called "Anti-Scum-Ethnic", oh wait, 
"Anti-Schemer-Intelligent", oh wait, "Anti-Pants-Wet-It", oh wait, 
"Anti-Stupidity-Epidemic", ah what was that ever-prized catchphrase again 
for instant paralysis of the gutless morons?

"Anti-semitic, its a trick we always use it"
http://www.youtube.com/watch?v=D0kWAqZxJVE
Former Israeli Minister Shulamit Aloni
"Anti-semitic", "its a trick we always use it"

Kapores The Transfering of our Sins
http://www.youtube.com/watch?v=G6hQo0YMYwY

Redemption of Kaparot Atonement through Charity -- a Double Obligation
http://www.youtube.com/watch?v=257TGsDD5vg

=======
FBI ARRESTS 17 RABBI'S FOR SELLING BODY PARTS.
http://www.youtube.com/watch?v=4JaI58_z3UI

Jews And Human Organ Trafficking
http://www.sunray22b.net/Jews_And_Human_Organ_Trafficking.html

The arrests of rabbis who trafficked body parts uncover more complicated 
issues.
http://www.slate.com/id/2223559/
By Benyamin Cohen [ 1 August 2009 ]

Two state legislators and several rabbis were among more than 40 people 
arrested yesterday in New JerseyWith the right ingredients of salaciousness 
and scandal, the news appeared to be straight out of a Hollywood screenplay: 
corrupt politicians, money laundering, people being arrested by the busload, 
raids on synagogues, an Apple Jacks cereal box stuffed with $97,000 in cash, 
and rabbis trafficking organs. Allegedly, one paid $10,000 to an 
impoverished Israeli for his or her kidney and tried to sell it for upward 
of $150,000 in the United States. The criminal complaint quotes the rabbi as 
saying he was in the organ business for a decade. (And in a 
you-can't-make-this-stuff-up twist, it wasn't even the day's only story on 
Israelis trafficking human body parts.)

The rabbis' organ trafficking was only one of their many indiscretions. In 
addition to being against the law, it raises a complex bioethical issue for 
Jews, one laced in a culture of moral imperatives.
UNQUOTE
Slaves, narcotics, guns, you name it, they sell it. As long as the price is 
right they are up for it. If it is illegal the price goes up and it is tax 
free. That makes two pay offs and they both drop straight through to the 
bottom line. More and better details at Jews And Human Organ Trafficking 
Take the point that Mr Cohen is more concerned with obscuring the issue than 
vice versa. The Scotsman puts a rather more robust view at The Kosher Nostra 
Is-Trapped At Last
======
http://www.whale.to/c/yitzchak_ginzburg.html
Quotes [Rabbi quotes]

[Organ Harvesting] "If a Jew needs a kidney, is it allowed, in order to save 
his life, to take the kidney from a Goy (non-Jew), passing by, even if he is 
not guilty of anything?  In my opinion, Torah allows it. The life of a Jew 
is priceless"-- Lubavitcher rabbi Yitzchak Ginsburgh

"As for the Goyim. Zalman's attitude (was): "Gentile souls are of a 
completely different and inferior order. They are totally evil, with no 
redeeming qualities whatsoever.".If every simple cell in a Jewish body 
entails divinity, is a part of God, then every strand of DNA is a part of 
God. Therefore, something is special about Jewish DNA." ".If a Jew needs a 
liver, can you take the liver of an innocent non-Jew passing by to save him? 
The Torah would probably permit that. Jewish life has an infinite value," he 
explained. "There is something infinitely more holy and unique about Jewish 
life than non-Jewish life."- Chabad-Lubavitch Rabbi Yitzhak Ginsburgh in 
"Jewish Week," the largest Jewish publication in the United States, April 
26, 1996.

"If you saw two people drowning, a Jew and a non-Jew, the Torah says you 
save the Jewish life first," Rabbi Ginsburgh told the Jewish Week.

"There is something infinitely more holy and unique about Jewish life than 
non-Jewish life." -- Chabad Lubavitch Rabbi Yitzhak Ginsburgh in Jewish 
Week, the largest Jewish publication in the United States.
======

The Jewish hand behind Internet
Google, Facebook, Wikipedia,Yahoo!, MySpace, eBay...
http://theunjustmedia.com/Media/Articles%20On%20media/The%20Jewish%20hand%20behind%20Internet.htm

====
Settler Rabbi publishes "The complete guide to killing non-Jews" - UPDATED
November 9, 2009
http://coteret.com/2009/11/09/settler-rabbi-publishes-the-complete-guide-to-killing-non-jews/
"In any situation in which a non-Jew's presence endangers Jewish lives, the 
non-Jew may be killed even if he is a righteous Gentile and not at all 
guilty for the situation that has been created."

====

The Truth About Talmud
Talmudic Doctrine: Non-Jews are not Human
http://www.missionislam.com/nwo/talmud.htm

The Talmud specifically defines all who are not Jews as non-human animals, 
and specifically dehumanises gentiles as not being descendants of Adam. We 
will now list some of the Talmud passages which relate to this topic:

"The Jews are called human beings, but the non-Jews are not humans. They are 
beasts."
Talmud: Baba mezia, 114b

"The Akum (non-Jew) is like a dog. Yes, the scripture teaches to honour the 
the dog more than the non-Jew."
Ereget Raschi Erod. 22 30

"Even though God created the non-Jew they are still animals in human form. 
It is not becoming for a Jew to be served by an animal. Therefore he will be 
served by animals in human form."
Midrasch Talpioth, p. 255, Warsaw 1855

"A pregnant non-Jew is no better than a pregnant animal."
Coschen hamischpat 405

"The souls of non-Jews come from impure sprits and are called pigs."
Jalkut Rubeni gadol 12b

"Although the non-Jew has the same body structure as the Jew, they compare 
with the Jew like a monkey to a human."
Schene luchoth haberith, p. 250 b

"If you eat with a Gentile, it is the same as eating with a dog."
Tosapoth, Jebamoth 94b

"If a Jew has a non-Jewish servant or maid who dies, one should not express 
sympathy to the Jew. You should tell the Jew: "God will replace 'your loss', 
just as if one of his oxen or asses had died"."
Jore dea 377, 1

"Sexual intercourse between Gentiles is like intercourse between animals."
Talmud Sanhedrin 74b

"It is permitted to take the body and the life of a Gentile."
Sepher ikkarim III c 25

"It is the law to kill anyone who denies the Torah. The Christians belong to 
the denying ones of the Torah."
Coschen hamischpat 425 Hagah 425. 5

"A heretic Gentile you may kill outright with your own hands."
Talmud, Abodah Zara, 4b

"Every Jew, who spills the blood of the godless (non-Jews), is doing the 
same as making a sacrifice to God."
Talmud: Bammidber raba c 21 & Jalkut 772 

On Jul 2, 6:38=A0pm, BGB <cr88...@hotmail.com> wrote:
> since then, I have been using MJPEG, but the performance isn't as good.

What's your target platform?

On 7/10/2012 2:01 PM, Jim Leonard wrote:
> On Jul 2, 6:38 pm, BGB <cr88...@hotmail.com> wrote:
>> since then, I have been using MJPEG, but the performance isn't as good.
>
> What's your target platform?
>

Windows+Linux (x86 and x86-64) and OpenGL.

I did optimize it a bit more, but it could still be better.


probably good enough, as I was getting around 700 images/second at 
256x256, and around 3000 images/second at 64x64 (so, ~ 45.9 Mpix/s for 
256x256, and 12.3 Mpix/s for 64x64).

so, is probably "good enough" for animated textures (10 streams at 5 
layers at 256x256 at 10Hz would require 500 images/second, or 32.8 Mpix/s).


(I can also get about another ~ 1.5x boost if it is compiled with 
compiler optimizations turned on, but this prevents using the profiler 
or debugger, and optimization settings are not currently used for 
building the 3D engine).


this doesn't actually do much with the decoded images, just decoding in 
a tight loop, and then dumping the image following the final iteration 
to verify that the image is still coming out correctly.


sadly, decode rate is still low enough to where it couldn't pull off 
1080p video at 30fps (nevermind for a moment the disk space 
requirements). (requires 62.2 Mpix/s).

it is fast enough to where it should be able to handle 720p though. 
(requires 27.6 Mpix/s).


I am wondering then if the actual video codecs have some trickery to 
speed up how quickly they can decode the video frames.

can't think of much in particular, apart from maybe using multiple 
threads to decode video frames or similar, where I guess it is possible 
that maybe a 2x-3x speedup could be possible with multi-threaded 
decoding (say, each thread decodes a frame in parallel), where presently 
my decoder is single-threaded.


a few optimizations I found:
the 4:2:0 case is detected, and pixels are transformed 4 at a time 
(2x2), for the YCbCr->RGB conversion;
made the observation that by doing things like 
"if((r0|r1|r2|r3)&(~256))", I could skip out on a lot of range-clamping 
checks;
....

currently, the YCbCr -> RGB conversion phase is still the main 
time-waster, followed by the logic for reading in DCT blocks, followed 
by the logic for decoding Huffman symbols, followed by the IDCT 
transform, the function for DCT block * QTab, ...

nearly all math at present is fixed-point (scalar integer math, no SIMD).


or such...

On 7/10/2012 5:00 PM, BGB wrote:
> On 7/10/2012 2:01 PM, Jim Leonard wrote:
>> On Jul 2, 6:38 pm, BGB <cr88...@hotmail.com> wrote:
>>> since then, I have been using MJPEG, but the performance isn't as good.
>>
>> What's your target platform?
>>
>
> Windows+Linux (x86 and x86-64) and OpenGL.
>
> I did optimize it a bit more, but it could still be better.
>

....

nevermind me realizing it was Mpx, not Mpix.


>
> a few optimizations I found:
> the 4:2:0 case is detected, and pixels are transformed 4 at a time
> (2x2), for the YCbCr->RGB conversion;
> made the observation that by doing things like
> "if((r0|r1|r2|r3)&(~256))", I could skip out on a lot of range-clamping
> checks;
> ...
>

correction: ~255.
the basic idea is that, if all are in the 0-255 range, (...)&(~255) will 
give 0.

if the value is non-zero, then at least one of the values is out of 
range, and the logic can be invoked to clamp the values.


the reason for sitting around micro-optimizing the color-space 
conversion and output-range clamping was because most of time in the 
profiler was going into this.

note that the reason for using 2x2 pixel-blocks was to allow reducing 
the amount of time needed to fetch the YCbCr values from the macroblocks.


> currently, the YCbCr -> RGB conversion phase is still the main
> time-waster, followed by the logic for reading in DCT blocks, followed
> by the logic for decoding Huffman symbols, followed by the IDCT
> transform, the function for DCT block * QTab, ...
>
> nearly all math at present is fixed-point (scalar integer math, no SIMD).
>

basically, a secondary goal would be to get comparable or better decoder 
performance to a proper video codec, just while being single-threaded 
and compiled with debug+profile settings, and no SIMD, ...

this is looking unlikely though, at least using normal JPEG (and without 
cutting corners in nasty ways).

I wonder though how some of this compares with "typical" JPEG decoders, 
as I haven't really done any comparative benchmarks.



ironically, the IDCT doesn't eat a lot of time (vs other "simpler" 
linear processes).

nevermind that I originally wrote the IDCT code (some years ago), but no 
longer remember exactly how exactly it works (it resembles some sort of 
math triangle thing). I think I vaguely remember it involving observing 
number patterns and factoring stuff in an effort to reduce the 
complexity (memory also seems to say that I could have factored it 
further, but would require first expanding out the full 2D transform and 
then factoring it, basically to make an IDCT shaped like a pyramid, or 
something).


crap, maybe sometimes I am becoming steadily stupider, as what is left 
of my youth slips away.


or such...

On Thursday, July 5, 2012 2:52:26 AM UTC, George Johnson wrote:
> "BGB" <cr88192@hotmail.com> wrote in message=20
> news:jt1smq$68a$1@news.albasani.net...
> > On 7/4/2012 2:23 AM, Alex Mizrahi wrote:
> >>> Stop spreading bullshit BGB. My old 1.5 ghz Pentium 4 could =
decode
> >>> 640x480 H.264 video and my current i7 can decode 1920x1080 w=
ith 6.25%
> >>> CPU usage.
> >>
> >> Do you realize that H.264 might be coded in a multitude of diffe=
rent=20
> >> ways?
> >>
> >
> > yeah.
> >
> > a partial issue here is that often the defaults seems to go for best=
=20
> > quality/bitrate tradeoff, which can hurt performance some on the dec=
oder=20
> > end.
> >
> >
> > for example, the use of arithmetic coding allows more quality at a l=
ower=20
> > bit-rate, yes, but it is slower to decode than Huffman.
> >
> > decoding Huffman can mostly be reduced to:
> > shift bit window (by bit-offset) into a "peek" value;
> > look up coded value using an index table (1);
> > add found symbol length to bit offset;
> > check bit-offset, shift in another byte and adjust offset if-needed.
> >
> > which can actually go fairly fast.
> >
> > 1: granted, this requires essentially using a table which has the sa=
me=20
> > width as the widest coded symbol (often 15 or 16 bits), whereas usin=
g an 8=20
> > or 12 bit prefix allows a smaller index table, it does add the need =
to=20
> > check for an "escape case" where a slower lookup is used f=
or=20
> > low-probability symbols (such as walking a list of symbols which hav=
e this=20
> > prefix).
> >
> >
> > although AC need not be "dead slow" either, it still tends=
 to be slower=20
> > than the use of Huffman coding.
> >
> >
> > for example, a "bit at a time" arithmetic coder may work s=
omething like:
> > get current bit probability;
> > calculate mid-value for the window (a few calculations involving the=
=20
> > probability);
> > compare bitstream-word with mid-value (to get output bit);
> > use mid-point as new low or high value for window (depending on bit)=
;
> > check for window convergence, adjusting window and shifting in more =
bytes=20
> > as-needed.
> >
> > this may then be repeated multiple times to decode a given symbol.
> >
> >
> > but, there may be something I am missing here...
> >
> >
> >>> This has nothing to do with H.264 but with browsers being bl=
oated like
> >>> a hippo's ass and Java sucking balls in general.
> >>
> >> You don't know anything about software engineering, do you? =
Size of
> >> program does not affect its performance.
> >>
> >> Java isn't used for video decoding, Flash is. It's very =
well possible
> >> that video decoder in Flash and Flash-browser integration plays =
a
> >> significant role in a disappointing performance.
> >>
> >
> > AFAIK, the video decoders for Flash are provided by the Flash VM usi=
ng=20
> > native code, where in this case the Flash serves mostly to provide t=
he=20
> > video player's UI.
> >
> > I could be wrong on this, not personally being much of an expert on =
Flash.
> >
> > however, even as such, Flash is GC'ed, and things like the YouTu=
be video=20
> > player also seem to be prone to memory leaks, so a lot of the lag/st=
alls=20
> > on YT and similar are likely due to these issues.
> >
> >
> > however, the particular issue of "high-res video + rain or=20
> > fancy-graphical-effects =3D lag" is more due to the codec (espe=
cially when=20
> > in the case of stand-alone media players).
> >
> > this is usually limited though to the case of watching high-res anim=
e=20
> > videos, which will play fine for the most part, but have playback go=
 all=20
> > to hell in the case where "some gigantic brightly colored/high-=
contrast=20
> > swirly thing with lots of clockwork" or similar comes on screen=
..
> >
> >
> > I have made the (at least informal) observation that this tends to=
=20
> > coincide with what codec was used, with typically getting a fuzzy me=
ss for=20
> > older codecs (including Xvid and similar), whereas more often gettin=
g=20
> > severe lag for H.264, though this tends to only (normally) be a majo=
r=20
> > issue at higher resolutions (typically 1080p).
> >
> >
> >>> If you really intend to watch whatever shit you're watch=
ing on JewTube
> >>> in high quality, just download the video instead and watch i=
t
> >>> normally, and you won't get the hangups.
> >>
> >> This reminds me Soviet joke:
> >>   "Why there is no sausages or meat in shops?"
> >>   "Party have determined that currently there is no need in=
 sausages or
> >> meat".
> >>
> >> Yeah, sure, there is no need...
> >>
> >
> > yeah.
> >
> > I also think that the use of a racial slur in this case was uncalled=
 for.=20
> > people may potentially take offense at such a comment.
>=20
>     Ignorance is as unappealing a trait as the inability to recognize the=
=20
> flaming murderous hate the Jews have for all non-Jews.  Do you know what=
=20
> happens when you come to a fight for which you are not even aware is=20
> occurring (thanks to the media - owned majorly by... guess who) with no=
=20
> weapons or even the instinct to protect yourself? It's called a trip =
to the=20
> slaughterhouse and you're playing the role of the soon-to-be slaughte=
red=20
> cattle.
>=20
>     Now bow your head to the altar of multi-deathcult-uralism  and say=20
> "MOOO" while the Rabbi slits your throat like a good little idi=
ot. Since=20
> you've been conquered by the same Jewish genetic-psychopaths that rou=
tinely=20
> have mass-murdered over 120 million human beings in the past 100 years, I=
=20
> see that you have surrendered without even a whimper.
>=20
> Kapparot (ritual chicken slaughter) in Los Angeles, CA
> http://www.youtube.com/watch?v=3DaZ3YDsnmFJM
>=20
>     You see kiddies, the Jews ritually murder animals (often humans) and=
=20
> under the delusions of Kapparot (and other Jewish moon-voodoo ceremonies)=
=20
> that their sins for the year are transferred by a Rabbi into the animal a=
nd=20
> then the animal is ritually-slaughtered, therein taking the sins of the J=
ew=20
> to the grave. Of course, there is some nonsense about swinging the chicke=
n=20
> in a circle above the head of the evil Jew prior to the ritual slaughter,=
=20
> but that's just the usual genetic-psychopathy of the Forever-Genocida=
l=20
> Jewish-Geneline.  After all, when the Haitians slaughter and cannibalize=
=20
> another human, that's not Voodoo, it's "Traditional African =
Cuisine". When=20
> Jews ritually slaughter animals for imaginary sin-transfer, it's not=
=20
> Violently Psychopathic Voodoo, it's just Ancient Jewish Tradition, oh=
 no not=20
> Violent Psychopathic Voodoo, are you going to believe your brain & ey=
es or=20
> what the Jews insist you believe or be called "Anti-Scum-Ethnic&quot=
;, oh wait,=20
> "Anti-Schemer-Intelligent", oh wait, "Anti-Pants-Wet-It&qu=
ot;, oh wait,=20
> "Anti-Stupidity-Epidemic", ah what was that ever-prized catchph=
rase again=20
> for instant paralysis of the gutless morons?
>=20
> "Anti-semitic, its a trick we always use it"
> http://www.youtube.com/watch?v=3DD0kWAqZxJVE
> Former Israeli Minister Shulamit Aloni
> "Anti-semitic", "its a trick we always use it"
>=20
> Kapores The Transfering of our Sins
> http://www.youtube.com/watch?v=3DG6hQo0YMYwY
>=20
> Redemption of Kaparot Atonement through Charity -- a Double Obligation
> http://www.youtube.com/watch?v=3D257TGsDD5vg
>=20
> =3D=3D=3D=3D=3D=3D=3D
> FBI ARRESTS 17 RABBI'S FOR SELLING BODY PARTS.
> http://www.youtube.com/watch?v=3D4JaI58_z3UI
>=20
> Jews And Human Organ Trafficking
> http://www.sunray22b.net/Jews_And_Human_Organ_Trafficking.html
>=20
> The arrests of rabbis who trafficked body parts uncover more complicated=
=20
> issues.
> http://www.slate.com/id/2223559/
> By Benyamin Cohen [ 1 August 2009 ]
>=20
> Two state legislators and several rabbis were among more than 40 people=
=20
> arrested yesterday in New JerseyWith the right ingredients of salaciousne=
ss=20
> and scandal, the news appeared to be straight out of a Hollywood screenpl=
ay:=20
> corrupt politicians, money laundering, people being arrested by the buslo=
ad,=20
> raids on synagogues, an Apple Jacks cereal box stuffed with $97,000 in ca=
sh,=20
> and rabbis trafficking organs. Allegedly, one paid $10,000 to an=20
> impoverished Israeli for his or her kidney and tried to sell it for upwar=
d=20
> of $150,000 in the United States. The criminal complaint quotes the rabbi=
 as=20
> saying he was in the organ business for a decade. (And in a=20
> you-can't-make-this-stuff-up twist, it wasn't even the day's =
only story on=20
> Israelis trafficking human body parts.)
>=20
> The rabbis' organ trafficking was only one of their many indiscretion=
s. In=20
> addition to being against the law, it raises a complex bioethical issue f=
or=20
> Jews, one laced in a culture of moral imperatives.
> UNQUOTE
> Slaves, narcotics, guns, you name it, they sell it. As long as the price =
is=20
> right they are up for it. If it is illegal the price goes up and it is ta=
x=20
> free. That makes two pay offs and they both drop straight through to the=
=20
> bottom line. More and better details at Jews And Human Organ Trafficking=
=20
> Take the point that Mr Cohen is more concerned with obscuring the issue t=
han=20
> vice versa. The Scotsman puts a rather more robust view at The Kosher Nos=
tra=20
> Is-Trapped At Last
> =3D=3D=3D=3D=3D=3D
> http://www.whale.to/c/yitzchak_ginzburg.html
> Quotes [Rabbi quotes]
>=20
> [Organ Harvesting] "If a Jew needs a kidney, is it allowed, in order=
 to save=20
> his life, to take the kidney from a Goy (non-Jew), passing by, even if he=
 is=20
> not guilty of anything?  In my opinion, Torah allows it. The life of a Je=
w=20
> is priceless"-- Lubavitcher rabbi Yitzchak Ginsburgh
>=20
> "As for the Goyim. Zalman's attitude (was): "Gentile souls =
are of a=20
> completely different and inferior order. They are totally evil, with no=
=20
> redeeming qualities whatsoever.".If every simple cell in a Jewish bo=
dy=20
> entails divinity, is a part of God, then every strand of DNA is a part of=
=20
> God. Therefore, something is special about Jewish DNA." ".If a =
Jew needs a=20
> liver, can you take the liver of an innocent non-Jew passing by to save h=
im?=20
> The Torah would probably permit that. Jewish life has an infinite value,&=
quot; he=20
> explained. "There is something infinitely more holy and unique about=
 Jewish=20
> life than non-Jewish life."- Chabad-Lubavitch Rabbi Yitzhak Ginsburg=
h in=20
> "Jewish Week," the largest Jewish publication in the United Sta=
tes, April=20
> 26, 1996.
>=20
> "If you saw two people drowning, a Jew and a non-Jew, the Torah says=
 you=20
> save the Jewish life first," Rabbi Ginsburgh told the Jewish Week.
>=20
> "There is something infinitely more holy and unique about Jewish lif=
e than=20
> non-Jewish life." -- Chabad Lubavitch Rabbi Yitzhak Ginsburgh in Jew=
ish=20
> Week, the largest Jewish publication in the United States.
> =3D=3D=3D=3D=3D=3D
>=20
> The Jewish hand behind Internet
> Google, Facebook, Wikipedia,Yahoo!, MySpace, eBay...
> http://theunjustmedia.com/Media/Articles%20On%20media/The%20Jewish%20hand=
%20behind%20Internet.htm
>=20
> =3D=3D=3D=3D
> Settler Rabbi publishes "The complete guide to killing non-Jews&quot=
; - UPDATED
> November 9, 2009
> http://coteret.com/2009/11/09/settler-rabbi-publishes-the-complete-guide-=
to-killing-non-jews/
> "In any situation in which a non-Jew's presence endangers Jewish=
 lives, the=20
> non-Jew may be killed even if he is a righteous Gentile and not at all=20
> guilty for the situation that has been created."
>=20
> =3D=3D=3D=3D
>=20
> The Truth About Talmud
> Talmudic Doctrine: Non-Jews are not Human
> http://www.missionislam.com/nwo/talmud.htm
>=20
> The Talmud specifically defines all who are not Jews as non-human animals=
,=20
> and specifically dehumanises gentiles as not being descendants of Adam. W=
e=20
> will now list some of the Talmud passages which relate to this topic:
>=20
> "The Jews are called human beings, but the non-Jews are not humans. =
They are=20
> beasts."
> Talmud: Baba mezia, 114b
>=20
> "The Akum (non-Jew) is like a dog. Yes, the scripture teaches to hon=
our the=20
> the dog more than the non-Jew."
> Ereget Raschi Erod. 22 30
>=20
> "Even though God created the non-Jew they are still animals in human=
 form.=20
> It is not becoming for a Jew to be served by an animal. Therefore he will=
 be=20
> served by animals in human form."
> Midrasch Talpioth, p. 255, Warsaw 1855
>=20
> "A pregnant non-Jew is no better than a pregnant animal."
> Coschen hamischpat 405
>=20
> "The souls of non-Jews come from impure sprits and are called pigs.&=
quot;
> Jalkut Rubeni gadol 12b
>=20
> "Although the non-Jew has the same body structure as the Jew, they c=
ompare=20
> with the Jew like a monkey to a human."
> Schene luchoth haberith, p. 250 b
>=20
> "If you eat with a Gentile, it is the same as eating with a dog.&quo=
t;
> Tosapoth, Jebamoth 94b
>=20
> "If a Jew has a non-Jewish servant or maid who dies, one should not =
express=20
> sympathy to the Jew. You should tell the Jew: "God will replace &#39=
;your loss',=20
> just as if one of his oxen or asses had died"."
> Jore dea 377, 1
>=20
> "Sexual intercourse between Gentiles is like intercourse between ani=
mals."
> Talmud Sanhedrin 74b
>=20
> "It is permitted to take the body and the life of a Gentile."
> Sepher ikkarim III c 25
>=20
> "It is the law to kill anyone who denies the Torah. The Christians b=
elong to=20
> the denying ones of the Torah."
> Coschen hamischpat 425 Hagah 425. 5
>=20
> "A heretic Gentile you may kill outright with your own hands."
> Talmud, Abodah Zara, 4b
>=20
> "Every Jew, who spills the blood of the godless (non-Jews), is doing=
 the=20
> same as making a sacrifice to God."
> Talmud: Bammidber raba c 21 & Jalkut 772

Although I don't deny the fact of Zionist domination of American politics, =
you gotta understand that none of this would be happening if the Muslim hor=
de pieces of shit would just learn to live and let live and stop invading o=
ther nations like a disease and slaughter/expel the indigenous inhabitants.

Jews were expelled from their own country by Muslims and they weren't the f=
irst. Spain, many countries in Eastern-Europe, Syria have been conquered an=
d dominated by Muslims for hundreds of years before they were expelled and =
many in North Africa as we speak are having their native black tribes slaug=
htered by Muslims and replaced by Arabian tribes.

For 400 years they've dominated Israel and converted it into a Sharia Law M=
uslim territory and you just can't get thru to those dumb motherfucker's he=
ads that they are not indigent to that territory they've raped and murdered=
 millions of its original inhabitants to steal, which already had a state a=
nd borders long before the invasion.

I'm not defending the Jews, they are ugly as fuck and just as inbred as Ara=
bs but for the sake of logic and justice, Israel is their territory and the=
 Muslim garbage deserve everything they fucking get for their habitual impe=
rialistic war crimes they still haven't grown out of as of yet.