Release Pandora Devboard: Mplayer, Picodrive, Quake 1 And Battle For Wesnoth

[Alpha2]

You can find the Ti H264 Decoder that use the DSP(C64x) but it don`t use HighProfil, only Base Line/Main Line. This codec can be used with GSStreamer. The limiter on OMAP is the memory bandwidth
CODE
http://focus.ti.com/docs/toolsw/folders/print/tmdh264d.html

Actualy all Vids use HighProfil (blueray format)
Max BP for HighProfil: 300 Mbit/s (1080p) 17.5 Mbit/s (720p 30FPS) 25 Mbit/s (720p 60FPS)
Max BP for Base line or Main: 240 Mbit/s (1080p) 14 Mbit/s (720p 30FPS) 20 Mbit/s (720p 60FPS)

FFMPEG codec using ASM ARM and Neon are efficient too.


I;m an incredible layman when it comes to many computational measurements so I;m going to take a wild swing at this, but I take it to mean it;s possible to get some of these videos to play because Arm is such a trooper but they;ll be slow like an inefficient game emmulator because of low bandwidthin the OMAP itself? Does Mplayer have some sort of frame skip feature that might help?

Just trying to wrap my non-coder brain around the concept.

 

[Monk]

BTW... how did the burntest turned out? I probably missed that one on the forum.

Doesn't the burn-in test happen on every mass-produced unit to avoid DOAs, or short-lived units?

Yes.
I just read it on the frontpage of the website, though I had no idea when the article was published lol.


No. IIRC it was Ed that said they'd only have to test each unit if they had a very large number of failures, but certainly the burnin tests are to test a given number from a batch. So if they have a batch of 400 and they test (say) 20 and all are fine, they assume the rest will pass the same tests. If 10 fail then they have a major problem with the batch and would most likely need to test them all.

 

[JDGBOLT]

You can find the Ti H264 Decoder that use the DSP(C64x) but it don`t use HighProfil, only Base Line/Main Line. This codec can be used with GSStreamer. The limiter on OMAP is the memory bandwidth
CODE
http://focus.ti.com/docs/toolsw/folders/print/tmdh264d.html

Actualy all Vids use HighProfil (blueray format)
Max BP for HighProfil: 300 Mbit/s (1080p) 17.5 Mbit/s (720p 30FPS) 25 Mbit/s (720p 60FPS)
Max BP for Base line or Main: 240 Mbit/s (1080p) 14 Mbit/s (720p 30FPS) 20 Mbit/s (720p 60FPS)

FFMPEG codec using ASM ARM and Neon are efficient too.


I;m an incredible layman when it comes to many computational measurements so I;m going to take a wild swing at this, but I take it to mean it;s possible to get some of these videos to play because Arm is such a trooper but they;ll be slow like an inefficient game emmulator because of low bandwidthin the OMAP itself? Does Mplayer have some sort of frame skip feature that might help?

Just trying to wrap my non-coder brain around the concept.


Mplayer does support frameskipping, the rate is automatic when enabled, so when in a more demanding part, it will drop more frames. But one interesting bit of trivia that at least works on x86 but should on pandora too is a nice little command line option that greatly reduces the requirements for h264 video. The quality is noticably worse, with things that should say be a smooth gradient in anime being more grainy, but is an option for 720P video. The command line option is "-lavdopts skiploopfilter=all" , and I found it on some mplayer optimization page somewhere for h264. Had a use for it because on my laptop I had a dying cpu fan, and could only run it in the lowest speed setting, which was 800mhz. Normally 720P video would be a practical slideshow, but with that optimization, with some sacrificing of image quality, it managed to be quite playable, with it only stuttering and going slideshow when the motion on screen got pretty intense. Otherwise it played and played relatively well. No longer have to do that, as I have since replaced the fan, but it's a useful optimization from a user of mplayer to you all.

JDGBOLT

 

[Alpha2]

thanks hopefully i;ll remember this post when the time comes... assuming there isnt some other fix that comes up by then.