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

Orchid XP v8 wrote:
> I'm not really comprehending the significance of the distinction between 
> P frames and B frames...

P frames are differences from the previous I frame.

B frames are differences from the preceding and following frames, 
whether they be I or P or B.

In other words, you can't play a B frame at all without all the data 
between one I frame and the next.

Ever try to skip forward and back in a youtube video? Those jumps 
*there* are the I frames (or whatever equivalent). P frames need the 
previous I frame (and maybe previous P frames? I don't remember) and B 
frames need all the data between two I frames.

> True - but the Intel product line has been 32-bit over a 32-bit bus 
> since, what, the Pentium at least?

Yep. How long do you think DSL and MPEG1 has been around? :-)

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

Invisible wrote:
>> 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?

Wasn't that in MPEG1 already? (honest ignorant question)

Post a reply to this message

Nicolas Alvarez wrote:
> Wasn't that in MPEG1 already? (honest ignorant question)

I think it was, yes.

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

>> I'm not really comprehending the significance of the distinction 
>> between P frames and B frames...
> 
> P frames are differences from the previous I frame.
> 
> B frames are differences from the preceding and following frames, 
> whether they be I or P or B.
> 
> In other words, you can't play a B frame at all without all the data 
> between one I frame and the next.

I get that there are full frames and difference frames. I'm just not 
really understanding why there are two different kinds of difference 
frames...

> Ever try to skip forward and back in a youtube video? Those jumps 
> *there* are the I frames (or whatever equivalent).

Yeah, I figured that out a long time ago. ;-) Presumably otherwise you'd 
only have one I frame, right at the very start.

Post a reply to this message

>> P frames are differences from the previous I frame.
>>
>> B frames are differences from the preceding and following frames, whether 
>> they be I or P or B.
>>
>> In other words, you can't play a B frame at all without all the data 
>> between one I frame and the next.
>
> I get that there are full frames and difference frames. I'm just not 
> really understanding why there are two different kinds of difference 
> frames...

I think it's just because P frames are way simpler (both for encoding and 
decoding), so they get their own name.  It's very fixed how the behave (it's 
always the difference from the previous I frame), whereas B frames are much 
more flexible, having inputs from a number of frames ahead and behind (even 
from other B frames, which can make matters very complex).  Some players get 
confused if you use too many B frames, or use them in the "wrong" places, or 
use them at all!

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Nicolas Alvarez wrote:
> > Wasn't that in MPEG1 already? (honest ignorant question)

> I think it was, yes.

  The motion detection in mpeg4 is much more complicated than in mpeg1.
Mpeg4 can track the motion of freely-shaped areas.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   The motion detection in mpeg4 is much more complicated than in mpeg1.
> Mpeg4 can track the motion of freely-shaped areas.

Cool. I think MPEG1 was just 8x8 blocks. I knew they had to be doing 
*something* more complicated. :-)

Maybe here's something you know: If Xvid and DivX are MPEG4, why do you 
need a special codec to decode them? They're either outputting standard 
mpeg4 or they aren't, yes?

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message