> 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

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

> 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'

Invisible <voi### [at] devnull> 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

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

> 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

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

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

>> 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

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