Video player


Oscaruzzo

Member
Joined
Sep 26, 2005
Messages
227
Age
50
Location
Italy
Website
Visit site
Hi, I just tried to play a video with mplayer (downladed from the official support page with the codec pack) and it VERY slow (i.e. not usable).


Is the decoding still done in software? Is there some library that uses the hardware codecs or some link on how to use it?
 
Hi, I just tried to play a video with mplayer (downladed from the official support page with the codec pack) and it VERY slow (i.e. not usable).


Is the decoding still done in software? Is there some library that uses the hardware codecs or some link on how to use it?

There are players for the Beagleboard using the DSP (you can search for them), but no one took care of that right now.


Make sure you use XV in MPlayer and not X11. H264 is too much without DSP, but any xvid up to 800x480 should run fine (unless the datarate is too high for your SD Card to stream - but that's something else ;) )
 
There are players for the Beagleboard using the DSP (you can search for them), but no one took care of that right now.

This a big task? For some reason I thought video playback was already hardware assisted....


Or is this more to do with the current Kernel not playing nice with the DSP? Would be great to get this sorted...
 
This a big task? For some reason I thought video playback was already hardware assisted....


Or is this more to do with the current Kernel not playing nice with the DSP? Would be great to get this sorted...
It's the kernel. The DSP bridge is built into the .37 kernel, and I can make it work (or at least compile) with the .32 kernel, unfortunately we've got the .27 kernel on the Pandora. A disturbing number of things changed between .27 and .32 that makes it difficult to update the Pandora to the newer kernel (due to driver issues) and to backport the DSP bridge to .27.


TI's DSP code is still evolving anyway. Waiting may be the best course of action for the time being, unfortunately.
 
It's actually possible to play h264 sd content fairly well with mplayer from the command line with a bit of overclocking. You just have to pass mplayer -lavdopts skiploopfilter=all:fast, with overclocking to 750 and it seems to work pretty well. A few dropped frames here and there, but overall watchable. You can even pass it -lavdopts skipframe=nonref:skiploopfilter=all to have it drop frames that aren't reference frames, makes it kind of jerky, but playable. Seeking can have a few problems, but for the most part it works pretty well. I'm currently trying to figure out how to set up a cross compiling environment to try to get a svn version of mplayer in a snapshot and perhaps an smplayer gui to have a good baseline. Smplayer in my opinion is one of the best mplayer frontends, and it works pretty well. We kind of need a newer snapshot of mplayer since the one we have is pretty ancient, I'm sure there have been a lot of arm optimizations since 2009, and also I think we lack swscale, which means if you try to play a file larger than the screen, mplayer will die, which is quite annoying to be honest. Will keep working on it, and hopefully we can have a good pnd to playback, as I tried the VLC, and it worked even worse than the mplayer in the codec pack. :)
 
^ great to have someone on the job!


Now if only those kernel-devs would keep up :rolleyes:
 
Yeah, been looking and poking around a bit here and there, not sure why, at least on mine, playing a video larger than the screen size will cause xv to freak out, with the only way to get it to play it is to pass it a -vf scale=x:y parameter, which can really slow down decoding. Hopefully it's just something with the mplayer that's in the community pack, and not a limitation of the driver we are using, though searching around in google a bit didn't really leave me with any meaningful results, with the last time mplayer spitting out that error message being sometime in 2006/2007. And our mplayer isn't QUITE as ancient as I thought, as the svn revision it was based off of was early january of 2010, still, there has probably been a fair amount of work done since then, a year in software development can be huge, depending on the project. Will try to be using the latest code sourcery to build mplayer, as it looks like there has been quite a few optimizations for arm done between the 2009 and 2010 versions, with gcc versions 4.3 and 4.5 respectively. And for some reason the mplayer build doesn't have support for vorbis audio, no idea what happened there.
 
Always head for git.openpandora.org if in doubt. The xv implementation in the omapfb X driver limits input size to the screen resolution. Go and fix it if you want to - I dont care enough.
 
Hi, I just tried to play a video with mplayer (downladed from the official support page with the codec pack) and it VERY slow (i.e. not usable).


Is the decoding still done in software? Is there some library that uses the hardware codecs or some link on how to use it?

There are players for the Beagleboard using the DSP (you can search for them), but no one took care of that right now.


Make sure you use XV in MPlayer and not X11. H264 is too much without DSP, but any xvid up to 800x480 should run fine (unless the datarate is too high for your SD Card to stream - but that's something else ;) )
Strange when I use XV I get audio only, using x11 I get both, any idea why?
 
Back
Top