QQ Object Joint Docking

The following are QQ linked audio and video related parameters:

our app audio and video parameters

Video: H264

Audio: PCM (8K sampling, 16bit, single channel)

Middleware provides interfaces externally:

QQ IoT Connection: HTTP://IOT.OPEN.QQ.COM/WIKI/INDEX.HTML#!CASE/IP_CAMERA.MD

Interface package refer to QQ IoT as follows:

Initialization

Inteq_initdevice ();

Load AV module

Inteq_start_av_service (eq_av_callback_t *CB);

Docking video data

Inteq_set_video_data (unsigned char *pcencdata,int nencdatalen,int nframetype,intntimestamps,int nGopIndex,int Nframeindex,int ntotalindex,int NAVGQP);

Docking audio data
int Eq_set_audio_data (Eq_audio_encode_param *param, unsigned char *pcencdata, int nencdatalen, int ntimestamps);

Lack of binding, alarm upload, still in doing ....

phenomenon: The app plays a sound with a meal of a phenomenon that is incoherent.

Troubleshooting process:

1) The PCM data that is not decoded by the packet is also normal, at first thought Faad2 decoding performance is too slow

2) separate test Faad2 decoding interface found a second decoding 30 packets of data, this speed is completely enough to exclude this possibility

3) Suspect mobile phone performance is low, change the phone, turn off the video stream is not, eliminate this possibility

4) Catch log discovery app get network audio queue always overflow, indicating app consumption audio data slow and supply

5) found that the app consumes 5 packets of audio data in a single second, and the network feeds 7-8 packets of data per second for reasons found.

Reason: QQ things to the 8KHZ, mono-channel AAC data, our app needs to play 8KHZ, mono PCM data, I see no problem, the AAC decoding into PCM to throw the app Android playback on it. But QQ every sampling for the 128ms,app end of every 200ms consumption, meaning that QQ things a second to 8 packets of data, and the app can only consume 5 packets per second.

Solution 1:

Manually debug app elapsed time through Sem_init,sem_timewait,time_add

Solution 2:

8khz,16bit, mono, i.e. consumption per second: 8000*2*1=16000 bytes. 200ms consumes 3,200 bytes, which consumes 5 packets per second, consuming 3,200 bytes at a time. This can be done without manually debugging the app's elapsed time, as long as the 3,200 bytes per consumption.

Let's count the QQ IoT, 8khz,16bit, Mono, that is, acquisition per second: 8000*2*1=16000 bytes. But it samples 128ms at a time, then each sample data is: 16000* (128/1000) = 2048 bytes. So you can make a buf to save up 3,200 bytes in the app's Android interface playback.