![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> Now compare the MPEG2 video back-to-back with the uncompressed original.
> Are you seriously telling me there is *no* detectable loss of quality?
Depends on the content - if your video consists of data you would typically
use PNG to encode rather than JPG, or where each frame is vastly different
from the previous one, then of course it's not going to compress well.
MPEG2 was designed to work well with real life captured video, and it does
that pretty well within the 10Mbit allocated by the DVD standard.
Another example, I made a video of some planets rolling about in POV, the
original uncompressed frames totalled 9.7 GB, after using MPEG4 the video
came out as 28MB, that's 350x smaller! Really, there is no noticeable
difference in quality, I can't tell the difference by looking at a
freeze-frame in VLC compared to the original BMP.
> Sure, it's a fairly small loss, but it *is* noticable. I wonder what the
> bitrate would need to be increased to for it to be impossible to tell the
> difference...
Depends on the content of course.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
scott wrote:
>> Now compare the MPEG2 video back-to-back with the uncompressed
>> original. Are you seriously telling me there is *no* detectable loss
>> of quality?
>
> Depends on the content - if your video consists of data you would
> typically use PNG to encode rather than JPG, or where each frame is
> vastly different from the previous one, then of course it's not going to
> compress well. MPEG2 was designed to work well with real life captured
> video, and it does that pretty well within the 10Mbit allocated by the
> DVD standard.
Commercial DVDs do seem to do this quite well. (For some reason, DVDs I
encoded myself aren't quite as good - although they're still not bad
considering the compression ratio.)
> Another example, I made a video of some planets rolling about in POV,
> the original uncompressed frames totalled 9.7 GB, after using MPEG4 the
> video came out as 28MB, that's 350x smaller! Really, there is no
> noticeable difference in quality, I can't tell the difference by looking
> at a freeze-frame in VLC compared to the original BMP.
That's some pretty steep claims. ;-)
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> That's some pretty steep claims. ;-)
Here's the difference scaled up by a factor of 32 from one frame. You
cannot see the difference even when studying the two stills closely.
Post a reply to this message
Attachments:
Download 'diff.png' (254 KB)
Preview of image 'diff.png'
![diff.png](/povray.off-topic/attachment/%3C490ee6b7%40news.povray.org%3E/diff.png?preview=1)
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Invisible <voi### [at] dev null> wrote:
> Commercial DVDs do seem to do this quite well. (For some reason, DVDs I
> encoded myself aren't quite as good - although they're still not bad
> considering the compression ratio.)
Creating an MPEG2 stream is far from an unambiguous process. Some programs
do a much better job than other programs ever could, no matter how much you
fine-tune their settings.
--
- Warp
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Warp wrote:
> Creating an MPEG2 stream is far from an unambiguous process. Some programs
> do a much better job than other programs ever could, no matter how much you
> fine-tune their settings.
When last I looked, encoding to MPEG1 basically involves taking the DCT
of each frame, in the style of JPEG. There's also some fun with
different frame types. It looked to me like there's basically only one
possible bitstream you can produce. (Well, no, you can fiddle with the
quantinisation matrix, and if you're doing variable bitrate there are
some possibilities.)
I'm not actually sure how MPEG2 differs from MPEG1. I know they added
some more features, but I don't know specifically what.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> When last I looked, encoding to MPEG1 basically involves taking the DCT of
> each frame, in the style of JPEG. There's also some fun with different
> frame types. It looked to me like there's basically only one possible
> bitstream you can produce. (Well, no, you can fiddle with the
> quantinisation matrix, and if you're doing variable bitrate there are some
> possibilities.)
It's not surprising that mpeg2 and 4 are much more complex than this. The
key concept is how to describe the current frame fairly accurately with the
minimum amount of data, given some data from previous (and in some cases
future) frames. Commonly motion is detected, as often blocks of pixels
hardly change, but are shifted in space from one frame to the next. So you
could say that the whole frame is a copy of the previous frame, but with
some region from 5 frames ago shifted right 23 pixels, and then with some
additional data and pixel changes. Obviously then there is more than one
possible bitstream depending on how good your motion detection code is,
which frames you reference, what tolerance you use for detecting motion, etc
etc. And of course at some point you need to consider the CPU power needed
to encode the video.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
scott wrote:
> It's not surprising that mpeg2 and 4 are much more complex than this.
On the contrary, it would be surprising if MPEG2 was *not* more complex
than this... ;-)
> The key concept is how to describe the current frame fairly accurately
> with the minimum amount of data, given some data from previous (and in
> some cases future) frames. Commonly motion is detected, as often blocks
> of pixels hardly change, but are shifted in space from one frame to the
> next.
...so they added motion prediction then?
> Obviously then
> there is more than one possible bitstream depending on how good your
> motion detection code is, which frames you reference, what tolerance you
> use for detecting motion, etc etc.
Indeed.
> And of course at some point you need
> to consider the CPU power needed to encode the video.
I'm usually more interested in how much CPU power is required to
*decode* the video. Let's face it, no codec on Earth is as slow as
POV-Ray. ;-)
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Invisible wrote:
> There's also some fun with different frame types.
That's the main place the ambiguities come from. If you don't understand
the ways in which you can build a B-frame, you're not going to see where
you can get good quality at low bitrates for video with things moving.
MPEG1 had motion prediction too. It's just that the CPU power needed to
do it never got cheap before MPEG2 came out.
Back in 1991 or so, I worked with someone who encoded 6 minutes of Star
Wars as MPEG1 for testing video on demand. They sent it out to a place
that had a specially-built cluster of machines for doing this work, and
it took several CPU weeks. (This was in the same timeframe where doing
jpeg compression needed special hardware cards in a PC, to the point
where it was faster to ship the image to the PC with the card, compress
it, and ship the results back, than it was to do in software.)
--
Darren New / San Diego, CA, USA (PST)
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
>> There's also some fun with different frame types.
>
> That's the main place the ambiguities come from. If you don't understand
> the ways in which you can build a B-frame, you're not going to see where
> you can get good quality at low bitrates for video with things moving.
>
> MPEG1 had motion prediction too. It's just that the CPU power needed to
> do it never got cheap before MPEG2 came out.
I know that MPEG has several different kinds of frames, some of which
are individual, independent frames, and some of which are related to
previous frames. I can just never remember the exact details; every
reference on the subject that I've ever read has made it sound insanely
complex, when obviously it isn't.
> Back in 1991 or so, I worked with someone who encoded 6 minutes of Star
> Wars as MPEG1 for testing video on demand. They sent it out to a place
> that had a specially-built cluster of machines for doing this work, and
> it took several CPU weeks. (This was in the same timeframe where doing
> jpeg compression needed special hardware cards in a PC, to the point
> where it was faster to ship the image to the PC with the card, compress
> it, and ship the results back, than it was to do in software.)
Damn. And here I was thinking an integer-arithmetic FFT would be really
fast...
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Invisible wrote:
> I know that MPEG has several different kinds of frames, some of which
> are individual, independent frames, and some of which are related to
> previous frames. I can just never remember the exact details; every
> reference on the subject that I've ever read has made it sound insanely
> complex, when obviously it isn't.
It's pretty easy. There's three kinds of frames:
I - Independent. Basically JPEG. Used when going FF and Fast Reverse.
About every half second.
P - Predictive. Differences based on the previous I frame. About five
per I frame.
B - Bidirectional. Based in the previous and following frame.
Lots of cheaper mpeg encoding software doesn't do B frames, because
they're a PITA to calculate efficiently. Natch, with faster and faster
CPUs, this becomes less of a problem. 5 or 10 years ago, you could spend
weeks looking for an easy-to-use compressor that would do B frames.
I think the higher numbered MPEGs added more options to the encoding of
B frames, so that you could look at more than just one frame away, for
example.
> Damn. And here I was thinking an integer-arithmetic FFT would be really
> fast...
When your CPU is a 16-bit CPU on an 8-bit bus running at a dozen MHz,
even integer FFT is slow.
--
Darren New / San Diego, CA, USA (PST)
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |