With 128MB on board RAM Is it fast enough to play HD720?

I am not sure the performance of OMAP3530 for HD video playback. Is
128MB is enough? In X86 we required 512MB or 1GB to get better
performance.

Yes, 128MB is sufficient memory for 720P video playback. I don't have
specific memory allocation numbers, but I've seen the video playing.

Charlie <charlie.to.ca@gmail.com> writes:

I am not sure the performance of OMAP3530 for HD video playback. Is
128MB is enough? In X86 we required 512MB or 1GB to get better
performance.

Memory size is not the problem here. For video playback, CPU/DSP
speed and memory bandwidth are the limiting factors. That said, 720p
video playback seems to be within reach, at least at moderate
bitrates. I don't think 1080p will be possible, though.













may be with some cleaver programing. using all three chips
ARM with (NEON) , TMS320C64x and the PowerVR chip
If someone could finger out how you could combined them to do 1080p HD

it has to be doable right! or is the the ram speed the bottleneck with HD.
The person who dus it will been in hi demand from all the cellphone companies. HD is the next big thing for the cellphone market. watching HD TV using your cellphone connected to your tv.

what a stage concept! but if you think about it, it makes sense and as the network speed gets quicker and quicker just another way to make some money out of the market.








So anyone smart enough to try?



— On Mon, 28/7/08, Måns Rullgård mans@mansr.com wrote:


> From: Måns Rullgård mans@mansr.com
> Subject: [beagleboard] Re: With 128MB on board RAM Is it fast enough to play HD720?
> To: beagleboard@googlegroups.com
> Date: Monday, 28 July, 2008, 8:48 PM
>
> <br>> Charlie <charlie.to.ca@gmail.com> writes:<br>> <br>> > I am not sure the performance of OMAP3530 for HD video playback. Is<br>> > 128MB is enough? In X86 we required 512MB or 1GB to get better<br>> > performance.<br>> <br>> Memory size is not the problem here. For video playback, CPU/DSP<br>> speed and memory bandwidth are the limiting factors. That said, 720p<br>> video playback seems to be within reach, at least at moderate<br>> bitrates. I don't think 1080p will be possible, though.<br>> <br>> -- <br>> Måns<br>> Rullgård<br>> mans@mansr.com<br>> <br>> <br>> <br>> ---<br>> <br>> <br>> Not happy with your email address?<br>> <br>> [ Get the one you <br>> <br>> really want](http://uk.docs.yahoo.com/ymail/new.html) - millions of new email addresses available now at [ Yahoo!](http://uk.docs.yahoo.com/ymail/new.html)<br>>

|

Memory bandwidth might be a problem: according to some lmbench
results, write BW is about 400 MB/s, and you need more than 350 MB/s
at 1920x1024x24 bit @ 60 fps (1080p60).

Laurent

If someone could finger out how you could combined them to do 1080p HD

Memory bandwidth might be a problem: according to some lmbench
results, write BW is about 400 MB/s, and you need more than 350 MB/s
at 1920x1024x24 bit @ 60 fps (1080p60).

What about YUV overlay? The memory bandwidth to the overlay
framebuffer would "only" need to be 225 MB/s (1920x1024x16 bit YUV422
x 60 fps).

Leave the SGX out of it because I don't think it will help. Use the
DSP to decode frames into a large ring buffer. The CPU then chains the
YUV buffers in a way the v4l video overlay device likes.

This assumes the pixel clock can go high enough to drive 1920x1024. I
seem to remeber someone on this list saying it basically can't on the
OMAP3 (although they could have been talking about the DVI driver IC
being the limiting factor - can't remeber).

"Tom Cooksey" <tomcooksey@googlemail.com> writes:

If someone could finger out how you could combined them to do 1080p HD

Memory bandwidth might be a problem: according to some lmbench
results, write BW is about 400 MB/s, and you need more than 350 MB/s
at 1920x1024x24 bit @ 60 fps (1080p60).

What about YUV overlay? The memory bandwidth to the overlay
framebuffer would "only" need to be 225 MB/s (1920x1024x16 bit YUV422
x 60 fps).

1920x1080 is the interesting resolution, and 30 fps should be enough.
This still needs about 120MB/s, which is just about the rate I've
managed to do the yuv420 to yuv422 conversion without doing anything
else.

Leave the SGX out of it because I don't think it will help. Use the

I'm quite sure it could help, if only we knew how to program it.
Since we don't, we might as well pretend it doesn't exist.

DSP to decode frames into a large ring buffer. The CPU then chains the
YUV buffers in a way the v4l video overlay device likes.

This assumes the pixel clock can go high enough to drive 1920x1024. I
seem to remeber someone on this list saying it basically can't on the
OMAP3 (although they could have been talking about the DVI driver IC
being the limiting factor - can't remeber).

The pixel clock can go up to 86.5 MHz. The HDMI standard 1080p at
30fps mode uses a 74.25 MHz pixel clock, so this is not a limitation.

TI did not declared that OMAP3530 can support HD 1080p at 30fps.

The benchmark of ARM Coretx-A8 of OMAP3530 is 1200 Dhrystone MIPS.
Nvidia's Tecra 650, that can play HD 1080p, is based on the ARM11
MPCore multicore processor technology for one and four cores
delivering up to an aggregate of 2600 Dhrystone MIPS of performance.

OMAP3 may need two ARM cores to support HD 1080p.

But if OMAP3530 can play HD 720p @30fps it is good enough.

Charlie wrote:

TI did not declared that OMAP3530 can support HD 1080p at 30fps.

The benchmark of ARM Coretx-A8 of OMAP3530 is 1200 Dhrystone MIPS.
Nvidia's Tecra 650, that can play HD 1080p, is based on the ARM11
MPCore multicore processor technology for one and four cores
delivering up to an aggregate of 2600 Dhrystone MIPS of performance.

The nvidia tegra has some unspecified GPU and maybe DSP in addition
to the ARM core(s). Since we don't know what that hardware is
capable of, comparisons are mostly pointless.

OMAP3 may need two ARM cores to support HD 1080p.

But if OMAP3530 can play HD 720p @30fps it is good enough.

As I said, at moderate bitrates this should be possible. I doubt
it has the power to process insane bitrates (>20Mbps) like those
used on bluray discs.

So are you are you using the CPU or the DSP for that?

can the Neon part of the ARM chip be used as well as the ARM at the same time?


— On Tue, 29/7/08, Måns Rullgård mans@mansr.com wrote:


> From: Måns Rullgård mans@mansr.com
> Subject: [beagleboard] Re: 1080p could be possible! and hear is how
> To: beagleboard@googlegroups.com
> Date: Tuesday, 29 July, 2008, 9:43 AM
>
> <br>> "Tom Cooksey" <tomcooksey@googlemail.com> writes:<br>> <br>> >>> If someone could finger out how you could combined them to do<br>> 1080p HD<br>> >><br>> >> Memory bandwidth might be a problem: according to some lmbench<br>> >> results, write BW is about 400 MB/s, and you need more than 350 MB/s<br>> >> at<br>> 1920x1024x24 bit @ 60 fps (1080p60).<br>> ><br>> > What about YUV overlay? The memory bandwidth to the overlay<br>> > framebuffer would "only" need to be 225 MB/s (1920x1024x16 bit<br>> YUV422<br>> > x 60 fps).<br>> <br>> 1920x1080 is the interesting resolution, and 30 fps should be enough.<br>> This still needs about 120MB/s, which is just about the rate I've<br>> managed to do the yuv420 to yuv422 conversion without doing anything<br>> else.<br>> <br>> > Leave the SGX out of it because I don't think it will help. Use the<br>> <br>> I'm quite sure it could help, if only we knew how to program it.<br>> Since we don't, we might as well pretend it doesn't exist.<br>> <br>> > DSP to decode frames into a large ring buffer. The CPU then chains the<br>> > YUV buffers in a way the v4l video overlay device likes.<br>> ><br>> > This assumes the pixel clock can go high enough to drive 1920x1024. I<br>> > seem to remeber someone on this list saying it basically can't on<br>> the<br>> > OMAP3 (although they could have been talking about the DVI driver IC<br>> > being the limiting factor - can't remeber).<br>> <br>> The pixel clock can go up to 86.5 MHz. The HDMI standard 1080p at<br>> 30fps mode uses a 74.25 MHz pixel clock, so this is not a limitation.<br>> <br>> -- <br>> Måns Rullgård<br>> mans@mansr.com<br>> <br>> <br>> <br>> ---<br>> <br>> <br>> Not happy with your email address?<br>> <br>> [ Get the one you <br>> <br>> really want](http://uk.docs.yahoo.com/ymail/new.html) - millions of new email addresses available now at [ Yahoo!](http://uk.docs.yahoo.com/ymail/new.html)<br>>

|

James Trigg <jamesleetrigg@yahoo.co.uk> writes:

"Tom Cooksey" <tomcooksey@googlemail.com> writes:

If someone could finger out how you could combined them to do 1080p HD

Memory bandwidth might be a problem: according to some lmbench
results, write BW is about 400 MB/s, and you need more than 350 MB/s
at 1920x1024x24 bit @ 60 fps (1080p60).

What about YUV overlay? The memory bandwidth to the overlay
framebuffer would "only" need to be 225 MB/s (1920x1024x16 bit YUV422
x 60 fps).

1920x1080 is the interesting resolution, and 30 fps should be enough.
This still needs about 120MB/s, which is just about the rate I've
managed to do the yuv420 to yuv422 conversion without doing anything
else.

Leave the SGX out of it because I don't think it will help. Use the

I'm quite sure it could help, if only we knew how to program it.
Since we don't, we might as well pretend it doesn't exist.

DSP to decode frames into a large ring buffer. The CPU then chains the
YUV buffers in a way the v4l video overlay device likes.

This assumes the pixel clock can go high enough to drive 1920x1024. I
seem to remeber someone on this list saying it basically can't on the
OMAP3 (although they could have been talking about the DVI driver IC
being the limiting factor - can't remeber).

The pixel clock can go up to 86.5 MHz. The HDMI standard 1080p at
30fps mode uses a 74.25 MHz pixel clock, so this is not a limitation.

So are you are you using the CPU or the DSP for that?

For what? Memory bandwidth and pixel clock are the same whichever
core does the decoding.

can the Neon part of the ARM chip be used as well as the ARM at the
same time?

The NEON unit receives instructions from the ARM pipeline, but
execution is not tightly coupled. This means that short instruction
sequences can execute in parallel. It is not, however, independent
the way the DSP is.