[mythtv-users] I'm in....

[Chris Delis]

> 
> >-----Original Message-----
> >From: Chris Delis [mailto:chris at delis.net] 
> >Sent: Friday, November 14, 2003 9:34 AM
> >To: Discussion about mythtv
> >Subject: RE: [mythtv-users] I'm in....
> >
> >
> >
> >You can determine the size of the ringbuffer during setup.
> >
> 
> Nope, this has nothing to do with the live buffer we're talking about.  Yes,


I understand.

I was (incorrectly, apparently) contributing some of that delay to ring buffer
managment.  Hence, I mentioned it.  I certainly realize that a ring buffer
size of, say 10GB, isn't used for the live buffer! :-)

> the size of the ringbuffer can be set, so you get to decide how long you can
> pause, basically.  (This buffer will hold up to 2GB, 3GB, etc etc)  But a
> mythtv "live" stream has to be at least 3-4 seconds (currently) behind real
> live tv.  This is because we're recording data then turning around and
> playing it at the same time.  What we're concerned about is finding a way to
> trim this 3-4 second delay.  (But once you pause, you're storing quite a lot
> of live data as it comes in, and there must be a limit to this size...
> again, that's what the Ringbuffer setting is for)
> 
> >Also, I _think_ part of the delay is caused by deleting the 
> >old ringbuffer and creating a new one. 
> 
> Nope, that possibility has already been taken care of by Isaac in CVS
> (discussed on the mythtv-devel list I think).  Even ignoring channel change:

Great.  I wasn't aware of it.  I will check it out.



> if I fast-forward as far as the player will let me, then compare real live
> tv on a tv, with the myth output, it's a full 4 seconds behind for me.
> Which suggests the delay has little to do with channel change actions, and
> more to do with how much the player process needs to output reliably (with
> no dropped frames or audio blips, etc.)
> 
> - Willy
> >
> >
> >> play as soon as it sees data, and 3-4 seconds is the best we 
> >can do?  
> >> Or is it stored in some variable in the code, and 3-4 
> >seconds worth of 
> >> data seemed reasonable for most systems?  (And I'm actually one that 
> >> promised to look through the code and figure this out :-D  I have to 
> >> admit I haven't gotten beyond a few basics timing tests in my spare 
> >> time, so not trying to be a
> >> hypocrite)  Does anyone with a Tivo or ReplayTV see a 3-4 
> >second delay?  For
> >> a hardware encoder, and therefore just a simple player off 
> >of /dev/video0,
> >> with modern hardware, I'm surprised that 3-4 seconds is the 
> >smaller buffer
> >> that will play reliably.  For software encoding I realize 
> >that's a different
> >> story...  but if the buffer is designed around a catch-all 
> >solution, maybe
> >> it can be shortened for hardware encoder systems?  
> >> 
> >> - Willy
> >> 
> >> >
> >> >> I am also seeing video and
> >> >> audio get a little jumpy when the OSD comes up.  Are you
> >> >> seeing this as well? What hardware are you running?
> >> >
> >> >This is due to the slow hardware. ME6000 on this side. Got
> >> >lots better with the pvr350 though.
> >> >
> >> >Torsten
> >> >--
> >> >Config files for pvr350 tv-out and framebuffer: 
> >> >http://www-isl.mach.uni-karlsruhe.de/>~hi93/ivtv-pvr-350-conf.tgz
> >> >
> >> >
> >> 
> >> 
> >
> >
> 
>