Notices

I just got hold of mplayer today, and the first video I attempted to play was an NSV file. Audio works great, but unfortunately, no video playback

I understand from reading the rest of this topic that this is probably due to the lack of codecs that will run on an ARM processor?

Are there any plans for VP6 implementation in the future? VP6 on NSV scales well across the Internet, and should be playable on the 770's hardware.

(I'm involved in a Internet TV station similar to ESS.TV, so getting NSV to work on my 770 would be fantastic!)

Thanks for your great work so far!

Is there a list of files mplayer will play as it stands? I just get audio on wmv files, same as I did in the command line version.

Another Youtube video that does not work:
http://www.youtube.com/watch?v=1AQX1HUHK50

Maybe 320x240 flv videos with long playtime do not work at all (with sound)?

has anyone gotten the mplayer GUI to work? I get the "loading" dialog box and then nothing.

For me it works fine.
Maybe you should try to start it over xterm with gmplauncher and see whats worng.
Or try to uninstall it and reinstall it.

This thread sure is getting long. I've just searched all through it to see whether the info I'm interested in is available, and I couldn't see it, my apologies if I've missed it.

I see that there was mention of performing the audio decoding using the ARM and the video decoding using the DSP, but that this was excluded because of the picky nature of the video DSP plugins. My question is basically the following: how would the audio and video ideally be split (assuming someone puts the effort in to write the DSP video decoders, etc.)?

I presume that the DSP is not running at 100% just decoding the audio, and that video decoding would almost certainly cause it to run at a higher load, and I also assume that the speed increase in using the DSP rather than the ARM to decode the video is greater than using the DSP rather than the ARM to decode the audio (I hope that makes sense). I may be wrong about this..? This does assume that either the DSP or ARM carries out all of the processing for either the audio/video, though splitting the larger of the two tasks between the two parts of the chip may be another option. It also assumes that both the DSP and ARM have equal memory bandwidth to the display, and this may not be the case, and would therefore influence the choice of video decoding.

I'd be interested to see CPU/DSP load figures and hear other people's thoughts about this.

Cheers,


Si

2lardman: There was an idea about also using DSP for scaling (video controller does not have scaling support), there was also an attempt to do this http://www.mail-archive.com/maemo-de.../msg05345.html
Considering all this, seems like C55x DSP programming is a very hard task (without proper tools, documentation and examples), as it is a very unusual cpu. So I don't feel like doing any DSP programming in the near future, it seems to be more efficient to use what is already provided on the device (like MP3 decoding using DSP) and apparently developed by the people who are proficient with this. The default video plays performs scaling in some way, so probably the code for it exists. It would be best if Nokia could provide some high level API for using colorspace conversion and scaling: http://www.mail-archive.com/maemo-de.../msg04511.html

On the other hand, ARM core also has some enhanced DSP instructions and is supposed to be suitable for multimedia: http://arm.com/pdfs/DVI0035B_926_PO.pdf
Moreover, optimization of video decoding to use these armv5te instructions has been already started and there are some results already (in upstream ffmpeg SVN, one of the ffmpeg developers got Nokia 770 too ). The next build of mplayer for nokia 770 will also use these optimizations.

To everyone asking about what codecs are supported and what are not. I'm not an upstream MPlayer developer and I don't know everything MPlayer is now built in default configuration, some codecs may be not compiled in, some may be buggy. I even did not hear about some of these codecs at all and do not have video samples to test if they work with MPlayer. My personal priority right now is to ensure that MPlayer is good at playing converted video with full fps and high quality. Once this milestone is reached (and we are very close to it), I may switch to some other tasks like ensuring more different and exotic codecs support or attempt at getting some nonconverted video played more or less acceptable. Anyway, as it is written in my signature, feel free to join If you are interested in some codec support, feel free to investigate how to enable it, fix any bugs it may have on arm architecture and submit a patch. Adding more developers to a project is always welcome.

2serge mp3 decoding is not handled by the system on chip dsp but by a specialized codec dsp. this can be confermed by running
cat /sys/devices/platform/dsp/loadinfo
this leave 70% of the dsp for othr tasks such as scaling.. dspfbsink handles scaling i guess through the on chip dsp. I will try to make a driver for this. but since i am starting with next to no knowladge im sure it will take me to the end of jjanuary. january is also when ill have some free time.
thankyou

I don't know how dspfbsink manages scaling and if it is any good, that's essentially a black box as all the other closed source plugins on Nokia 770. After, dealing with audio decoding using gstreamer sinks, I would prefer to stay away from it for a while

As for scaling using DSP chip, seems like it should be possible in spite of the previous unsuccessful attempt. I got some docs in .pdf's descriping Nokia 770 DSP core (C55x), and looks like it can be actually good for scaling. Here is the description of additional extensions that seem to be supported by OMAP1710 DSP core: http://focus.ti.com/lit/ug/spru098/spru098.pdf
Check "Pixel interpolation Hardware Extension" part

There are also lots of references to other docs, they are quite interesting to read.

And in general, DSP does not seem so bad from looking its presentation and benchmark results: http://www.omimo.be/magazine/01q2/2001q2_p034.pdf

Well, it is good to know, but I hope that all the most important mplayer porting work will be finished by that time already Anyway if things will not proceed as good as expected, your help will be welcome in January