MPEG4/H264 Video decoding/encoding c libraries/apis with DSP acceleration (BB C4)?
Guy Zyskind
I've been reading around, and as far as I've seen all of the open
source implementations (Such the the XBMC port done by some students
in the Google summer of code) don't support hardware acceleration (on
the DSP).
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?
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.
In addition, I heard something about the MPlayer in the newer Angstrom
releases having a NEON video acceleration. How does that differ than
the DSP HW accelerated codecs TI provides, and is it possible to use
any library to take advantage of it? As far as I know mplayer is open
source, so if there is a way to take advantage of it's HW acceleration
methodologies, it might be the easiest solution.
Thanks for your help,
Guy
Jayanth Acharya
Had a somewhat similar kind of doubt, and a very quick read-up leads me to think that the NEON instructions are SIMD instructions added on the GPP (General Purpose Processor), which allow a single instruction to work on a multiple data elements in parallel. The GPP instruction set is the standard ARM instruction set, which for a given ARM processor family is consistent accross models and chip manfs (Atmel, Samsung, Sharp, NXP, ST...). However the DSP is a specialized processor with an altogether different instruction-set which help do DSP specific numerical computation much faster than the GPP. This processor is TI proprietary (AFAIK). So a I am guessing that by-and-large a codec implemented using ARM (incld. SIMD) instruction-set for the ARM processor, in-theory may work accross processors from diff. manfs. of same ARM family (or with very little modifications), but for many numerically intensive computation the DSP implements the entire logic in a block, possible in a single clock cycle, for which ARM processor requires several memory/register store/fetch, and multiple instructions. But then, I am learning... this is just information gleaned.
Anyhow, I would be quite interested in knowing the answers to your question, as I do continue to have questions around the TI codecs / alternatives.
cheers,
Jay
--
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.
Jayanth Acharya
Vladimir Pantelic
> Hi guys.
>
> I've been reading around, and as far as I've seen all of the open
> source implementations (Such the the XBMC port done by some students
> in the Google summer of code) don't support hardware acceleration (on
> the DSP).
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...
Vladimir Pantelic
> Oh, and BTW, the libavcodec (/ffmpeg) library does take advantage of SIMD
> instructions, on entire range of ARM processors... but of course, no DSP :).
> NEON, I believe is the marketing name of SIMD support on TI processors.
NEON is an ARM "marketing" name...
http://www.arm.com/products/processors/technologies/neon.php
Guy Zyskind
I've been reading some more about it, and indeed NEON is simply a
representative of SIMD support on ARM based processors. As this deals
directly with the ARM CPU and not the DSP, it isn't enough for my
video encoding/decoding needs. FFmpeg indeed uses it, and that
explains why the mplayer software supports it, but then again - it
won't be enough for more 'hardcore' tasks.
On Mar 8, 5:44 am, Jayanth Acharya <jayacha...@gmail.com> wrote:
> Oh, and BTW, the libavcodec (/ffmpeg) library does take advantage of SIMD
> instructions, on entire range of ARM processors... but of course, no DSP :).
> NEON, I believe is the marketing name of SIMD support on TI processors.
>
>
>
>
> > Guy,
>
> > Had a somewhat similar kind of doubt, and a very quick read-up leads me to
> > think that the NEON instructions are SIMD instructions added on the GPP
> > (General Purpose Processor), which allow a single instruction to work on a
> > multiple data elements in parallel. The GPP instruction set is the standard
> > ARM instruction set, which for a given ARM processor family is consistent
> > accross models and chip manfs (Atmel, Samsung, Sharp, NXP, ST...). However
> > the DSP is a specialized processor with an altogether different
> > instruction-set which help do DSP specific numerical computation much faster
> > than the GPP. This processor is TI proprietary (AFAIK). So a I am guessing
> > that by-and-large a codec implemented using ARM (incld. SIMD)
> > instruction-set for the ARM processor, in-theory may work accross processors
> > from diff. manfs. of same ARM family (or with very little modifications),
> > but for many numerically intensive computation the DSP implements the entire
> > logic in a block, possible in a single clock cycle, for which ARM processor
> > requires several memory/register store/fetch, and multiple instructions. But
> > then, I am learning... this is just information gleaned.
>
> > Anyhow, I would be quite interested in knowing the answers to your
> > question, as I do continue to have questions around the TI codecs /
> > alternatives.
>
> > cheers,
> > Jay
>
>
> - Show quoted text -
Guy Zyskind
more about it, and came across some new questions.
As you've mentioned, the GStreamer TI plugin seems like the most
extensive usage of the DSP power, since it wraps the DSP link and uses
TI hardware accelerated codecs (as far as I understand).
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-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-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-omapfb - As I understand this is only used to actually display the
information on the screen.
Thanks again,
Guy
On Mar 8, 9:44 am, Vladimir Pantelic <vlado...@gmail.com> wrote:
Guy Zyskind
Thank you for the details, I've read more about these concepts. It
seems that the widest application is indeed GStreamer, and I was
wondering if you could explain the difference between these projects I
found:
gst-ti - seems like a plugin that provides binaries which can be used
as pipelines
gst-dsp - Not sure what this is for, since there are other interfaces
to deal with the DSP on a low level.
gst-openmax - As far as I understand this is the most viable option.
It provides a similar API as the common OpenMax IL library. If this is
the case, than isn't this the natural choice ?
If you could explain how these projects differ (Regarding their
purpose), it could assist me in finding the right solution for my
issue.
Thanks again,
Guy
P.S: I apologize if thsi is a double post.
Vladimir Pantelic
> 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..)