Re: [vdr] Ring buffer overflows with streamdev and remux script
Hi Lubo, On Wed, 13 Jul 2011 21:05:52 +0200, Lubo Doleel 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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Ring buffer overflows with streamdev and remux script
Am 14.07.2011 02:28, schrieb VDR User: On Wed, Jul 13, 2011 at 12:05 PM, Luboš Doležel lu...@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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Ring buffer overflows with streamdev and remux script
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... -- Luboš Doležel ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Ring buffer overflows with streamdev and remux script
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. -- Luboš Doležel ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Ring buffer overflows with streamdev and remux script
On Thu, Jul 14, 2011 at 10:23 AM, Udo Richter udo_rich...@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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
