接收RTPstream – AudioStream,AudioGroup

我想听一个RTPaudiostream,但是这个语音在它里面没有什么差距 – 不能继续。 什么可能是解决scheme? 我在Receiver(android)端或者Streamer(ffmpeg)端丢失了什么?

我使用ffmpeg来传输RTPaudio

ffmpeg -f lavfi -i aevalsrc="sin(400*2*PI*t)" -ar 8000 -vcodec pcm_u8 -f rtp rtp://192.168.0.15:41954 (port changes.) 

这里是我的相关的android代码:

 AudioStream audioStream; AudioGroup audioGroup; @Override public void onStart() { super.onStart(); StrictMode.ThreadPolicy policy = new StrictMode.ThreadPolicy.Builder().permitNetwork().build(); StrictMode.setThreadPolicy(policy); AudioManager audio = (AudioManager)getSystemService(AUDIO_SERVICE); audio.setMode(AudioManager.MODE_IN_COMMUNICATION); audioGroup = new AudioGroup(); audioGroup.setMode(AudioGroup.MODE_ECHO_SUPPRESSION); InetAddress inetAddress; try { inetAddress = InetAddress.getByName("192.168.0.15"); audioStream = new AudioStream(inetAddress); audioStream.setCodec(AudioCodec.PCMU); audioStream.setMode(RtpStream.MODE_NORMAL); InetAddress inetAddressRemote = InetAddress.getByName("192.168.0.14"); audioStream.associate(inetAddressRemote, 6000); ((TextView)findViewById(R.id.tv_port)).setText("Port : " + String.valueOf(audioStream.getLocalPort())); audioStream.join(audioGroup); } catch ( UnknownHostException e ) { e.printStackTrace(); } catch ( SocketException e ) { e.printStackTrace(); } } 

Solutions Collecting From Web of "接收RTPstream – AudioStream,AudioGroup"

回答我自己的问题,问题是与Android rtp数据包pipe理。

Android说... assume packet interval is 50ms or less. 在AudioGroup源文件中 。

但是,RTP数据包以60ms的间隔发送。

这意味着50ms是不够的,这导致如下所述的问题。

 Incoming: XXXXXXYYYYYYXXXXXXYYY YYYXXXXXX Reading : XXXXXYYYYYXXXXXYYYYYX XXXXYYYYY ^ ^ ^ ^ ^ - - - - - - - - - - - - - - - - - - - - ^ ^ ^ ^ ^ ^ ^ | | |---- just these overlapping packets is valid ----| |---- and other packets discarding due to --------| |---- invalid RTP headers. -----------------------| X, Y < packets 

我每隔300毫秒只有一个数据包。 那结果是不安的声音。

我会发送一个错误报告,希望它可以帮助别人。

对于那些真正想听RTPstream的人来说,我build议他们手动读取数据包并将其解码为PCM 16bit(这是Android声卡支持的唯一audio格式)并将其写在AudioTrack上。

道歉,如果以下是愚蠢的:

ffmpeg命令行似乎正在生成testing声音,并通过RTP将其发送为pcm数据stream。

RTP本身并不能保证stream式数据的可靠传输,它只是提供足够的信息告诉接收方是否收到了所有的数据,以及如果某些数据在传输过程中丢失了什么数据。 另外它通常使用UDP。

因此,RTP的重点在于RTP的用户发送以这种方式编码的数据(即,纠错编码,数据冗余等),使得接收者可以重构足够的原始数据以满足应用需要。 所以对于audiostream,你需要一些适合的编码格式。

我还没有findpcm_u8意义的参考,但是它高度暗示它是一个简单的脉冲编码调制数据stream,具有8位数据。 这听起来不像它内置任何纠错编码或数据冗余。 丢失一个字节意味着丢失一个样本,在接收端没有任何东西可以填写。

所以我认为发生的事情是networking中的某些东西正在丢弃UDP数据包,RTP告诉AudioStream哪些数据丢失,结果是差距,因为在pcm_u8数据stream中没有纠错或数据冗余,以允许丢失的数据由AudioStream重build。

我已经看到像VMware这样的事情故意在虚拟networking上丢弃UDP数据包,作为确保良好性能的一种方式,理由是UDP无法保证传输,所以“无关紧要”。 这严重刺痛了一位正在使用RTP的同事,他希望保证交付,但是没有得到。 他有一个封闭的网段,在networking的每一端都有一个服务器,其中一个托pipe单个虚拟机。

所以它可能只是一个改变你使用的编解码器的情况。 我无法推荐一个。 首先,值得研究一下广播数字媒体stream的用途。 DVB-T使用MPEG传输stream(具有纠错编码等),AFAIK是MPEG-2的包装。