Beijing University of Technology, 20981 Chen Yu
With the continuous development and evolution of smartphones, mobile phones are becoming more and more powerful, and their processing capabilities are getting higher and higher. smartphones with 200 MHz and MHz processors are no longer very rare, it has become a popular consumer of electronic goods, which also brings valuable development opportunities for third-party application software developers Based on smart phone systems. Looking at 3G as soon as possible, the average bandwidth on mobile phones should be around 64 kB in the future (from the TD perspective, it will be faster if WCDMA or CDMA is adopted ), this far exceeds the traditional k average bandwidth speed of GPRS. There should be a "bloody battle" in the mobile app development field. The developers will try their best to design their own "killer" applications to attract users and enrich their mobile phone functions, of course, at the same time, the platinum is full. : D. However, it all depends on whether applications that interest users can be created. I personally think that if 3G bandwidth can really be done very much, Once users can easily access the Internet from the mobile network, compared to Internet websites, traditional websites such as free WAP cannot compete with the Internet in terms of scale or content richness, and the problem of content homogeneity is serious. The Internet has a huge impact on the entire WAP industry. Application developers will also face the same problem. Let's take an example: for traditional WAP browser developers, the current Internet CSS, web 2.0 and video websites represented by YouTube put forward higher requirements for WAP browser. This is equivalent to putting forward higher requirements for developers of such applications.
Currently, most developers are dedicated to developing RSS applications on mobile phones. This is helpless for low-bandwidth GPRS networks. However, for users, there are only a few pieces of news and images. This mode is not enough in terms of user experience or user viscosity to attract users to use it for a long time, the common problem is that users are deleted in a few days. We also need to do a lot of work in the background, such as content preparation, editing, and processing. In this case, if the bandwidth is really wide, why don't you directly use Internet resources and user viscosity to do your own thing?
How nice is it to support YouTube on the Symbian platform? So I searched from Google and found an open-source project, mobiflv. This developer has been developing mobiflv for a long time and has indeed done a lot of valuable work. From the code point of view, he uses the porting scheme, extracts libavcodec from FFMPEG of open source, and migrates the Code only related to the FLV format to the Symbian platform. Currently tested, mobiflv supports h263 + MP3 or MPEG4 + MP3 video formats. The latest FLV formats that support h264 or h263 + AAC are not supported, if you want to use this code, pay special attention to this.
The following content is obtained through Google. The h263 video encoding and standard used in FLV is Sorenson H.263. Therefore, it differs from the h263 format encoding used in 3GP files: 1. Video tags composition: tag type 0x09tag data size 3 bytes video data size tag timestamp 3 bytes tag data application time (millisecond) Tag timestamp extended 1 byte timestamp extension, change the timestamp to 4 bytes. The current byte is used as the high timestamp. three-byte streamid class ID, always 02. Video tags data: the video tags data is similar to the videoframe In the SWF file format. their data is composed of the same video format: (1) Frame Type 4bit1: Key Frame keyframe (key frame in the video, the data stores the complete data of the entire screen, you can extract it to generate an image. 2. The inter frame of the intermediate frame (the State between key frames and incomplete image data must be generated based on the data of the previous frame). 3: any intermediate Frame disposable inter frame (H.263 only) (2) Video Encoding ID 4bit2: Sorenson H.263 (video encoding used for mencoder conversion) 3: screen video4: on2 vp65: on2 VP6 with Alpha channel6: screen video Version 2 (3) video data if codecid = 2 then codecid = 3 then screenvideopacketif codecid = 4 then codecid = 5 then codecid = 6 then screenv2videopacket here we will talk about Sorenson H.263 video encoding and Its packets: starting from swf6, FLA Sh uses a video encoding format known as Sorenson H.263. This format is based on H.263, a public video encoding standard proposed by ITU. would like to know H.263 encoding format of friends can refer to the http://www.chinavideo.org/index.php? Option = com_content & task = view & id = 123 & Itemid = 0 but there is a difference between Sorenson H.263 encoding and H.263: The following features do not exist in Sorenson H.263: ■ GOB (Group of blocks) layer ■ split-screen indicator ■ document camera indicator ■ picture freeze release ■ syntax-based arithmetic coding ■ Pb frames ■ continuous-presence multipoint ■ Overlapped Block-motion compensation the feature below is Sorenson H.263 added: ■ disposable frames (difference frames with no future dependen CIEs) ■ arbitrary picture width and height up to 65535 pixels ■ unrestricted motion vector support is always on ■ A deblocking flag is available to suggest the use of a deblocking filter about this mobiflv, compilation is very convenient. Code warrior or carbide C ++ can be used for compilation. the SDK version I use is Symbian 3rd FP1. Note that the Open c plug-in needs to be installed in mobiflv, the libavcodec decoder itself does not need to be used. This arrangement is a bit ironic. Haha, it is possible that open C is not used, but the front end is used again. Also, it seems that the compiling environment of vs2005 + carbide. vs plug-in cannot work. In addition, this version of mobiflv supports rvct, that is, you can use abld build armv5 urel to generate a test version on your mobile phone. rvct supports the thumb 16-bit instruction set, it is hard to imagine that the SIS package compiled by the player that supports FLV video is a little more than kb. I have passed the test using the n81 mobile phone.
From the code structure point of view, mobiflv is mainly divided into two parts: (1) libavcodec_mobitubia (which is the core part of libavcodec decoder) is completely the modification and transplantation of the FLV decoding part in libavcodec, this part of work is indeed doing very well without memory leakage.
(2) mobiflv (which is the front-end of the player call) should focus on the player. h producer player. CPP, which is detailed here (it can be said that the textbook-like code shows the libavcodec call method) I believe if I carefully read the player. CPP: "How does one convert video data into images? ", All doubts like this are clear at a glance.
Many of my friends are very troubled by how to synchronize Video and Audio Information in a video player. I will explain it with the code below:
To start video playback, you can use the following code in the cmobiflvappview: offerkeyeventl () function to enable cperiodic to quickly and cyclically call cmobiflvappview: playloop ():
iPeriodic = CPeriodic::NewL(0);
TInt tTickInterval = 1;
iPeriodic->Start(tTickInterval, tTickInterval, TCallBack(PlayLoopTick,this));
|
The playloop implementation is as follows:
TInt result = FetchCodecAndDecode(iPts, iNeoStreamPlayer);
if (result == -3) // End
{
iPts = FLVGetDuration() * 1000;
delete iPeriodic;
iPeriodic = NULL;
}
iNowTime.HomeTime();
iOffScreenBitmap->LockHeap();
if (DoWithDecoded((unsigned char*)iOffScreenBitmap->DataAddress(),EFalse,
iFirstFrameNum, iFirstFrameTimeStamp,
iFrameNum, iNowTime.Int64()) >MAX_FRAME_SKIP)
{
iFirstFrameNum = iFrameNum;
iNowTime.HomeTime();
iFirstFrameTimeStamp = iNowTime.Int64();
DoWithDecoded((unsigned char*)iOffScreenBitmap->DataAddress(),
EFalse, iFirstFrameNum, iFirstFrameTimeStamp,
iFrameNum, iNowTime.Int64());
}
FetchCodecAndDecodeSoundOnly(iPts, iNeoStreamPlayer, iAudioCurrentFTell);
iOffScreenBitmap->UnlockHeap();
User::ResetInactivityTime();
DrawNow();
|
Note that the key part of time processing here is the dowithdecoded function.
int DoWithDecoded(unsigned char* dst, unsigned char no_pic,
intfirst_frame_num, int first_frame_timestamp,
int& frame_num, intnow_timestamp)
{
const int should_b_frame_num = first_frame_num +
(now_timestamp -first_frame_timestamp) *
flvGlobalVar.framerate * 0.000001;
const int diff = frame_num - should_b_frame_num;
if (diff > 0)
return 0;
if (!no_pic)
{
if (diff == 0)
{
if (g_RectWidth == AVIdx && g_RectHeight == AVIdy)
ConvertYUV2BGRFast(avpict.data[0], avpict.data[1],
avpict.data[2], dst, avpict.linesize[0],
AVIdy, AVIdx);
else
ConvertYUV2BGRNeoFast(avpict.data[0], avpict.data[1],
avpict.data[2], dst,
avpict.linesize[0], AVIdy,
AVIdx, g_RectWidth,g_RectHeight);
numframeskipped = 0;
}
else
{
numframeskipped++;
}
}
is_decoded = false;
frame_num++;
return numframeskipped;
}
|
Pay close attention to the first two lines:
should_b_frame_num = first_frame_num + (now_timestamp -first_frame_timestamp) *
flvGlobalVar.framerate * 0.000001;
This row is used to calculate the duration of each frame based on the read framerate and frame rate. If the next frame has not been played, the diff will not be able to pass through, return. Haha, this is the essence of Audio and Video Synchronization. If framerate is available, the rest will be calculated directly and you can use a timer to control the time, this is of course because the H.263 decoding speed is relatively fast and does not cause timestamp to be reached. However, the current frame has not been completely resolved, so you do not need to skip the frame caused by decoder, there may be some differences in h264. Here, it is relatively simple and feasible, and the code is clear.
The remaining part of mobiflv is to call the open functions in player. h. I personally think that this so-called player API should be made into a class that is more in line with the Symbian style. There is a file that cannot be mentioned here, that is, yuvtorgb. H and yuvtorgb. CPP: the author used convertyuv2bgrneofast (), convertyuv2bgrneofastscaleup (), convertyuv2bgrneofastscaledown (), and even the NEO in the hacker Empire used the name, naturally, the author's confidence in these functions. The execution efficiency is naturally good. After a lot of table queries and manual displacement optimization, the efficiency is indeed good. It is recommended that you try this method with a friend who is still depressed about the video playback speed.
Any way, just work.
The following is a simulator:
The source code of this article is attached. Since the official website of mobiflv has received the influence of the domestic gateway, it is basically unable to log on. Access can be achieved through proxy, which is of great concern and need to be made by Chinese developers. I am here to be a good guy and paste all the source code of mobiflv 1.0 for developers:
|
| File: |
Mobiflv pack 1.00.zip |
| Size: |
285kb |
| Download: |
Download |
|
For code compilation and usage, see the release note in the code package. By the way, I also paste my unsigned SIS package for download and testing by interested friends.
|
| File: |
Mobiflv.rar |
| Size: |
51kb |
| Download: |
Download |
|
Note: You must copy a video named test. FLV to the C: // data // videos // directory of your mobile phone before using the video. Otherwise, leave will occur.
