Demo of OMAP5 playing video.


TrashyMG

TrashyMG

Sarcasm Dispenser
Staff member
Joined
Jan 18, 2010
Messages
11,409
Some have stated some concern with video playback being an issue on the Pyra.. So I made a video demonstrating that it can more than handle 720p and 1080p .h264 encoded videos..

First video is 720p, I've fast-forward a few times to show speaking parts and such.. Amazingly I have very few 1080p videos on my file server all of them are animated it seems.. so I picked one..

Also to note It's drawing about ~650mA-700mA of current when decoding videos.. Prior tests it was running around well over an Amp.. The newer Kernel really does improve things.

https://www.youtube.com/watch?v=DKKMXPPjoPw

sorry for the shaky camera.. And that monitor isn't that great.
 
Last edited by a moderator:
Does the Pyra CPU has some hardware parts for .h264 decoding or is it just done due pure software?  Overall, it's good to see that .h264 works well because it actualy doesn't work at all onto my Pandora, no matter which player I try.
 
Fusion_Power said:
Does the Pyra CPU has some hardware parts for .h264 decoding or is it just done due pure software?  Overall, it's good to see that .h264 works well because it actualy doesn't work at all onto my Pandora, no matter which player I try.
Click to expand...
It's supposed to, but I believe that it's all being muscled by the CPU(s) at the moment..
 
Last edited by a moderator:
Not bad for CPU decoding. I hope hardware decoding can be made to work, so power consumption can go further down -- 650mA is still quite a lot (about 2.5 Watt, right?), and I guess that's without the screen/backlight, just the devboard? Then again that TI devboard probably has some power consuming stuff on it that is not on the Pyra. How much is the baseline power consumption when the CPU is being idle?

On my Pandora I can view (low res, 360p) movies while drawing only about 250mA (~1W), display included. That's not much more than the baseline ~180mA it draws when being mostly idle with the display on. And that's without hardware decoding (though I assume that the codec does have some optimized NEON code?).
 
I doubt we will have hardware video decoding, it'll be the same as with OMAP3 where TI's blobs are old and incompatible with most software or just too difficult to use to bother with them. And the decoding hardware is undocumented again, so not much hope for open implementation (even if it was documented, it's very unlikely somebody would do it anyway).
 
Last edited by a moderator:
Why do they include the decoding hardware then if nobody can use it? TI seems to be a funny company. :D

Anyways, has the hardware to be open to be used? Wouldn't just a closed source driver do the job? We may not be able to look inside but as long as it works, who cares. ^^"
 
Fusion_Power said:
Why do they include the decoding hardware then if nobody can use it? TI seems to be a funny company. :D

Anyways, has the hardware to be open to be used? Wouldn't just a closed source driver do the job? We may not be able to look inside but as long as it works, who cares. ^^"
Click to expand...
Well, no. You could use the closed source driver - as you could do that with the OMAP3 on the Pandora.

There are example distributions from TI available (both for OMAP3 and OMAP5) that can use hardware accellerated video.

But that doesn't mean it's easy to do.

No one has done it on the Pandora.
 
Last edited by a moderator:
notaz said:
I doubt we will have hardware video decoding, it'll be the same as with OMAP3 where TI's blobs are old and incompatible with most software or just too difficult to use to bother with them. And the decoding hardware is undocumented again, so not much hope for open implementation (even if it was documented, it's very unlikely somebody would do it anyway).
Click to expand...
As far as I understood, the OMAP3 doesn't really have hardware video decoding; the TI decoders use the DSP afaik, which is probably quite a bit more efficient than using the CPU, but probably not hugely so.

The OMAP5 does however have dedicated video coding/decoding hardware (called IVA-HD), which should be capable of doing very fast and low power encoding and decoding of a.o. h264.

From: http://processors.wiki.ti.com/index.php/GLSDK_Datasheet_OMAP5_6.04.00.02#Supported_Decoders

Multimedia_stack.png


I hope that this can somehow be made to work. There's more to be gained here than on the Pandora, because the difference between brute-force CPU decoding and dedicated hardware decoding should be larger than the difference between CPU and DSP, and also because the Pyra will have FullHD hdmi output so you might want to use it for lid-closed video playback, where the difference in battery life could be huge.
 
_wb_ said:
650mA is still quite a lot (about 2.5 Watt, right?)
Click to expand...

Just thinking about this, I was playing those videos off a 2.5" 120GB HDD via the SATA port.. It was powered using an external power supply, but wonder if it still would draw a bit more current vs just using the eMMC or SD card. something to try out when I get home.
 
Last edited by a moderator:
_wb_ said:
As far as I understood, the OMAP3 doesn't really have hardware video decoding; the TI decoders use the DSP afaik, which is probably quite a bit more efficient than using the CPU, but probably not hugely so.
Click to expand...
It does have hardware decode blocks for DCT, motion estimation, and loop filtering. They just have zero documentation aside from mention that they're there.

Fusion_Power said:
Why do they include the decoding hardware then if nobody can use it? TI seems to be a funny company. :D

Anyways, has the hardware to be open to be used? Wouldn't just a closed source driver do the job? We may not be able to look inside but as long as it works, who cares. ^^"
Click to expand...
It's because no one else wants to use the SoC for a general purpose Linux computer, instead just embedded tasks. It's not that no one can do it, just that it doesn't fit the software ecosystem wanted for Pyra.
 
The sgx gpus don't have x264 decoding features like the gpu in the raspberry for example?
 
Exophase said:
_wb_ said:
As far as I understood, the OMAP3 doesn't really have hardware video decoding; the TI decoders use the DSP afaik, which is probably quite a bit more efficient than using the CPU, but probably not hugely so.
Click to expand...
It does have hardware decode blocks for DCT, motion estimation, and loop filtering. They just have zero documentation aside from mention that they're there.
Click to expand...
They are documented - at least in the documentation for OMAP35x (the documentation for DM37x contains less information about them).
edgex004 said:
notaz said:
http://repo.openpandora.org/?page=detail&app=gst_dsp_pkg

Somebody just needs to update it to not insist installing it's own kernel and just run op_dsp.sh script instead.
Click to expand...
 How much work would that be and what is the potential gain? Would we possibly see better .h264 decoding, and could it be utilized by XBMC for higher quality streaming?
Click to expand...
The .h264 decoder supports files encoded using baseline profile. And since most files (AFAIK) are encoded using mainline profile or higher, it can't decode them.
 
Shenmue said:
Linux-SWAT said:
Can you continue the film at 1:32 please ?
Click to expand...
Sorry, OMAP5 crashed at that part as it is too weak to handle so much details there.  Ed, please change OMAP5 to Tegra K1 please ;)
Click to expand...
It was more that I was too weak and decided not to tempt fate with youtube's decency policy.. and keep dreaming about getting any nvidia chip.. it's not going to happen. 
 
You must log in or register to reply here.

Similar threads

bsp
Pandora successor requirements / wishlist / ..
2
Replies
38
Views
4K
Hồng Thất Công
Hồng Thất Công
Back
Top