On Tue, 20 Feb 2007 10:52:46 +0000 Dieter <[EMAIL PROTECTED]> wrote:
> Peter's AMD64 3200+ can't decode mpeg4 in real time. (bitrate?)
> Even Attila "decode it in software" Kinali admits that a
> AMD64 3700+ isn't fast enough to decode H.264. (bitrate?)
I can decode h.264. Just not 1080p contend with all filters
enabled.
> So what is the solution?
Have a look at the diagram i made of a video decoding process
of a codec based on DCT (which is 90% of the material around).
Currently, the border between SW and HW on non-hw solution
video decoders is between Filters and Upsampling.
Mostly because of the lack of hardware and driver support
for more functionality. If you want to make hardware aided
video decoding, you have to move the border further left and
implement all functions within the process in hardware.
You cannot implement just the parts that are easy to do
in hardware as then you would need to transfere the stream
back and forth between CPU/main memory and the graphics card.
So first step would be to implement the filters in hardware
But, if you have a look into the h.264 specs on what kind
of filters are _required_ by the standard or on what kind
of filters an _average_ video player has to support, you'll
soon realize that this isn't something you can easily do.
Especialy as most of the filters are not stream based filters
on pixels, but stream based on lines or even on individual frames.
Ie, for each filter operation you have to have access to a large
amount of data which has to reside in the graphics card memory (DRAM)
because of its size. And if it's a more complex filter to even a
few frames. Not very friendly to implement in hardware.
Frame reordering is fairly easy, just passing around pointers
and having enough memory to store them all.
Motion compensation is again quite complicated. Less because
of the many algorithms that are around (there are only a hand
full of basic styles which can be quite easily abstracted) but
because it needs to access the whole frame. Ie you run into
the same problem as with the filters.
iDCT is again quite easy to implement in hardware and can be
easily parallelized and pipelined.
Stream decoding is, because of the multitude of formats out
there nearly impossible to do in hardware.
Also an issue that comes up with hardware decoding is, that
the further you move the border to the left, the more information
you need to have about the video stream. Ie you have to pass data
that is not purely picture data around. Which means, you have to
recode the data you get from the video into a format that the
hardware can use. This has to be done in software before the
stream goes into the hardware (suffers from the same problem
as stream decoding). And the design of the data representation
has to be done very carefully as you otherwise will restrict
yourself just to a small subclass of codecs and streams out there.
> 1) fully decode in TRV(sp?) chip?
> adds complexity, chip takes longer to design
Infeasible with our budget.
> 2) partly in CPU, partly in TRV chip?
> from previous discussion, this may be difficult
> or impossible?
The only way IMHO.
> 3) wait for AMD to sell a AMD64 30,000+ x16 CPU?
Impossible, light isnt that fast.
> 4) wait for TI to sell a faster DSP?
DSPs wont help as much as you think. DSP are for signal
processing, not for video decoding. Yes, video decoding
is to a certain extend signal processing, but not in a
way that maps easily into DSP like systems.
> 5) find out what the standalone Blu-Ray and HD-DVD
> players use, and see if we can use that
Forget that... unless you want to deal with NDAs and
closed source libraries.
> 6) something else?
Keep the current aproach.
Attila Kinali
--
Linux ist... wenn man einfache Dinge auch mit einer kryptischen
post-fix Sprache loesen kann
-- Daniel Hottinger
VideoDecoding.dia
Description: Binary data
VideoDecoding.png
Description: PNG image
_______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
