 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> > 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.
And FFT is not the only thing an MPEG encoder has to do. Far from it.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>>> 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.
>
> And FFT is not the only thing an MPEG encoder has to do. Far from it.
Well quantinisation isn't exactly math-intensive, and the arithmetic
encoding stage shouldn't be too hard either. (It's fiddly to code
correctly, but it's all simple integer arithmetic.) I'm not sure what
else is *in* the MPEG encoder transform...
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> 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.
I'm not really comprehending the significance of the distinction between
P frames and B frames...
>> 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.
True - but the Intel product line has been 32-bit over a 32-bit bus
since, what, the Pentium at least?
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
