NEON accelerated mplayer ???


Code:
ofbset -fb /dev/fb1 -mem 2764800

Then 'mplayer -vo omapfb' works with videos that have width upto 1024. For larger videos higher functional clock is needed for hardware scaler (change in kernel config) which might result in higher power usage.


Should we enable that ED?


Would at least be great to test that and see how much it really eats as battery!


Great to know omapfb works, I could now also make an mplayer with PickleLauncher, which would be great for a player where you don't want to use a touchscreen :D

[/CODE]
 
Code:
ofbset -fb /dev/fb1 -mem 2764800

Then 'mplayer -vo omapfb' works with videos that have width upto 1024. For larger videos higher functional clock is needed for hardware scaler (change in kernel config) which might result in higher power usage.


Should we enable that ED?

Would at least be great to test that and see how much it really eats as battery!


Great to know omapfb works, I could now also make an mplayer with PickleLauncher, which would be great for a player where you don't want to use a touchscreen :D
I just use the terminal to start mplayer. No touchscreen use there!
 
I just use the terminal to start mplayer. No touchscreen use there!

Me too, but I guess the normal user would be happy to have a GUI where he simply selects the file he wants to play and it plays nicely fullscreen ;)

Um... doesn't Smplayer take care of that? Isn't there a way to just use this command when starting mplayer? It'd be a shame to have to slap picklelauncher on everything.


Personally I can't stand the thing.
 
I just use the terminal to start mplayer. No touchscreen use there!

Me too, but I guess the normal user would be happy to have a GUI where he simply selects the file he wants to play and it plays nicely fullscreen ;)
Um... doesn't Smplayer take care of that? Isn't there a way to just use this command when starting mplayer? It'd be a shame to have to slap picklelauncher on everything.

SMPlayer can't do omapfb AFAIK and hides the menus behind the video, which is awkward.


Also, it's an X-Windows GUI, so it's not non-touch-friendly.
 
I just use the terminal to start mplayer. No touchscreen use there!

Me too, but I guess the normal user would be happy to have a GUI where he simply selects the file he wants to play and it plays nicely fullscreen ;)
Um... doesn't Smplayer take care of that? Isn't there a way to just use this command when starting mplayer? It'd be a shame to have to slap picklelauncher on everything.

SMPlayer can't do omapfb AFAIK and hides the menus behind the video, which is awkward.


Also, it's an X-Windows GUI, so it's not non-touch-friendly.

And I suppose I could just use a pnd to get the non-picklelauncher gui back if you do go ahead and impliment this.


Alright, I'll shut up. Keep doin' what you're doin'.
 
Well, working with my mplayer build, I got some mixed results on omapfb, I tried a pal encoded 1024x576 file, but it was just too much for the frame buffer to handle. If we can get that increased clock to get full 1280 stuff, we'll probably pretty easily be able to play at least 720p xvid content. Overclocking my pandora to 800mhz, and giving mplayer a combination of the options -fs -lavdopts skiploopfilter=all:fast:skipframe=nonref -vo omapfb -quiet -hardframe drop, I got an h264 encoded 960x720 file playing, there were some parts where it obviously couldn't keep up, and I had to seek a few times, and this was on an animated episode, so the decoding requirements were less, but it was playing. :D . I'm glad I decided to throw that file into the framebuffer, and even surprised at how well it was doing on a psuedo 720p h264 file. Only thing keeping me from doing tests on whether true 720p 1280x720 is the clock in the kernel. :) . Well, I plan on putting this mplayer binary out pretty soon anyway, but omapfb stuff is somewhat experimental, but I'll add some logic to the script that will detect whether smplayer is trying to use omapfb and set it up accordingly.
 
I made some mplayer tests 3 weeks ago. You can find the discussion here.


To avoid the mmap problem I wrote (with root privileges): "echo 2000000 > /sys/class/graphics/fb1/size"


Then configured mplayer to use omapfb for video and oss for audio. It works better than default, but I couldn't get H264+AAC 800x480 files to play properly even at 800 MHz. Also I had two issues I reported:


- The video is cut: there are two black borders at the top and bottom of the screen.


- There is tearing: vsync is not working.


Video playback is very important for me, and these issues make me go back to PSP for H264 video playback. It would be great to fix the vsync, the black borders ant to get 800x480 H264+AAC video playback working...
 
Last edited by a moderator:
Also, it's an X-Windows GUI, so it's not non-touch-friendly.

This isn't a criticism, I really love that double negative! Never say anything with a single word when you can stretch it to three. As a student I'd have been proud to pad out one of those 2000 word essays with something that confusing. :lol:


Edit, hang on, I'm confused, it's a double negative that seems to mean the same thing as a single negative, wtf... or is it, I'm suffering from sleep deprivation and my head is going to explode.
 
Last edited by a moderator:
Now, I don't see the point of being able to play back HD videos at all. After all, the screen resolution is only 480 pixels high: not HD. TV-out can't handle HD either, as far as I know.
Exactly my thoughts, so just to clarify: are we talking about sampling the movie down to 800x480 "on the fly"? (So you don't have to convert all your movie-files?)


This still sounds a lot like "hey guys, let's fit a brand new Porsche engine into this rusty old VW Beetle and then restrict it to 100 km/h because otherwise it falls apart ... why? Because we CAN!" :D
 
Last edited by a moderator:
I assume it means that 32mb+ would have to be permanently reserved in the OS which is not good. Would it be possible though to allow some kind of choice on bootup as to allocating the desired ram for the player? That way a simple reboot would let you have all system ram available to all progs if you were not going to watch video.
Yeah that might be possible, there is just no one to do the work for this.
Can grub be made to work on the pandora?
 
Only thing keeping me from doing tests on whether true 720p 1280x720 is the clock in the kernel. :)

Already pushed to git, next HF5 RC2 will have it enabled.

Then configured mplayer to use omapfb for video and oss for audio. It works better than default, but I couldn't get H264+AAC 800x480 files to play properly even at 800 MHz. Also I had two issues I reported:


- The video is cut: there are two black borders at the top and bottom of the screen.


- There is tearing: vsync is not working.


Video playback is very important for me, and these issues make me go back to PSP for H264 video playback. It would be great to fix the vsync, the black borders ant to get 800x480 H264+AAC video playback working...

Hm, sounds like omapfb wasn't really working well here, since I have no tearing with that anymore.


As far as I understood notaz used ofbset to use fb1 instead of fb0, maybe that makes some difference?
 
Then configured mplayer to use omapfb for video and oss for audio. It works better than default, but I couldn't get H264+AAC 800x480 files to play properly even at 800 MHz. Also I had two issues I reported:


- The video is cut: there are two black borders at the top and bottom of the screen.


- There is tearing: vsync is not working.


Video playback is very important for me, and these issues make me go back to PSP for H264 video playback. It would be great to fix the vsync, the black borders ant to get 800x480 H264+AAC video playback working...

Hm, sounds like omapfb wasn't really working well here, since I have no tearing with that anymore.


As far as I understood notaz used ofbset to use fb1 instead of fb0, maybe that makes some difference?

I *ALSO* set fb1: echo 2000000 > /sys/class/graphics/fb1/size
 
Now, I don't see the point of being able to play back HD videos at all. After all, the screen resolution is only 480 pixels high: not HD. TV-out can't handle HD either, as far as I know.
Exactly my thoughts, so just to clarify: are we talking about sampling the movie down to 800x480 "on the fly"? (So you don't have to convert all your movie-files?)


This still sounds a lot like "hey guys, let's fit a brand new Porsche engine into this rusty old VW Beetle and then restrict it to 100 km/h because otherwise it falls apart ... why? Because we CAN!" :D

For me the point has always been; it should be powerful enough to run 720p videos from all the devices with similar inards that already do. This would be a strong point of sale if it can save you time and raise efficiency by allowing you download a videos and slap it on your SD card without the extra step of forcing to re-encode, which is a pain.
 
For me the point has always been; it should be powerful enough to run 720p videos from all the devices with similar inards that already do. This would be a strong point of sale if it can save you time and raise efficiency by allowing you download a videos and slap it on your SD card without the extra step of forcing to re-encode, which is a pain.

I agree, transcoding h264 video is sloooooooooooooow. But I don't mind doing it. What is important for me is to achieve full resolution (800x480) H264+AAC flawless playback (no tearing, no black borders).


Do anybody know why are there black borders when in fullscreen mode? Am I the only one suffering this issue?
 
Posted a beta of my mplayer build at . Usage instructions in the post, it's not a pnd, but something you have to run from the command line. If anyone is interested in it, it's there. There'll be an actual pnd coming out probably in the next couple of days, have to wrestle with picklelauncher to get it to do what I want. :)


JDGBOLT
 
Back
Top