Mplayer port on arm 2410

After porting Several Linux media players to the S3C2410 embedded development platform, I feel that the playback effect is not very good, and the video playing at the 320x240 resolution is not very smooth, is the speed of MB only available? I was a little disappointed. Last month, when mplayer received the news of the "new media" Award at the annual Linux World Expo, mplayer inspired my determination to migrate mplayer to 2410 again, although the previous transplantation results were not very successful.

When I first started desktop development in Linux, I heard that mplayer is called the most powerful media player in Linux history. It is easy to install on the desktop, simple configure and make, after installation, the interface is quite friendly with QT's Gui. Mplayer's extensive support for media formats and rich post-processing filters impressed me. The latest versions support DivX and H. the latest streaming media formats such as 264 and MPEG4 can play video streams online in real time. How nice it is to have such an excellent playback software transplant it to an embedded device!

There is a fs2410 Development Board in the company, the board of Shenzhen youlong, the CPU is Samsung's S3C2410, the kernel of arm9-, The board works very fine, it has been used for development in the past, the configuration is 10 at the time of purchase. A 4-inch sharp screen with a resolution of X is good, so that you can test the video playback speed at a resolution of X. The hardware platform solved the problem. Next, download the latest mplayer source code package. After all, the latest source code package has the latest functions. Of course, there are also a lot of bugs. Open the official website http: // www. mplayerhq. on the Hu homepage, you can see the "Download" link and click here to go to the download page. on this page, you can see the download section of "Daily CVS snapshot source, these links all point to the latest mplayer source code package submitted to the CVS server every day. Click here to download it!


1. Start Compilation


The downloaded source code is generally called the name of mplayer-current.tar.bz2.

Bunzip2 MPlayer-current.tar.bz2 | tar XV-

Check the README and install files that are decompressed to see if there is anything that is specifically stated during installation. This is my habit, because different versions of the same software sometimes have different installation methods. Then enter./configure -- help to check whether there are more or less options. Fortunately, there is no change, so I took out the previously configured mplayer command, copied it, and pasted it on the command line:


. /Configure -- cc = arm-Linux-GCC -- target = arm-armv4-linux -- enable-static -- prefix =/tmp/mplayer -- disable-win32 -- disable-dvdread -- enable-fbdev -- disable-mencoder -- disable-live -- disable-mp3lib -- enable-mad -- enable-libavcodec -- language = zh_cn


After the configuration is complete, start cross-platform Compilation: Make

Staring at every piece of information fed back by the compiler, I am always worried about errors. The mplayer source code is too huge,
Who can ensure that compilation is not a problem even though many third-party libraries are used? As a result, codec-CFG cannot be run and thus the header file cannot be generated. After checking, we found that the executable codec-cfg file was the first file to be compiled and generated. This file exists. Why can't it be executed? After a manual execution, the system prompts "cannot execute binary file". Suddenly, codec-CFG is compiled on a cross-platform basis and generates arm code, of course, it cannot be executed on x86, so we should first compile mplayer into x86 code without cross-platform compilation, and then reconfigure it, which is simple. /configure, make, and then
Codec-CFG is renamed codec-cfg.x86. Then configure according to the cross-platform way, compile, wait for the compiler to stop the compilation error, the codec-cfg.x86 name codec-CFG, then make, OK, compilation can continue.

Several errors occurred during compilation, which are caused by header file reference. It is important to note that there is an omission in the libmp codecs and libavcodec directories, that is, the source files of both directories are
# Incude "config. h to reference the header file "config. h, but the header file "config. H ", these source files are actually expected to reference the" config. H "header file,
Therefore, we need to manually create a link named config. h under the libmp codecs and libavcodec directories and point it to the "config. H" header file under the mplayer installation package root directory.


$> Cd libmp codecs


$> Ln-S ../config. h config. h


$> Cd ../


$> Cd libavcodec


$> Ln-S ../config. h config. h

After several edits, the compilation link to mplayer is successfully completed. Let's take a look at the size of the mplayer file, which is 10 MB or Z, I haven't compiled it into debug yet. So far, this is the first step to success.

2. Start debugging

Can the compiled code run normally on fs2410? I still have many questions. Power on the board, use a network transmission tool compiled by yourself to upload the code to the ramdisk of the board, and then upload a video about 10 MB. Well, run mplayer without parameters, the help information in Chinese is displayed, indicating that the program is basically compiled correctly. Enter the command. /mplayer matrix. mpg, eyes staring at the screen, looking forward to the appearance of the screen, unfortunately, after some video clip feedback, the program will no longer move, no way, press Ctrl + C to end the program, then the system prompts a segment error. I have heard that this error also occurs when LINUX embedded fans are transplanted. However, if the sound is not played, the image can appear, So enter the command. /mplayer-nosound matrix. mpg, then the screen is displayed. The video of the X size downloaded from the internet is playing smoothly, and it seems to be faster than the player decoding speed. Of course, it is X in size, there is no sound decoding.

The voice won't be solved. Of course, it cannot be said that the porting is successful, because mplayer also supports audio decoding in so many formats. But what exactly is the problem? Use exclusion! Find a WAV audio file that has not been compressed by any audio. It is a PCM file, uploaded to ramdisk, and played with mplayer. The same problem still exists, and the program is dead. Well, this shows that the problem does not occur in audio decoding, but is very likely in audio stream playback. Currently, most of the embedded development boards on the market use the OSS standard audio driver. I have previously done OSS programming and I am still familiar with this. So I started to check the mpalyer and C source files to see how the audio stream is played,

In the audio playback part, it uses the audio playback/control module of the libao2 library. By further viewing the ao_oss.c source code, we can further learn how mplayer works with the audio Linux driver. After this step is clarified, re-compile mplayer, enable the debug option, enable debugging string output, set multiple breakpoints at the audio playback, and add the printf statement to output some variable content, eventually, zero division error occurs when the play () function of ao_oss.c is called,

The root cause of this problem is the audio driver. Most embedded boards now use the Phillips uda1341 audio chip, so they all use the same audio driver, that is, mizi's copyrighted Linux uda1341 audio driver, this driver basically complies with the OSS specifications, but when using multi-segment DMA audio data transmission, a problem occurs, that is, the establishment of the DMA buffer occurs in the first call with write () when the function transmits audio data to the device descriptor, the OSS-driven caller usually wants to obtain the DMA buffer information when the audio device description is enabled, therefore, the buffer size is 0.

The solution is to add the following code to the smdk2410_audio_open () function body of the audio driver source code,

If (! Output_stream. buffers & audio_setup_buf (& output_stream ))


Return-enomem;

For details about the position to add, see the bold Section of the following code:



Static int smdk2410_audio_open (struct inode * inode, struct file * file)

{

Int cold =! Audio_active;



Dprintk ("audio_open/N ");



If (file-> f_flags & o_accmode) = o_rdonly ){

If (audio_rd_refcount | audio_wr_refcount)

Return-ebusy;

Audio_rd_refcount ++;

} Else if (file-> f_flags & o_accmode) = o_wronly ){

If (audio_wr_refcount)

Return-ebusy;

Audio_wr_refcount ++;

} Else if (file-> f_flags & o_accmode) = o_rdwr ){

If (audio_rd_refcount | audio_wr_refcount)

Return-ebusy;

Audio_rd_refcount ++;

Audio_wr_refcount ++;

} Else

Return-einval;



If (cold ){

Audio_rate = audio_rate_default;

Audio_channels = audio_channels_default;

Audio_fragsize = audio_fragsize_default;

Audio_nbfrags = audio_nbfrags_default;

If (file-> f_mode & fmode_write )){

Init_s3c2410_iis_bus_tx ();

Audio_clear_buf (& output_stream );

// Add the following line of code


If (! Output_stream. buffers & audio_setup_buf (& output_stream ))


Return-enomem;

}

If (file-> f_mode & fmode_read )){

Init_s3c2410_iis_bus_rx ();

Audio_clear_buf (& input_stream );

}

}



Mod_inc_use_count;



Return 0;

}



After the driver is changed, re-compile the kernel.



3. Conclusion


Because mplayer directly uses buffered frames or other optimization algorithms, the playback speed of the video on arm S3C2410 is significantly improved, at least at 320x240, the speed for extracting mpeg1 or 2 standard videos is quite smooth, but the MPEG4 decoding speed is still insufficient. The CPU of arm S3C2410 is a simple command, fixed-point computing,

Without MMX and hardware floating point computing, the capability of Large-size multimedia codec is still insufficient. The solution in the industry is to add a hardware codec DSP out of the CPU, or add a coprocessor In the SOC to enhance this function.


Postscript


After I learned that youlong has a new Development Board, XScale PXA255, I decided to give it to them for testing on the board. MPEG4 encoding. The video with the screen size of 320x240 is already quite smooth. This may be the effect of playing DivX videos with PDAs using PXA255 CPU on the market!