2-hour length, 148.50 Mhz, 1920 x 1080 progressive scan image, 1-bit object data, 193 bits of file size
Radium
http://groups.google.com/group/sci.electronics.basics/msg/67ea1a75d326e0f8?hl=en&
:
> An empty wma file will have some overhead even if there is no 'data' within
> it.
> WMA files are wrapped in a ASF file structure which has the format:
>
> Object GUID 16 Bytes (128 bits)
> Object Size 8 Bytes (64 bits)
> Object data {as many as needed}
>
> so as a minimum, not knowing what type of WMA file is involved 192 bits (24
> bytes) are required. (probably somewhat more)
So is it possible to exist for the following to exist:
A WMV file of 2-hour length, 148.50 Mhz, 1920 x 1080 progressive scan
image, whose object data is only 1-bit in size due to massive
compression of color-depth? [this file would be 193 bits in size
because the the "object size" is 64 bits, the GUID is 128 bits, and the
object data is only 1-bit]?
If such a WMV file can exist, how would its video look like?
Thanks,
Radium
Bob Myers
"Radium" <gluc...@excite.com> wrote in message
news:1161909975....@i42g2000cwa.googlegroups.com...
> So is it possible to exist for the following to exist:
>
> A WMV file of 2-hour length, 148.50 Mhz, 1920 x 1080 progressive scan
> image, whose object data is only 1-bit in size due to massive
> compression of color-depth? [this file would be 193 bits in size
> because the the "object size" is 64 bits, the GUID is 128 bits, and the
> object data is only 1-bit]?
You still don't get it. A one-bit "file," no matter how it
was produced, can provide only one bit of information.
That SHOULD be obvious, but you're not thinking about
what it means. A single bit can convey what amounts to ONE
answer to a yes/no, or true/false sort of question - in other
words, just enough information to permit one to decide
between two and only two possible answers. That's why
people have been, in jest, talking about the multi-gigabyte
"decompression" routines your supposed "one bit" file would
require - what they really mean is that the "decompression"
program itself would have to contain all of the information
required to reconstruct either of two (and not more than two)
possible videos. Or in other words, you've just shifted the
burden of providing the information from the "video file" to
the "decompressor" - in effect, the "file" you're talking about
is just identifying which of two videos (contained elsewhere)
you want to see.
As usual, you need to learn a LOT more about the fields you're
trying to discuss (in this case, information theory and data
compression) before you leap to these absurd notions.
Bob M.
Radium
> You still don't get it. A one-bit "file," no matter how it
> was produced, can provide only one bit of information.
I never said the file size is 1 bit. The file size is 193 bits.
Bob Myers
Radium, old chap, here's exactly what you said:
"So is it possible to exist for the following to exist:
A WMV file of 2-hour length, 148.50 Mhz, 1920 x 1080 progressive scan
image, whose object data is only 1-bit in size due to massive
compression of color-depth? [this file would be 193 bits in size
because the the "object size" is 64 bits, the GUID is 128 bits, and the
object data is only 1-bit]?
If such a WMV file can exist, how would its video look like?"
You're clearly talking about the "object data" - i.e., all of the data
outside of the required overhead - being just a single bit. That's
the data that actually carries the video information, right? If not,
then what exactly DID you mean by "the object data is only
1 bit"?
And given THAT, the analysis I gave you is both correct and
relevant. You simply have no idea what you're talking about
here - once again.
Bob M.
Radium
> You're clearly talking about the "object data" - i.e., all of the data
> outside of the required overhead - being just a single bit. That's
> the data that actually carries the video information, right?
Yes. The "object data" is the video signal. So I just got the point. As
you say, one-bit would not work for this video. Then what is the
minimum bit required?
Martin Heffels
>Yes. The "object data" is the video signal. So I just got the point. As
>you say, one-bit would not work for this video. Then what is the
>minimum bit required?
Do yourself a favour, and play with the bit-depth of your computer-screen
and then play a movie. You will find the answer yourself.....
If the video is compressed down to 1 bit, it will be black or white, no
colour, no grey, no nothing. It's as simple as that :-)
cheers
-martin-
--
Bob Masta
I have the distinct impression that you are new to the concepts of
compression. Here's a thumbnail sketch: All compression schemes
can be divided into lossless and lossy. Lossless compression
works by analyzing the data and replacing large redundant areas
with smaller versions. For example, in a text file you might replace
each occurence of 'the' with a single byte or symbol. The compressor
also creates a "dictionary" table that allows you to determine the
long form from the symbol. Then the decompressor reads a symbol
and recreates the original.
If you think about it, you should realize that there is no way to
predict ahead of time how much compression is possible with
this scheme. If your source has a lot of redundancy, the compression
ratio is high. If the source is random data with no patterns, then
no compression is possible (by defininition). So if you had a video
taken with the lens cap on (all black) the compression would be
extremely high... just a symbol for "black" and a run length. If
you had a video of a swirling snowstorm (random black and white
dots) the compression might be non-existent.
But many real-world things like video and audio contain a lot
more information than most people want. For example, in an
audio recording, you probably don't care if the background hiss
is *exactly* the same waveform as the original. You can't really
tell one run of random hiss from another with the sme spectrum
and level. Similarly, human ears are really bad at detecting
absolute phase, or a soft sound in the presence of a loud one
at a similar frequency, and a whole lot of other stuff. So lossy
compression says, essentially, "if you can't tell the difference,
don't bother to save the details". In the hiss case, for example,
it could encode a few symbols to specify the spectrum, level,
and duration. A program of pure background hiss that could
not be compressed at all with lossless compression would
thus compress down to a few symbols. In the real world, of
course, we don't care about such cases. In concept, lossy audio
compression works by looking at the spectrum of sound snippets
and deciding which sounds would be masked by louder sounds
in the same frequency region, and trims those out. Then it
only has to store the frequencies and levels of the components
you can actually hear.
Another concept is to store only *changes* from one frame
to the next, whether we are talking about audio or video.
If everything is the same as the last frame, store a "ditto"
symbol and run length for the total number of frames that
are the same. If there is a small change, store only the
part that is changed.
So once again, you should see that there is no way to
predict maximum compression for a real-world case.
Hope that helps!
Bob Masta
dqatechATdaqartaDOTcom
D A Q A R T A
Data AcQuisition And Real-Time Analysis
www.daqarta.com
Home of DaqGen, the FREEWARE signal generator
Quanta
"Bob Myers" <nospam...@address.invalid> wrote in message
news:LOf0h.1674$di4...@news.cpqcorp.net...
A-men and Bravo!
Ken Maltby
"Bob Masta" <NoS...@daqarta.com> wrote in message
news:4541ffaa...@news.sysmatrix.net...
Great intro./basic description to this issue. It serves well as
a means to address a needed common level of understanding.
It covers all that most well need, to allow their use of
compressed video in most commercial products. Well done!
There is a great deal more in the way of using the "limitations"
of human perception, that goes into modern compression schemes
and the whole use of sophisticated algorithms to detect and
address/exploit such opportunities, would be next. Then the "Eyes
glazing over" would reach a level that causes most to stop reading.
I wouldn't have posted to this ridiculous thread but for your
reply.
Luck;
Ken
------------------------------------
To the rest of the thread:
While you can have a logical data of 1-bit, the computer has to
read data from a Byte. It can throw away the rest of the bits in a
Byte, but they must have existed. In fact, to have a usable data
structure will require more than one Byte, for an addressable data
element. Your 193 bits could be addressing some of that, but even
if it covered it all, there is still another factor.
Any program that might be expected to work with video "object
data" would require more than that "1-bit" of it, to function.
Bob Myers
There's no way of giving a single, absolute answer here - the
minimum "file size" or "object data" size for any compressed
information depends on the size, etc., of the original data, and
the nature of the compression and the desired quality of the
uncompressed result. Compression methods broadly fall into
two categories - "lossless," in which case the compression itself
does not degrade the data in any way (but it removes redundancy,
making the data more vulnerable to loss through noise in the
transmission channel), and "lossy," in which case you know there's
going to be some loss of quality no matter what - the question is
how much of a hit you're willing to take (which in turn often has
to do with what can reasonably be expected to be heard/seen
by the human user of this data).
Bob M.
>
Richard Crowley
> Yes. The "object data" is the video signal. So I just got the point. As
> you say, one-bit would not work for this video.
One bit would not work for ANY video.
One bit would not work for any AUDIO.
One bit would not work for any TEXT.
One bit could tell you whether the porch light is on.
One bit could tell you if you left the fridge door open.
One bit could tell you if it is night or day.
One bit = Yes or No. Nothing beyond that.
> Then what is the minimum bit required?
How may frames per sec? 30? 24? 15? 6? 2? 1? 1 per minute?
How much image degradation is acceptable?
You might even be able to get it down to several MB,
but nobody would want to watch it (or likely even
recognize it.)
Do you understand that your question is not answerable?
Or are you just trolling us?
Frank
in article <Re: 2-hour length, 148.50 Mhz, 1920 x 1080 progressive
scan image, 1-bit object data, 193 bits of file size>,
"Bob Myers" <nospam...@address.invalid> wrote:
For anyone who's interested, Microsoft offers as a free download
(sorry, I don't have the URL handy) a program called Windows Media ASF
View 9 Series (asfview.exe).
To see just how much overhead a Windows Media Video (.wmv) file has, I
just took a look at a typical 21,211,084 byte .wmv file with the
following results.
Header Object (2744 bytes)
Data Object (21,208,050 bytes)
Simple Index Object (290 bytes)
The program breaks down each of the above categories of data types
into as many as 13 subtypes, displaying the contents of each field,
and also offers the ability to display the raw contents of each
subtype in hex.
--
Frank, Independent Consultant, New York, NY
[Please remove 'nojunkmail.' from address to reply via e-mail.]
Read Frank's thoughts on HDV at http://www.humanvalues.net/hdv/
Radium
Richard Crowley wrote:
> "Radium" wrote...
> > Yes. The "object data" is the video signal. So I just got the point. As
> > you say, one-bit would not work for this video.
>
> One bit would not work for ANY video.
> One bit would not work for any AUDIO.
> One bit would not work for any TEXT.
>
> One bit could tell you whether the porch light is on.
> One bit could tell you if you left the fridge door open.
> One bit could tell you if it is night or day.
>
> One bit = Yes or No. Nothing beyond that.
Okay. I understand.
> > Then what is the minimum bit required?
> How may frames per sec? 30? 24? 15? 6? 2? 1? 1 per minute?
Frames per sec should not be decreased at all. The sample rate should
still be 148.50 mhz.
> How much image degradation is acceptable?
Infinite, as long as as the sample-rate [148.50 mhz], the frame-rate
[60 hz], and the pixel-resolution [1920 X 1080 progressive] are not
decreased. As for the color-depth, compress it as much as you want.
> You might even be able to get it down to several MB,
> but nobody would want to watch it (or likely even
> recognize it.)
Well, as long as the sample-rate, frame-rate, and pixel-resolution are
not decreased, I don't mind maximum WMV compression of color-depth.
> Do you understand that your question is not answerable?
Now I do.
> Or are you just trolling us?
No.
Dave Martindale
>Do yourself a favour, and play with the bit-depth of your computer-screen
>and then play a movie. You will find the answer yourself.....
>If the video is compressed down to 1 bit, it will be black or white, no
>colour, no grey, no nothing. It's as simple as that :-)
Well, not, it's not. When someone is discussing image or video
compression, and they refer to "one bit per pixel", they are almost
certainly *not* talking about bilevel black&white display. Instead,
they are talking about either a greyscale or colour image that has been
sufficiently compressed that the *average* bit rate is 1 bit per
pixel. But when the image is decompressed, it returns to some wider
format; usually 8 bits for greyscale and 24 bits for colour.
Dave
Ken Maltby
"Dave Martindale" <da...@cs.ubc.ca> wrote in message
news:ehuvt4$1n8$1...@swain.cs.ubc.ca...
Could you provide a reference to where such discussions
are going on? A paper perhaps, a journal?
Luck;
Ken
Pete Fraser
news:BpWdnc81tbm2ld7Y...@giganews.com...
>> compression, and they refer to "one bit per pixel", they are almost
>> certainly *not* talking about bilevel black&white display. Instead,
>> they are talking about either a greyscale or colour image that has been
>> sufficiently compressed that the *average* bit rate is 1 bit per
>> pixel. But when the image is decompressed, it returns to some wider
>> format; usually 8 bits for greyscale and 24 bits for colour.
> Could you provide a reference to where such discussions
> are going on? A paper perhaps, a journal?
>
Looks at the documantation of almost any video or image
compression tool.
For example, the usage example for Kakadu (JPEG2000):
a) kdu_compress -i image.pgm -o out.j2c -rate 1.0
-- irreversible compression to 1 bit/sample.
Ken Maltby
"Pete Fraser" <pfr...@covad.net> wrote in message
news:123c8$454349e8$43672514$23...@msgid.meganewsservers.com...
Even I could do better than that, but the point was that if
this annoying OP could be lead to such material he might
have a chance of gaining some better understanding of the
situation where a reference to a standard bitrate/color depth
like "one bit per pixel" doesn't mean "1-bit object data".
It took a series of threads by the OP before he was able to
post this thread with his still refusal to comprehend that you
can't create a *FILE* compressed to just one bit of "object
data" and some overhead. Not for 2 hours of video, not for
2 seconds, not for HD, not for SD. Not a WMV, or AVI,
or MPEG. Not with wavelet compression, or any other way.
You can't have:
"A WMV file of 2-hour length, 148.50 Mhz, 1920 x 1080
progressive scan image, whose object data is only 1-bit in size
due to massive compression of color-depth? [this file would be
193 bits in size because the the "object size" is 64 bits, the
GUID is 128 bits, and the object data is only 1-bit]?"
This FILE wouldn't be 193 bits in size. This FILE couldn't
exist. Too suggest otherwise, is only encouraging this folly. I
fully expect this OP to keep up his series of incremental
postings, on this matter, rather than crack a book, or even
Google for a published reference, but we need not waste
too much time trying to straighten out his misconceptions.
The information is out there for OP to find with a little real
effort on his part.
Luck;
Ken
Bob Myers
> Frames per sec should not be decreased at all. The sample rate should
> still be 148.50 mhz.
Why are you hung up on sample rate per se? Question:
if I could decrease the sample rate by eliminating "dead"
time in the original video signal (for instance, by cutting out
excess blanking time in which no image information was
being transmitted), would you find that acceptable?
>> How much image degradation is acceptable?
>
> Infinite, as long as as the sample-rate [148.50 mhz], the frame-rate
> [60 hz], and the pixel-resolution [1920 X 1080 progressive] are not
> decreased. As for the color-depth, compress it as much as you want.
Oh, OK - in that case, I can give you an infinitely-degraded
image in no bits at all! :-)
And why do you think that "color depth" is something
you can compress the daylights out of, but by Gawd, don't
touch there OTHER things?
Bob M.
Bob Myers
>> compression, and they refer to "one bit per pixel", they are almost
>> certainly *not* talking about bilevel black&white display. Instead,
>> they are talking about either a greyscale or colour image that has been
>> sufficiently compressed that the *average* bit rate is 1 bit per
>> pixel. But when the image is decompressed, it returns to some wider
>> format; usually 8 bits for greyscale and 24 bits for colour.
>>
>> Dave
>
> Could you provide a reference to where such discussions
> are going on? A paper perhaps, a journal?
Consider the following - the average data rate of an ATSC
digital television broadcast cannot exceed about 19.4 Mbits/sec.
In one second, a 1920 x 1080, 60 Hz (2:1 interlaced) HDTV
source generates at least:
1920 x 1080 x 30 = 62.2 million pixels.
So we have a data stream giving us under 20 million bits
each second, which we're going to have to turn into over
60 million pixels. That's under 3 bits/pixel, on average.
Ain't compression wonderful? (And it often gets down
to an average rate of around a bit per pixel...)
Bob M.
Pasi Ojala
> So we have a data stream giving us under 20 million bits
> each second, which we're going to have to turn into over
> 60 million pixels. That's under 3 bits/pixel, on average.
Or rather, 0.33 bits/pixel..
-Pasi
--
/She could not stop touching him. Both hands traced his hard cheeks,
his wonderful blue eyes, his strong nose, his firm lips, his ears./
-- Nynaeve in The Wheel of Time:"A Crown of Swords"
Radium
I think this is what I am describing. I could be wrong though.
Bob Myers
"Pasi Ojala" <alb...@pikkukorppi.cs.tut.fi> wrote in message
news:slrnek7hgh...@pikkukorppi.cs.tut.fi...
> On 2006-10-28, Bob Myers <nospam...@address.invalid> wrote:
>> So we have a data stream giving us under 20 million bits
>> each second, which we're going to have to turn into over
>> 60 million pixels. That's under 3 bits/pixel, on average.
>
> Or rather, 0.33 bits/pixel..
Oh, damn - I hate it when I do that....I really
need to stop and recheck my head, every so
often...
Bob M.
Radium
> Why are you hung up on sample rate per se?
Because I dislike aliasing.
> Question:
> if I could decrease the sample rate by eliminating "dead"
> time in the original video signal (for instance, by cutting out
> excess blanking time in which no image information was
> being transmitted), would you find that acceptable?
Yes. As long as no aliasing -- at *any* level -- occurs.
> Oh, OK - in that case, I can give you an infinitely-degraded
> image in no bits at all! :-)
LOL. There needs to be at least one bit. Otherwise the data doesn't
exist.
So it is true that 1-bit movie cannot exist. What about a WMV file that
is 148.50 Mhz sample-rate, 1920 x 1080 progressive scan image, whose
object data rate is a CBR of 1 bit per second? Could this exist? In 2
hours or this video, the file size would be 7,200 bits.
> And why do you think that "color depth" is something
> you can compress the daylights out of, but by Gawd, don't
> touch there OTHER things?
Because I hate pixelation and alaising with a passion. Pixelation and
aliasing make me make me sick. I don't mind the artifacts -- that I
think -- are associated with a WMV whose color-depth has been
compressed even to extremes while the sample-rate and pixel resolution
are left alone. It looks similar to what a WMA file with a 44.1 khz and
20 kbps sounds like -- I think.
What would be to the human eye what 44.1 Khz, 20kbps is to the eye?
The human ear needs at least 20 hz to hear the sound. The human eye
needs at least 60 hz for the light to appear solid. E.g. a hummingbird
wing flap is to high of a video-frequency for the human eye to see,
much like the sound of a dog-whistle is to high an audio-frequency for
the human ear to see.
WMA is my preferred type of perceptual encoding. Both WMAs and MP3s
will produce artifacts with a too-low bitrate. However, WMA's artifacts
are rather pleasant, while MP3's are digusting.
I have Adobe Audition 1.5. I generate a silent file. I save it as WMA
20 kbps, 44.1 KHz, mono. I convert file this to WAV and then back to
WMA several times. I make my last conversion to WMA and save it. I then
open this WMA file. Finally I increase the volume of the audio in the
WMA file and play. Intrigueing tones result. These tones are typical in
low bit-rate, high-sample rate WMA files. I believe something analogous
could be done to WMV video.
Not really. I've tried doing my Adobe Audition experiment with MP3. How
sickening MP3's audio artifacts are. Much like non-WMV video
compression of pixels are. Those pixelations are just nasty.
Radium
Radium wrote:
> Not really. I've tried doing my Adobe Audition experiment with MP3. How
> sickening MP3's audio artifacts are. Much like non-WMV video
> compression of pixels are. Those pixelations are just nasty.
Please ignore the "not really" in the beginning of the above paragraph.
It was a f--king
typo!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Radium
Bob Myers wrote:
>the question is
> how much of a hit you're willing to take (which in turn often has
> to do with what can reasonably be expected to be heard/seen
> by the human user of this data).
How about a video whose "object data" bit-rate is a CBR of 1 bit per
second with a sample-rate of 148.5 mhz and 1920 X 1080 progressive scan
image resolution? How would this video look like? In 2 hours of this
video, the file size would be 7,200 bits. Sounds like a good idea for
internet video streaming -- if it is possible to have a bit-rate of 1
bit per second.
Lionel
>So is it possible to exist for the following to exist:
>
>A WMV file of 2-hour length, 148.50 Mhz, 1920 x 1080 progressive scan
>image, whose object data is only 1-bit in size due to massive
>compression of color-depth? [this file would be 193 bits in size
>because the the "object size" is 64 bits, the GUID is 128 bits, and the
>object data is only 1-bit]?
No, it isn't possible. I've already explained why it isn't possible in
great detail, but you are obviously either too lazy to read it, or too
stupid to understand the explanation.
--
W
. | ,. w , "Some people are alive only because
\|/ \|/ it is illegal to kill them." Perna condita delenda est
---^----^---------------------------------------------------------------
Bob Myers
>> Oh, OK - in that case, I can give you an infinitely-degraded
>> image in no bits at all! :-)
>
> LOL. There needs to be at least one bit. Otherwise the data doesn't
> exist.
And hopefully you understand at this point why it's going to take
a LOT more than one bit, or even one bit per second. Again,
you REALLY need to look into some basic information theory.
How much information a given signal actually contains, and how
far you can compress that (and how) before you start to lose
some. Then you need to consider how much you can afford to
lose, and why. Once you do that, you will no longer be asking
questions like:
> So it is true that 1-bit movie cannot exist. What about a WMV file that
> is 148.50 Mhz sample-rate, 1920 x 1080 progressive scan image, whose
> object data rate is a CBR of 1 bit per second? Could this exist? In 2
> hours or this video, the file size would be 7,200 bits.
...to which the answer is still "no way."
>> And why do you think that "color depth" is something
>> you can compress the daylights out of, but by Gawd, don't
>> touch there OTHER things?
>
> Because I hate pixelation and alaising with a passion. Pixelation and
> aliasing make me make me sick. I don't mind the artifacts -- that I
> think -- are associated with a WMV whose color-depth has been
> compressed even to extremes while the sample-rate and pixel resolution
> are left alone. It looks similar to what a WMA file with a 44.1 khz and
> 20 kbps sounds like -- I think.
Why do you think that, though? Remember, in the sciences
- which includes physics, and information theory, and electronics -
what you FEEL the answer ought to be doesn't count for squat
until and unless you've got some reasoning and knowledge to
back it up.
Bob M.
Jim Leonard
> > And why do you think that "color depth" is something
> > you can compress the daylights out of, but by Gawd, don't
> > touch there OTHER things?
>
> Because I hate pixelation and alaising with a passion. Pixelation and
> aliasing make me make me sick. I don't mind the artifacts -- that I
> think -- are associated with a WMV whose color-depth has been
> compressed even to extremes while the sample-rate and pixel resolution
> are left alone. It looks similar to what a WMA file with a 44.1 khz and
> 20 kbps sounds like -- I think.
I think the terms you're searching for are frequency and amplitude.
Like you, I greatly prefer video presented at a very high framerate
(frequency) and don't care so much about color quality (amplitude). In
other words, if I had a (low) certain amount of bandwidth available, I
will take a 60fps video that is 4 colors any day over one that has 256
colors but runs less than 1fps. Both theoretical videos would have
exactly the same bitrate, but one would be a slideshow and the other
would be in motion.
You are very, very confused about information theory and compression.
Here's a quick primer: Lossless compression -- where sizes are reduced
without anything being lost -- involves searching the data for
redundancy and then recoding the data to eliminate that redundancy. So
the answer to your question ("how small can a video file get without
throwing anything away?") depends on how redundant the video is. If
it's nothing but a black screen, most of it is redundant and the file
can get compressed very small. If it's complex motion with lots of
changing elements, hardly any of it is redundant and it won't compress
hardly at all.
You are comparing lossless compression with WMV, WMA, etc. which are
LOSSY techniques. Those compression methods throw information away.
That is a totally different conversation, so you might need to restate
your question a bit.
Martin Heffels
wrote:
>Well, not, it's not. When someone is discussing image or video
>compression, and they refer to "one bit per pixel", they are almost
>certainly *not* talking about bilevel black&white display. Instead,
>they are talking about either a greyscale or colour image that has been
>sufficiently compressed that the *average* bit rate is 1 bit per
>pixel. But when the image is decompressed, it returns to some wider
>format; usually 8 bits for greyscale and 24 bits for colour.
Hang on. One bit per pixel, means that it can only have one value. Of
course with a LUT you could determine which value should be displayed.
--
Bob Myers
"Martin Heffels" <is....@oris.ityou.info> wrote in message
news:pmqck2he1gvbk8rpk...@4ax.com...
> Hang on. One bit per pixel, means that it can only have one value. Of
> course with a LUT you could determine which value should be displayed.
No, again, you're missing that all-important phrase "on average."
Talking about systems that use an AVERAGE of one bit per
pixel (or even less!) over the whole data stream doesn't really
tell you anything about the quality of the video being presented.
As was already discussed, standard HDTV operates at a data
rate such that there is, ON AVERAGE, less than one bit in the
transmitted data stream per pixel of the original X x Y pixel,
N frames per second video.
How that is achieved is actually quite clever...;-)
Bob M.
Martin Heffels
<nospam...@address.invalid> wrote:
>No, again, you're missing that all-important phrase "on average."
>Talking about systems that use an AVERAGE of one bit per
>pixel (or even less!) over the whole data stream doesn't really
>tell you anything about the quality of the video being presented.
>As was already discussed, standard HDTV operates at a data
>rate such that there is, ON AVERAGE, less than one bit in the
>transmitted data stream per pixel of the original X x Y pixel,
>N frames per second video.
I see. So what you mean is that of all the original bits, on average, one
is left, after all the compression is done? Interesting.
--
Dave Martindale
>I see. So what you mean is that of all the original bits, on average, one
>is left, after all the compression is done? Interesting.
None of the "original bits" is left. A compressor takes in a data
stream and generates a new, smaller, data stream that can be decoded to
some approximation of the original image or video sequence.
The bit rate of the compressed data stream is simply the number of bits
per unit time (frame, second, hour, whatever you prefer) divided by the
number of original pixels in that same time period.
Dave
Pasi Ojala
> One bit per pixel, means that it can only have one value.
If you have some kind of predictor coding, one input bit is
capable of much more than monochrome.
And, one bit per pixel _on average_ is capable of much more
still. Ever heard of arithmetic coding?
Martin Heffels
<alb...@pikkukorppi.cs.tut.fi> wrote:
>On 2006-10-30, Martin Heffels <is....@oris.ityou.info> wrote:
>> One bit per pixel, means that it can only have one value.
>
>If you have some kind of predictor coding, one input bit is
>capable of much more than monochrome.
That's why I mentioned a LUT, where you can make that bit to display
anything you want.
>And, one bit per pixel _on average_ is capable of much more
>still. Ever heard of arithmetic coding?
Arithmetic has always been my weak point at school ;-)
But I'll have a look into it.
-m-
--
Ken Maltby
You mean compression ratio, not bit rate.
One bit has no meaning until there is some significance applied
to it's two values. Within a computer, a bit exists as an element of
a byte. The position of a bit within a byte can be an element of data,
as well, which can change the significance of the bit's value. Bytes
are grouped/read as a word.
You don't have bytes of only one bit, even if the rest of the bits
have no significance they must be there. So in a computer you
can't have a bit stored all by itself.
Now the fact that I can assign any significance to each of a bit's
two values that I wish, doesn't mean it is carrying any more
information/data than that it is in one of two possible states.
There is no difference in the amount of information/data conveyed
between a bit where one state=0 and the other state=1, and a bit
where one state=the contents of The Library of Congress and the
other state=a picture of the moon.
The library contents nor the image data, are actually contained
within the bit. If I could somehow store that bit someplace (say
a file) and examine it outside of a program that assigns it's two
states a particular significance, it only carries the fact that it is in
one of its two possible states. The "file" with only one significant
data bit, would not contain anything more than that.
Now someone will say we are talking about a bit stream not
data stored on a computer. ( A bit stream of one bit? )
That the significance of each bit is established by the order in
which it is processed, not by a structure of the bits themselves.
( No bytes, just packets, that are only there for coordinating
the transmission of the stream.) But for this to actually mean
anything, you still need a series of bits to feed the process, one
bit won't do it.
If you could write a program to read one bit, and apply a
significance to one of the states of the bit to be; a "2-hour
length, 148.50Mhz,1920 x 1080 progressive scan image";
it would be in the program that the "image" data would have
to reside.
This is the state of affairs for any level of abstraction above
the two states inherent in the bit itself.
Luck;
Ken
Bob Myers
> I see. So what you mean is that of all the original bits, on average, one
> is left, after all the compression is done? Interesting.
No, let's try this another way.
Let's say you have an original video stream that consists
of - gee, I don't know - let's say 1920 x 1080 pixel
frames that come at you at a rate of 30 per second.
That would be 1920 x 1080 x 30 pixels per second, right?
Working out the above, we could say it's 62.2 million pixels
per second.
Now let's say that we compress this into a data stream which
has an average rate of - again, just to pick a number completely
at random - 19.39 Mbits/second.
On average, how many bits per pixel of the original
video stream does that compressed stream give you?
Bob M.
Ken Maltby
"Bob Myers" <nospam...@address.invalid> wrote in message
news:oUQ1h.1823$2Z....@news.cpqcorp.net...
>
> "Martin Heffels" <is....@oris.ityou.info> wrote in message
> news:c6rdk2t8gu4mkgffc...@4ax.com...
>> I see. So what you mean is that of all the original bits, on average, one
>> is left, after all the compression is done? Interesting.
>
> No, let's try this another way.
>
> Let's say you have an original video stream that consists
> of - gee, I don't know - let's say 1920 x 1080 pixel
> frames that come at you at a rate of 30 per second.
>
> That would be 1920 x 1080 x 30 pixels per second, right?
>
> Working out the above, we could say it's 62.2 million pixels
> per second.
>
> Now let's say that we compress this into a data stream which
> has an average rate of - again, just to pick a number completely
> at random - 19.39 Mbits/second.
>
2bpp CGA? 4bpp EGA? 8bpp VGA? 16bpp XGA,High Color?
24bpp True Color? How about the 32 bit I use for my desktop?
I guess you want to use the monochrome 1 bit per pixel, right?
That would be for both the original and the compressed, right?
Bob Myers
>> Working out the above, we could say it's 62.2 million pixels
>> per second.
>>
>> Now let's say that we compress this into a data stream which
>> has an average rate of - again, just to pick a number completely
>> at random - 19.39 Mbits/second.
>>
> Woah - How many bpp? Is it "1bpp" monochrome? Is it
> 2bpp CGA? 4bpp EGA? 8bpp VGA? 16bpp XGA,High Color?
> 24bpp True Color? How about the 32 bit I use for my desktop?
Doesn't matter. Again, the compressed stream is delivering data
at a rate which, relative to the original pixel rate, represents less
than one bit per pixel on average.
Now, it turns out that the numbers I picked in my example were
not (surprise, surprise!) chosen completely at random:
19.39 Mbit/sec is the actual data rate limit specified in the ATSC
(U.S. digital/HD TV) broadcast transmission standard.
1920 x 1080 at 30 frames/second, is, of course, a standard HD
format and frame rate. As it happens, such material is generally
originated as RGB data at at least 8 bits/color (24 bits/pixel);
long before getting to the compressed form of the final data
stream, it will most likely be re-encoded as YCbCr at something
less than a 4:4:4 sampling scheme - probably 4:2:2 or even 4:2:0
(which are systems that effectively reduce the spatial resolution
of the color components, while preserving the luminance component
at full resolution - this is itself a form of lossy compression vs. the
original RGB representation). The result then goes through a goodly
number of further compression processes, which results in the
cumulative data-rate reduction (compression ratio) seen in the end
result - something in the neighborhood of 80:1 vs. the original.
Bob M.
Ken Maltby
"Bob Myers" <nospam...@address.invalid> wrote in message
>
> "Ken Maltby" <kma...@sbcglobal.net> wrote in message
> news:TYSdnSQE7PZut9XY...@giganews.com...
>>> Working out the above, we could say it's 62.2 million pixels
>>> per second.
>>>
>>> Now let's say that we compress this into a data stream which
>>> has an average rate of - again, just to pick a number completely
>>> at random - 19.39 Mbits/second.
>>>
>> Woah - How many bpp? Is it "1bpp" monochrome? Is it
>> 2bpp CGA? 4bpp EGA? 8bpp VGA? 16bpp XGA,High Color?
>> 24bpp True Color? How about the 32 bit I use for my desktop?
>
> Doesn't matter. Again, the compressed stream is delivering data
> at a rate which, relative to the original pixel rate, represents less
> than one bit per pixel on average.
>
OK, so how many bits of "object data" does that put in Radium's
WMV file? More than one, I would guess. You have been reading
this thread, right?
Luck;
Ken
Bob Myers
> OK, so how many bits of "object data" does that put in Radium's
> WMV file? More than one, I would guess. You have been reading
> this thread, right?
If you look back through the thread, you'll see that I've
been contributing rather regularly - and as has been
said several times before, by myself and others, there
have to be a LOT more than just one bit. Or even one
bit per second.
Bob M.
Richard Crowley
"discussion"? It seems to me like one of the most
ridiculous wastes of time that has come along here
in months/years.
Martin Heffels
<nospam...@address.invalid> wrote:
>
>"Martin Heffels" <is....@oris.ityou.info> wrote in message
>news:c6rdk2t8gu4mkgffc...@4ax.com...
>> I see. So what you mean is that of all the original bits, on average, one
>> is left, after all the compression is done? Interesting.
>
>No, let's try this another way.
Sorry, I was a bit short in my answer, but I understood what you said :-)
My bad.
-m-
--
Martin Heffels
<nospam...@address.invalid> wrote:
>Doesn't matter. Again, the compressed stream is delivering data
>at a rate which, relative to the original pixel rate, represents less
>than one bit per pixel on average.
But this is a bit weird comparison. After all, a normal colour-image on tv,
can not be represented by 1 bit pieces. It would be better to speak in
terms of bytes, and then a compression-ratio makes more sense.
When I am compressing an video-image, I am not throwing away 7 bits and
keep 1. No, I throw away bytes which are occuring repeatedly (lossless), or
similar in colour (lossy).
-m-
--
Ken Maltby
"Richard Crowley" <rcro...@xpr7t.net> wrote in message
news:12kjpn8...@corp.supernews.com...
> Can anybody explain what is the point of this whole
> "discussion"? It seems to me like one of the most ridiculous wastes of
> time that has come along here in months/years.
Agreed.
Pasi Ojala
> keep 1. No, I throw away bytes which are occuring repeatedly (lossless), or
> similar in colour (lossy).
When someone else is doing video compression (btw, it not
AN image, video compression handles multiple images), it is
much more than that.
There's delta coding (differences between frames), transform coding
(for example DCT) and quantization (represent data that matters most
more accurately). And/or prediction and encoding only prediction error.
After this lossy phase you use lossless entropy codes.
-Pasi
--
"Maybe the doc's right. Embrace the moment. In the end, that's all we have.
Trouble will come in its own time, it always does. But that's tomorrow.
Give me today, and I *will* be happy."
-- Sheridan in Babylon 5:"Epiphanies"
Bob Myers
>>Doesn't matter. Again, the compressed stream is delivering data
>>at a rate which, relative to the original pixel rate, represents less
>>than one bit per pixel on average.
>
> But this is a bit weird comparison. After all, a normal colour-image on
> tv,
> can not be represented by 1 bit pieces. It would be better to speak in
> terms of bytes, and then a compression-ratio makes more sense.
> When I am compressing an video-image, I am not throwing away 7 bits and
> keep 1. No, I throw away bytes which are occuring repeatedly (lossless),
> or
> similar in colour (lossy).
Doesn't matter whether you talk about bits, bytes, words,
characters, or squamishes (a word I just stole from an old
Mad magazine to refer to data organized in 43-bit chunks).
You start out with this many bits, you wind up with this many
bits. It's just that "average bits per displayed pixel" has been
one of those fun ways of presenting compression ratio
information, especially in seminars where the objective of
the presenter is to elicit a "wow!" response from the audience
which is presumably learning about this stuff for the first time.
And you're never simply throwing away bits or bytes in
any practical compression scheme which is currently in
use; that would be far too crude. What happens in real-
world systems is far more complicated, and produces a
far better result.
Bob M.