[Live-devel] Birates in Video-Streams

[Eric Peters]

Ross Finlayson wrote:

>
>> we have the following problem. When we are streaming multicast mpeg1 
>> or mpeg2 files with bitrates about 2500 kbps there are on the 
>> receiver side many artefacts in the video. We are using eg. 
>> testMPEG1orMPEG2AudioVideoStreamer. Even we are streaming videos with 
>> lower bitrate (800 kbps mpeg1 or mpeg2) and resolution (352x288) 
>> there are many artefacts on the receiver side. When we set the value 
>> /proc/sys/net/core/rmem_maxsize to 2MB the artefacts problem for 
>> lower bitrates is solved.
>
>
> Well, it looks like you've solved your problem: The kernel's receive 
> buffer for the "RTPSource" 'groupsock' needs to be sufficiently large 
> to ensure that incoming packet data doesn't overflow it. (You could 
> probably get the same effect - within your program - by calling 
> "increaseReceiveBufferTo()".)
>
>
> Ross Finlayson

I discussed this problem with some collegues. You can compare the memory 
defined by rmem_size as a queue. If this queue is full the data inside 
is overwritten by the operating system. So there are artefacts in the 
video. If this size is big enough the queue wouldn't overflow and no 
artefacts appear.
But which value is big enough? In our tests we determine a value of 2 MB 
for a video of 2500kpbs. But what about videos of higher bitrates?

And another problem is setting this rmem_maxsize value. This value could 
only be changed by root. So you have to call your system administrator 
cause you would see a streaming video. I don't know about your system 
administrator but here they aren't really happy about this questions. :-)

I think it would be better if you have your own queue on the programmers 
side. If you are using queues inside your source code you can solve this 
problem very easy. The queue size can be changed very easy and it would 
be independent of the settings of your operating system.

Greetings
Eric