|MPEG4/H264 Video decoding/encoding c libraries/apis with DSP acceleration (BB C4)?||Guy Zyskind||3/7/11 12:36 PM|
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
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
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,
|Re: [beagleboard] MPEG4/H264 Video decoding/encoding c libraries/apis with DSP acceleration (BB C4)?||Jayanth Acharya||3/7/11 7:42 PM|
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.
|Re: [beagleboard] MPEG4/H264 Video decoding/encoding c libraries/apis with DSP acceleration (BB C4)?||Jayanth Acharya||3/7/11 7:44 PM|
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.
|Re: [beagleboard] MPEG4/H264 Video decoding/encoding c libraries/apis with DSP acceleration (BB C4)?||vladimir||3/7/11 11:44 PM|
On Mon, Mar 7, 2011 at 9:36 PM, Guy Zyskind <guy...@gmail.com> wrote:
> I also read on TI's website that they provide some kind of SDK which
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
TI DSPLink, Codec Engine and DMAI (these are all google'able terms)
|Re: [beagleboard] MPEG4/H264 Video decoding/encoding c libraries/apis with DSP acceleration (BB C4)?||vladimir||3/7/11 11:45 PM|
On Tue, Mar 8, 2011 at 4:44 AM, Jayanth Acharya <jayac...@gmail.com> wrote:
NEON is an ARM "marketing" name...
|Re: MPEG4/H264 Video decoding/encoding c libraries/apis with DSP acceleration (BB C4)?||Guy Zyskind||3/8/11 2:16 AM|
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 Tue, Mar 8, 2011 at 9:12 AM, Jayanth Acharya <jayacha...@gmail.com>wrote:> >>http://groups.google.com/group/beagleboard?hl=en.- Hide quoted text -
> - Show quoted text -
|Re: MPEG4/H264 Video decoding/encoding c libraries/apis with DSP acceleration (BB C4)?||Guy Zyskind||3/8/11 2:29 AM|
Thanks Vladimir for the details, I've been googling and reading some
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
gst-omapfb - As I understand this is only used to actually display the
information on the screen.
On Mar 8, 9:44 am, Vladimir Pantelic <vlado...@gmail.com> wrote:
|Re: MPEG4/H264 Video decoding/encoding c libraries/apis with DSP acceleration (BB C4)?||Guy Zyskind||3/8/11 3:36 AM|
I'm not sure my previous post was received,
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
gst-ti - seems like a plugin that provides binaries which can be used
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
P.S: I apologize if thsi is a double post.
|Re: [beagleboard] Re: MPEG4/H264 Video decoding/encoding c libraries/apis with DSP acceleration (BB C4)?||vladimir||3/8/11 10:43 AM|
On 03/08/2011 11:29 AM, Guy Zyskind wrote:
> What isn't clear to me, is the difference between the GStreamer plugin
gst-ti -> DMAI -> CE -> DSPLink -> DSP CE -> DSP codecs
> gst-dsp - Not sure what exactly is the purpose of this one, as it
gst-dsp -> DSPBridge -> DSP SocketNodes -> DSP codecs
> gst-opemax - This sounds like the most interesting project, but I'm
gst-openmax -> TI OMX components -> libdspbridge -> DSPBridge ->
read "->" as "wraps", the actual codecs used in the end are all the same
So, you get to chose the number of wrappers :)
(I might have forgotten some wrappers in the above diagrams..)