Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
video compression idea
75 views
Skip to first unread message
Alex Mizrahi
Jun 29, 2012, 6:35:13 AM6/29/12
to
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.
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.
BGB
Jun 29, 2012, 1:04:31 PM6/29/12
to
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,
> 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?
>
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.
>
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.
>
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.
>
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.
Alex Mizrahi
Jul 1, 2012, 7:55:11 AM7/1/12
to
> 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
> compress well, and not look like crap, is a bit more debatable.
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).
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.
> meanwhile:
> I had recently imagined (once again) doing something similar to PNG but
> for video;
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,
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.
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.
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.
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.
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 :)
BGB
Jul 1, 2012, 1:22:28 PM7/1/12
to
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).
>> 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.
>
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.
>
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.
>
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.
>
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?
>
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?
>
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.
>
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.
>
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
>
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.
>
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 :)
>
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.
SG
Jul 2, 2012, 4:44:36 AM7/2/12
to
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.
> 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.
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
> difference between actual block and cluster mean and encoding this
> difference using KLT. KLT will be different for each cluster.
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.
*lots* of bits doing it well.
SG
Noob
Jul 2, 2012, 6:52:37 AM7/2/12
to
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
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
Industrial One
Jul 2, 2012, 7:32:38 AM7/2/12
to
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.
> 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).
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.
BGB
Jul 2, 2012, 11:38:47 AM7/2/12
to
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"
> 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.
>
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.
>
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.
Jim Leonard
Jul 2, 2012, 3:04:12 PM7/2/12
to
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
> 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.
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).
BGB
Jul 2, 2012, 7:38:06 PM7/2/12
to
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...
Alex Mizrahi
Jul 4, 2012, 3:23:15 AM7/4/12
to
> 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.
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.
"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...
BGB
Jul 4, 2012, 12:56:11 PM7/4/12
to
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.
>> 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?
>
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.
>
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...
>
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.
George Johnson
Jul 4, 2012, 10:52:26 PM7/4/12
to
"BGB" <cr8...@hotmail.com> wrote in message
news:jt1smq$68a$1...@news.albasani.net...
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
Jim Leonard
Jul 10, 2012, 3:01:19 PM7/10/12
to
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?
> since then, I have been using MJPEG, but the performance isn't as good.
BGB
Jul 10, 2012, 6:00:35 PM7/10/12
to
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...
BGB
Jul 10, 2012, 11:54:00 PM7/10/12
to
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.
>
...
> 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;
> ...
>
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).
>
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...
Industrial One
Jul 11, 2012, 12:03:52 PM7/11/12
to
On Thursday, July 5, 2012 2:52:26 AM UTC, George Johnson wrote:
> "BGB" <cr8...@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.
> slaughterhouse and you're playing the role of the soon-to-be slaughtered
> you've been conquered by the same Jewish genetic-psychopaths that routinely
> 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
> "Anti-semitic", "its a trick we always use it"
>
> "As for the Goyim. Zalman's attitude (was): "Gentile souls are of a
> 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
> 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."
> 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."
> 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."
> the denying ones of the Torah."
> 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
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 horde pieces of shit would just learn to live and let live and stop invading other nations like a disease and slaughter/expel the indigenous inhabitants.
Jews were expelled from their own country by Muslims and they weren't the first. Spain, many countries in Eastern-Europe, Syria have been conquered and 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 slaughtered by Muslims and replaced by Arabian tribes.
For 400 years they've dominated Israel and converted it into a Sharia Law Muslim territory and you just can't get thru to those dumb motherfucker's heads 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 and borders long before the invasion.
I'm not defending the Jews, they are ugly as fuck and just as inbred as Arabs but for the sake of logic and justice, Israel is their territory and the Muslim garbage deserve everything they fucking get for their habitual imperialistic war crimes they still haven't grown out of as of yet.
> "BGB" <cr8...@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
> 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
> 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
>
> Now bow your head to the altar of multi-deathcult-uralism and say
> 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
> 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,
> 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"
>
> "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.
> 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
>
> =======
> 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
>
> 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
> 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
> 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]
>
> 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
> not guilty of anything? In my opinion, Torah allows it. The life of a Jew
>
> "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
> ======
>
> The Jewish hand behind Internet
> Google, Facebook, Wikipedia,Yahoo!, MySpace, eBay...
> http://theunjustmedia.com/Media/Articles%20On%20media/The%20Jewish%20hand%20behind%20Internet.htm
>
> ====
> 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
> http://coteret.com/2009/11/09/settler-rabbi-publishes-the-complete-guide-to-killing-non-jews/
> 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
> ====
>
> 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:
>
> 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
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 horde pieces of shit would just learn to live and let live and stop invading other nations like a disease and slaughter/expel the indigenous inhabitants.
Jews were expelled from their own country by Muslims and they weren't the first. Spain, many countries in Eastern-Europe, Syria have been conquered and 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 slaughtered by Muslims and replaced by Arabian tribes.
For 400 years they've dominated Israel and converted it into a Sharia Law Muslim territory and you just can't get thru to those dumb motherfucker's heads 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 and borders long before the invasion.
I'm not defending the Jews, they are ugly as fuck and just as inbred as Arabs but for the sake of logic and justice, Israel is their territory and the Muslim garbage deserve everything they fucking get for their habitual imperialistic war crimes they still haven't grown out of as of yet.
0 new messages