PCMU RTP streaming is buggy
When streaming PCMU (G.711) for an audio wav file (mono, 8000samples/sec), the stream content by looking with wireshark on the network is buggy. There are garbage data inserted in the stream between real audio samples. Capturing this stream and looking at the timestamp will make that some audio samples are missing also.
Example of streaming cmd line: vlc c:\tempo\amono8000sps.wav :sout=#transcode{acodec=ulaw,channels=1,rate=8000}:duplicate{dst=rtp{dst=192.168.1.100,port-audio=8000}} :sout-keep
I have checked with latest version 2.0.1 and the problem is still there. I have also verified all versions since v0.9.9 and from these tests i got this conclusion:
1- all version from v0.9.9 to v1.0.5 are working correctly (will generate 3 rtp packets per audio frames for 400 samples total, each 50 msec for an audio frame), with no audio garbage junk inserted in the middle). Minor issue with all these versions are that it seems that a small part of the beginning of the audio is not send? The smallest time between RTP packets is around 16msec. These version sent correctly a 64kb/sec audio in a v2.0.0 player statistics. When using v2.0.0 player to play an audio stream generated by version 0.9.9 for example it plays correctly (without samples audio lost).
2- all versions from 1.1.0 to 2.0.1 have a similar problem. They are inserting garbage junk between the real audio samples and are streaming completly differently than the older version above. The timestamp is not changing very often (like every 26 packets instead of 3) and a lot of junk can be seen on the received rtp signal (or when looking the packets with wireshark). By looking at the rtp time stamp with these versions, we can detect from the received stream that we are having lost samples. These version don't sent correctly a 64kb/sec audio in a v2.0.0 player statistics (128kb/sec instead!!!).
I took care of using a mono audio sample and at correct sampling rate of 8000 samples/sec to minimize the transcoding effort/problem for videolan for G.711 PCMU which needs 8ks/sec 8 bits mono audio.
Maybe the problem is related to a streaming related library change between v1.0.5 and v1.1.0...