![]() |
[Canola] video good in mplayer, choppy in canola
hey there,
i have put a couple of music videos on the internal sdhc card class 6, and when I view them on canola, it is choppy and frames skip, but when viewed in mplayer, it plays fine (not computer perfect, but smooth enough). I thought I read somewhere in these forums that canola uses mplayer in some instances. My question is, is this behavior typical when playing these videos in canola? Video was about 4-5 min long, xvid encoded, avi file. |
Re: video good in mplayer, choppy in canola
canola with mplayer doesn't use the same video out driver (-vo) as the default mplayer interface.
The problem with "-vo nokia770" on the default mplayer gui is it isn't very friendly in slave mode (eg. embedded in conola) and the switch that canola uses isn't quite up to the level of performance as "-vo nokia770" so videos in the standard mplayer gui should preform a bit better. Hopefully I got it right :p I am sure someone will correct me if I am wrong :) Cheers -Rip |
Re: video good in mplayer, choppy in canola
That's not the only problem. The entire keyboard on the N810 seems not to work. So pause, skip, jump forward / back is not possible. It would be interesting why this does not work...
MiBi |
Re: video good in mplayer, choppy in canola
Hi guys, we are in beta, so being honest there's a lot more problems than those :) but we are working hard on several fronts to fix several issues each release.
So: videos, I will check to see if that's the case, but yes we do ask mplayer a window, don't know if that looses quality in the process, but for sure canola uses some cpu, then mplayer using full cpu can be fighting for it causing framing skips. MiBi: the hardware keys support is not implemented. So this is why it doesn't work. Our application is focused on touchscreen, but indeed we have nice plans for the hardware support but as we are focused on touchscreen I admit I left those low in the priority, because I think we should get things workings correct in the screen before doing other parts. http://www.marceloeduardo.com/blog/d...s-you-know-why here's a picture of the planned shortcurt using hardkeys : if you don't press is scroll.. if you press select comes this : http://www.marceloeduardo.com/blog/w...ens_player.png That will allow you to play, pause stop in any screen. Of course this makes more sense only for 800 and 770 users, so that's why it also went low on priority. Br Marcelo |
Re: video good in mplayer, choppy in canola
Quote:
Thanks for the feedback It's great to see people from a great project active in the community. I can't wait for canola to be out of beta as I love the interface. Cheers -Rip |
Re: video good in mplayer, choppy in canola
@handful
thanks for clarification. I thought that using mplayer for video playback automatically implements the keys for forward / back / etc. From my point of view, i don't need the hardware-keys as long as there is a possibility for me to jump forward / back 10 sec or a minute in my currently played video (in fullscreen mode). I am watching videos in the subway and when it gets to loud so that i cannot hear everything, i like to repeat a few seconds of the video to catch up. And of course pausing a video without leaving fullscreen when i have to change trains would be great. Perharps something like a playerinterface on screen shown when touching screen in Fullscreen playback.... Thanks for canola, it's really on a good track :D MiBi |
Re: video good in mplayer, choppy in canola
Quote:
I don't know how Canola does it exactly, but when playing a video with mplayer, Canola might be constantly talking to mplayer for retrieving things like the current position, or checking for end of file. This communication overhead could add additional choppiness. Lastly, when not in fullscreen mode, Canola constantly updates the progress indicator. mplayer becomes choppy when something outside its video area is being drawn. At least these are my experiences with embedding mplayer in slave mode. |
Re: video good in mplayer, choppy in canola
Quote:
We investigated and actually this and gapless playback we think that would be easy to implement in libXINE then in the others, but we don't have time to port libXINE correctly now (it does work out of the box, but needs optimization etc) So, thanks for the nice words and we will keep everyone informed as we go. Marcelo |
All times are GMT. The time now is 18:17. |
vBulletin® Version 3.8.8