Hello,
I'm experiencing ring buffer overflows with streamdev-server and the following remux script:
tmpdir=${TMPDIR-/tmp}/externremux-${RANDOM:-$$} FIFO=$tmpdir/out.mkv OUTLOG=$tmpdir/out.log mkdir -p $tmpdir || exit 1 mkfifo $FIFO (cat $FIFO; rm -rf $tmpdir) & ffmpeg -threads 2 -i - -deinterlace -vcodec libx264 -vpre veryfast -b 900k -bt 50k -maxrate 900k -s vga -acodec libfaac -async 1 -ac 2 -ar 44100 -aq 128 -sn -y $FIFO 2>/tmp/ffmpeg.log
My outgoing line is a VDSL2 line with a 2048kbps upload.
2011-07-09T21:05:46+02:00 localhost vdr: [553] buffer usage: 70% (tid=552) 2011-07-09T21:05:47+02:00 localhost vdr: [553] buffer usage: 80% (tid=552) 2011-07-09T21:05:47+02:00 localhost vdr: [553] buffer usage: 30% (tid=552) 2011-07-09T21:05:49+02:00 localhost vdr: [25625] ERROR: 76 ring buffer overflows (14288 bytes dropped)
When this happens, the picture freezes and it never recovers. Sometimes, there's also this suspicious extra error message (the first line):
2011-07-09T21:16:28+02:00 localhost vdr: [593] ERROR: read failed: Resource temporarily unavailable 2011-07-09T21:16:29+02:00 localhost vdr: [25625] ERROR: 58 ring buffer overflows (10904 bytes dropped) 2011-07-09T21:16:33+02:00 localhost vdr: [596] buffer usage: 70% (tid=595) 2011-07-09T21:16:33+02:00 localhost vdr: [596] buffer usage: 80% (tid=595) 2011-07-09T21:16:34+02:00 localhost vdr: [596] buffer usage: 90% (tid=595)
Any advice on how to fix the problem?
Thanks!
On 9.7.2011 22:51, Luboš Doležel wrote:
Hello,
I'm experiencing ring buffer overflows with streamdev-server and the following remux script:
tmpdir=${TMPDIR-/tmp}/externremux-${RANDOM:-$$} FIFO=$tmpdir/out.mkv OUTLOG=$tmpdir/out.log mkdir -p $tmpdir || exit 1 mkfifo $FIFO (cat $FIFO; rm -rf $tmpdir) & ffmpeg -threads 2 -i - -deinterlace -vcodec libx264 -vpre veryfast -b 900k -bt 50k -maxrate 900k -s vga -acodec libfaac -async 1 -ac 2 -ar 44100 -aq 128 -sn -y $FIFO 2>/tmp/ffmpeg.log
My outgoing line is a VDSL2 line with a 2048kbps upload.
2011-07-09T21:05:46+02:00 localhost vdr: [553] buffer usage: 70% (tid=552) 2011-07-09T21:05:47+02:00 localhost vdr: [553] buffer usage: 80% (tid=552) 2011-07-09T21:05:47+02:00 localhost vdr: [553] buffer usage: 30% (tid=552) 2011-07-09T21:05:49+02:00 localhost vdr: [25625] ERROR: 76 ring buffer overflows (14288 bytes dropped)
When this happens, the picture freezes and it never recovers. Sometimes, there's also this suspicious extra error message (the first line):
2011-07-09T21:16:28+02:00 localhost vdr: [593] ERROR: read failed: Resource temporarily unavailable 2011-07-09T21:16:29+02:00 localhost vdr: [25625] ERROR: 58 ring buffer overflows (10904 bytes dropped) 2011-07-09T21:16:33+02:00 localhost vdr: [596] buffer usage: 70% (tid=595) 2011-07-09T21:16:33+02:00 localhost vdr: [596] buffer usage: 80% (tid=595) 2011-07-09T21:16:34+02:00 localhost vdr: [596] buffer usage: 90% (tid=595)
Any advice on how to fix the problem?
Thanks!
Apart from simplifying the script to a single line I've found a solution: I've tripled the size of the ring buffer in vdr-streamdev-server and the problem is gone. No problems after hours of playback...
On Wed, Jul 13, 2011 at 12:05 PM, Luboš Doležel lubos@dolezel.info wrote:
Apart from simplifying the script to a single line I've found a solution: I've tripled the size of the ring buffer in vdr-streamdev-server and the problem is gone. No problems after hours of playback...
Is there any reason why the ring buffer can't or shouldn't be dynamic aside of just not bothering to implement it?
Am 14.07.2011 02:28, schrieb VDR User:
On Wed, Jul 13, 2011 at 12:05 PM, Luboš Doležel lubos@dolezel.info wrote:
Apart from simplifying the script to a single line I've found a solution: I've tripled the size of the ring buffer in vdr-streamdev-server and the problem is gone. No problems after hours of playback...
Is there any reason why the ring buffer can't or shouldn't be dynamic aside of just not bothering to implement it?
Unlimited buffers tend to get unlimited big, crashing your app with out-of-memory. Huge buffers also add lag to the signal. With no bandwidth issues, buffers are usually almost empty, with bandwidth issues, buffers are usually almost full.
In the end you set them as big as necessary, and as small as possible. And giving them a fixed size (possibly configurable) is less complicated, especially in a multi-threaded environment.
Cheers,
Udo
On 14.7.2011 19:23, Udo Richter wrote:
Unlimited buffers tend to get unlimited big, crashing your app with out-of-memory. Huge buffers also add lag to the signal. With no bandwidth issues, buffers are usually almost empty, with bandwidth issues, buffers are usually almost full.
In the end you set them as big as necessary, and as small as possible. And giving them a fixed size (possibly configurable) is less complicated, especially in a multi-threaded environment.
I such case I would suggest to give the buffer an initial and maximum size, but I'm not sure if that's worth implementing. But the initial size should definitely be configurable.
My problem is really related to bandwidth problems. More specifically, ffmpeg/x264 seems to sometimes exceed the constant bitrate I specified using -br -minrate -maxrate.
With ffmpeg, having a 128kbps audio + 1050kbps CBR video sometimes gives bitrate over 2048kbps!
Instability on the client side (e.g. on a WiFi) can also cause the ring buffer to overflow...
On Thu, Jul 14, 2011 at 10:23 AM, Udo Richter udo_richter@gmx.de wrote:
Is there any reason why the ring buffer can't or shouldn't be dynamic aside of just not bothering to implement it?
Unlimited buffers tend to get unlimited big, crashing your app with out-of-memory. Huge buffers also add lag to the signal. With no bandwidth issues, buffers are usually almost empty, with bandwidth issues, buffers are usually almost full.
I'm not sure such a blanket statement can be made these days. There are plenty of apps which grow & shrink buffers on the fly which seem to be perfectly stable. I suppose sloppy coding and mishandling of memory would cause the symptoms you're describing though.
On a side-note, a lot of people experience a frozen vdr/xine with 100% buffer. It's never been fixed to my knowledge and it's been a while since I've seen it brought up but iirc it has nothing to do with bandwidth. Rnissl, I think, knows what actually causes that particular problem.
In the end you set them as big as necessary, and as small as possible. And giving them a fixed size (possibly configurable) is less complicated, especially in a multi-threaded environment.
Translation: path of least resistance. ;)
Cheers
On 14.7.2011 17:35, Frank Schmirler wrote:
Hi Luboš,
On Wed, 13 Jul 2011 21:05:52 +0200, Luboš Doležel wrote
solution: I've tripled the size of the ring buffer in vdr-streamdev-server and the problem is gone. No problems after hours of playback...
which of the buffers did you change to which value?
Regards, Frank
Not knowing which buffer was the right one, I increased both STREAMERBUFSIZE and WRITERBUFSIZE (server/streamer.h) to three times the original value.
-
Frank Schmirler -
Luboš Doležel -
Udo Richter -
VDR User