Flask - again?

Hello everybody

first of all, I wish to apologize with all of you tired of Flask-related stuff.
Please, don't fire me

I am employee in ST microelectronics. Our group works on MPEG related algorithms, and my specific job since 1999 was to develop an mpeg transcoder - that means, a piece of sw capable of converting an mpeg stream in another stream with different characteristics, ie bitrate.
Does that seems familiar to you? Right, that's something very similar to Flask.
The simplest way to transcode an mpeg stream is to
1.decode the source bitstream
2.encode with new parameters (for ease, encode at lower bitrate)
that's what is called a decoder-encoder pipeline. It's not the best architecture (in fact, it is far from optimal) but it is easy to realize.
Flask implements an mpeg decoder, and redirects its output to a Premiere-compatible plugin which does the encoding.
Of course, the computational cost of the pipeline is the sum of the decoding+encoding cost.
Decoding is WAY faster than encoding, and moreover it is an ISO standardized process. That means, every ISO-compliant decoder offers the SAME output: there can be some differences only in speed and/or memory consumption (thus any involvement of IDCT implementation on quality is simply nonsense).
When I say WAY faster, I mean some 1-2 magnitude level: decoding can be 20-30 times faster than encoding - with a FAST encoder (the reference TM5 from MSSG is some 100 times slower).
What I stated before means that the pipeline cost is mainly due to the encoder and that the final quality depends on encoder decisions, too.
Here's my concern: why Tom, Intel and AMD have been discussing on Flask (the decoder), while nobody talks about the DivX plugin (the encoder)?
Someone could say: "hey, you said that the encoder is the most time-critical part of the pipeline: then why just optimizing Flask we have seen improvements of 1:10?"
That's the second question: that means that DivX encoder does not really does a fine encoding job.
Some more explanation is then necessary: the greater cost of encoding vs. decoding is mainly due to motion estimation. In fact, the speed of an encoder can be approximated to the speed of its me engine, plus some overhead (IDCT, DCT, VLC etc.).
If the encoder is nearly as fast as a decoder (as it seems from the tests), then it simply does no motion estimation, or something near to that. That could be done by a MV0 estimation, which means that the motion is approximated to be null.
I will not proceed in deeper technicisms, I simply say that a bad motion estimation means bad quality.
Well, it could be that DivX guys have done such a good job that their encoder is even faster than a decoder. If that's the case, they deserve all my respect. Sorry: they deserve it anyway

Of course, all that has nothing to do with CPU evaluation: it is simply some question from someone very interested in mpeg trascoding.
Thus I am off topic, and I apologize for it; still I feel some of you may be interested in this post.
Let me partially run to the shelters: if SSE2 means packed arithmetics (more than one integer processed in a single cpu issue), then you bet it boosts streaming operations to lightspeed. DCT, FFT, linear filtering, nearly any signal processing algorythm can take advantage of it.
But someone has already said that before me.