G711/Buffer Size of 743 Bytes?

[Moriquendi]

Hello forum,

I am currently working on a streaming project to an SIP telephony (which uses a non-vlc media engine) and I am trying to send live streams using VLC on the application side. Anyway, I've managed to send audio and video successfully except every now and then (it can happen in 30 seconds or after 4 minutes, seems like totally random to me) the audio (g711/alaw) starts to distort for like 2-10 seconds, then the sound is recovered for a while (the duration is again random) and then the process repeats itself.

I have no expertise in this subject but it seemed to me that it might be a buffer problem on the SIP telephony side. However, there is really nothing i can do about it, so I was thinking if it is possible to correct this by some tweaking on the vlc code.

I've tried this with couple of different softphones(bria, limphone, mizuphone etc. ) and all of the successfull calls(for alaw) had 214 bytes of data chunks with 160 ms time difference between 2 consequent timestamps. So it is like 160 bytes of (54 bytes for rtp headers) every 160 ms. Now, when I stream with vlc, it takes 743 bytes of audio data(371 bytes in some cases) and depending on the ptime value (default is 20, i know but i had to reduce it to 10 in order to be compitable with my telephone settings), it splits the audio data into smaller chunks. So if ptime is 20 ms, then the audio data is splitted as 4 x 214(160+54) + 1 x 157 (103 +54). I've tried to track how vlc determines this 743 value in vlc code (working on version 1.1.9 currently), tried couple of things such as messing with the block_New's "i_size" value and such but all ended up in the same way.

I have two questions at this point:

1. Is it possible to set/change this value somehow?
2. If so, can you give any hints?

Thanks.

[Rémi Denis-Courmont]

This value is just the remainder of the division of the packet size coming from the input by the packetization time. There is no way to change that other than improve the code for RTP/G.711 packetization.

That being said, it is more like a limitation in your SIP phone than a VLC bug.

[Moriquendi]

On a totally different side note, I've left the streaming open just to test it, it was fine after 1 hour and and then i left the place to get something and when i got back, the video and audio both were gone. The call duration at that time was 1hour 15 minutes. I made a little bit of calculations and for win32 systems; say if 4,294,967,296 counts (2^32) are possible, this might mean vlc can only support at about 1 hour 11 minutes 35ish seconds of streaming considering it counts something, but what exactly it counts and increments per unit time(I believe its 10^-6 s)? and is it not possible to some sort of reset this value when it reaches to peak and repeat the process without the need of moving to win64 system to be able to watch longer streams than 1:11:35?

I am asking this coz the videophones im working on are capable of videoconferencing over 20 days without interruption(this is prolly much longer, but so far this is the longest time duration we have yet to test it) and they have linux 32 systems, so maybe its something you are aware of but cant fix it because of windows?

[Rémi Denis-Courmont]

VLC uses 64-bits microseconds timestamps. OK, leave out the negative values so 63-bits only. That should cover almost 300 millenia.

There may of course be a bug somewhere.

[Moriquendi]

VLC uses 64-bits microseconds timestamps. OK, leave out the negative values so 63-bits only. That should cover almost 300 millenia.

There may of course be a bug somewhere.

Ok but the .dlls im using are compiled for win32 by following http://wiki.videolan.org/Win32CompileMSYSNew since i couldnt find any guide for win64. In any case, it is not a big concern right now. About ur previous comment, you are most likely right about possible limitations on the SIP telephony side. But then I checked with another SIP telephony(grandstream that is) and video was fine but audio was problematic again, adjusting ptime in the vlc source code improved the quality but there are still some distortions i can not remove. So, I am starting to think the possibility that maybe vlc is sending alaw packets not compitable with the RFC standards in some cases maybe. Ofc thats just a wild guess and prolly not true but can you verify that VLC's alaw packetization is 100% upto standards or do you know the coder of the alaw rtp packetization so that he/she can verify?

Thanks again.

[Rémi Denis-Courmont]

I don't have time to test that sorry.

[Moriquendi]

Hi forum,

I've solved this particular problem a while ago, in case you wanna mess with the rtp g711 packet size, heres how you can start with:

In ..\vlc\modules\codec\avcodec\audio.c, check for SplitBuffer function. The line;

Code: Select all

p_sys->p_samples += i_samples * p_sys->p_context->channels * ( p_dec->fmt_out.audio.i_bitspersample / 8 );

determines the packet sizes. Here i_samples is initialized as

Code: Select all

int i_samples = __MIN( p_sys->i_samples, 4096 );

So for an input stream with 44100 samplerate, the packet size = 4096*1*((64000/44100)/8)=743 where the value 64000 value represents the bits per seconds for alaw which is independent of the input stream. Lets cut to the chase. All I needed to do was changing 4096 value to 882 as;

Code: Select all

int i_samples = __MIN( p_sys->i_samples, 882 );

so that encodec alaw packet sizes resulted in 160 bytes max. I am not sure this change can cause any side effects, but so far everything works just fine.

Cheers