--
You received this message because you are subscribed to the Google Groups "Beagle Board" group.
To post to this group, send email to beagl...@googlegroups.com.
To unsubscribe from this group, send email to beagleboard...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/beagleboard?hl=en.
correct
> I also read on TI's website that they provide some kind of SDK which
> includes specific hardware accelerated codecs for the OMAP3 processor.
> I was wondering if these codecs are incorporated into the Angstrom
> Demo image, or if there is a way to install them without using TI's
> image?
there are integrated and there is a way to "install" them separately
> The more important question I'd like to ask is if there's any decent
> documentation regarding how to use them? I've seen people resort to
> non-HW accelerated software implementations on the ARM core, which
> makes me wonder if there's no easy way to programmatically decode/
> encode video using the accelerated codecs.
TI DSPLink, Codec Engine and DMAI (these are all google'able terms)
come with a lot of examples. Also the TI DVSDK comes with the codecs
data sheets. It is not too hard to use the DSP codecs, it's just that so far
not many people even tried. Also the TI DSP codecs are integrated into
gstreamer (called gst-ti) so one can always look into the source code of
the gst-ti dsp component to see how to use/call the codecs...
NEON is an ARM "marketing" name...
http://www.arm.com/products/processors/technologies/neon.php
> What isn't clear to me, is the difference between the GStreamer plugin
> itself, which seems like binaries that one can only take advantage of
> using pipelines and the other forked projects that I'm not sure how
> they differ. So far I've seen these related projects:
>
> gst-ti (the direct plugin) - Binaries used with pipelines.
gst-ti -> DMAI -> CE -> DSPLink -> DSP CE -> DSP codecs
> gst-dsp - Not sure what exactly is the purpose of this one, as it
> seems like a more direct interface to the DSP which is already
> provided by the lower level DSP toolchain.
gst-dsp -> DSPBridge -> DSP SocketNodes -> DSP codecs
> gst-opemax - This sounds like the most interesting project, but I'm
> not sure if I'm correct here. Is it a port of the normal OpenMax IL
> standard? If it is, wouldn't it be easier to use a more 'global' way
> if it is indeed implemented to support the specific DSP HW used? If I
> understand this correctly, I can skip the other projects, including
> the direct plugin (Well, I might need to build it too if it's
> referenced), and use the widely spread OpenMax IL library API. Am I
> correct here?
gst-openmax -> TI OMX components -> libdspbridge -> DSPBridge ->
DSP SocketNodes -> DSP codecs
read "->" as "wraps", the actual codecs used in the end are all the same
namely TI XDAIS (more buzzwords!) compliant C64x codecs
So, you get to chose the number of wrappers :)
(I might have forgotten some wrappers in the above diagrams..)