| |
 |
|
|
Science Forum Index » Compression Forum » IBM showcase 3Mbps HD video encoding system
Page 1 of 1
|
| Author |
Message |
| Sportman |
 Posted: Sun Apr 13, 2008 12:13 am |
|
|
|
Guest
|
|
| Back to top |
|
| Sportman |
| Posted: Sun Apr 13, 2008 2:14 am |
|
|
|
Guest
|
On Apr 13, 1:09 pm, Thomas Richter <t...@math.tu-berlin.de> wrote:
Quote: I don't quite understand the claims here. On one hand, they say 80%
bandwidth reduction, which means a compression factor of 1:5, which is
pretty bad.
I think they mean 80% bandwidth reduction compared with the average
codecs used today.
Quote: So what's this all about?
This is my guess:
If they use a 4 core CPU at server side and encode at every core
simultaneously the same HD video with a different codec and keep track
about what part is how much compressed by what codec, then they only
need to transmit with a little delay the output part of the codec what
compressed a HD video part as best. At client side only 1 core is
needed for decoding by switching to the right codec for the part what
must be decoded. |
|
|
| Back to top |
|
| Thomas Richter |
| Posted: Sun Apr 13, 2008 6:09 am |
|
|
|
Guest
|
Sportman wrote:
I don't quite understand the claims here. On one hand, they say 80%
bandwidth reduction, which means a compression factor of 1:5, which is
pretty bad. On the other hand, they claim 6 times better than MPEG-2,
which can do much better than 1:5 for sure, 1:50 is not unrealistic, and
1:100 is definitely possible for video. And a comparison to H264 is
missing, which is state of the art, unlike MPEG-2, which is rather old.
So what's this all about?
So long,
Thomas |
|
|
| Back to top |
|
| Thomas Richter |
| Posted: Sun Apr 13, 2008 9:15 am |
|
|
|
Guest
|
Sportman wrote:
Quote: On Apr 13, 1:09 pm, Thomas Richter <t...@math.tu-berlin.de> wrote:
I don't quite understand the claims here. On one hand, they say 80%
bandwidth reduction, which means a compression factor of 1:5, which is
pretty bad.
I think they mean 80% bandwidth reduction compared with the average
codecs used today.
Ok, this makes "sort of" sense. I would believe comparing to MPEG-2
(H261 and related) is not much of a challenge, though. I would expect to
get - at usable qualities - to get twice to three times the rate with
more modern codecs. Five to six times better - well maybe a factor of 2
or three. Hmmm. I think I need a better estimate how well h264 and
similar codes work to get really an idea on this.
Quote:
So what's this all about?
This is my guess:
If they use a 4 core CPU at server side and encode at every core
simultaneously the same HD video with a different codec and keep track
about what part is how much compressed by what codec, then they only
need to transmit with a little delay the output part of the codec what
compressed a HD video part as best. At client side only 1 core is
needed for decoding by switching to the right codec for the part what
must be decoded.
For video, this doesn't look like a good approach for me. It means that
you would need to switch the codec here or there, which, at most, you
can only do at I-frames. It also means that the codecs loose the
statistical information built up over frames, which is neither a good idea.
So long,
Thomas |
|
|
| Back to top |
|
| Pete Fraser |
| Posted: Sun Apr 13, 2008 12:19 pm |
|
|
|
Guest
|
"Sportman" <sportman@gmail.com> wrote in message
news:f359cea5-c876-41f5-afdd-546e24e27828@m1g2000pre.googlegroups.com...
Quote: This is my guess:
If they use a 4 core CPU at server side and encode at every core
simultaneously the same HD video with a different codec and keep track
about what part is how much compressed by what codec, then they only
need to transmit with a little delay the output part of the codec what
compressed a HD video part as best. At client side only 1 core is
needed for decoding by switching to the right codec for the part what
must be decoded.
To some extent, something like that happens already.
When you consider H.264, there are so many intra and inter
prediction modes and tools available, that they're already
trying multiple "encoders" and selecting the best one.
It doesn't make sense adding other full encoders. |
|
|
| Back to top |
|
| Stefano Brocchi |
| Posted: Sun Apr 13, 2008 10:43 pm |
|
|
|
Guest
|
On Apr 13, 12:13 pm, Sportman <sport...@gmail.com> wrote:
Quote: News IBM showcase 3Mbps HD video encoding system:http://www.vnunet.com/vnunet/news/2214117/big-blue-planning-hd-video
Demo:http://www.codecsys.com/demo.html
Hello,
well this seems an article for the non-experts that says 'hey we did
something great'... for us who know something about compression
something more specific would be needed to understand the good and bad
ideas in the algorithm/format. The demo is visually very nice, but
doesn't explain how the choice of the coder works, so gives not much
information. In fact compressing the video with three different coders
and choosing the best for each chunk does not seem very smart, it
would be best if some previsions about the best coder could be done
before the encoding.
About the 4-6 times better compression, this again is a vague
information: a good one would be 'compresses n% better than this
format on this well-known video set'. I'm not criticizing the article
itself, I'm just saying maybe it's just too commercial and not enough
technical for us :)
So long,
Stefano |
|
|
| Back to top |
|
| Industrial One |
| Posted: Mon Apr 14, 2008 4:17 am |
|
|
|
Guest
|
I'm gonna quote Thomas Richter for truth. In addition, does anyone
remember that revolutionary video codec "EuclidVision" in 2006? |
|
|
| Back to top |
|
| |
|
Page 1 of 1
All times are GMT - 5 Hours
The time now is Sun Oct 12, 2008 5:20 pm
|
|