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

[Tako Schotanus]

Easy Geoff, I think that Honer was only pointing out that it seems at 
least technically possible with similar hardware and similar 
functionality to get a "decent" channel change time. I'm not reading 
anywhere that he says that MythTV is crap and that the developers don't 
spend enough time on it. What he does address is Bruce's seeming 
certainty that there is nothing we can do about the situation.

I think it's good that people feel strongly about certain things and 
that they can express those feelings as long as they do it in a positive 
way. And as a small-time dabbler in MythTV code (yes, I've taken shot at 
the channel change code, without much luck ;-) I must say I feel 
strengthend by the fact that is _does_ seem possible to solve this 
problem. :-)

-Tako

Geoff Sadler wrote:

> Not that I post often.  But I think the explanation speaks for 
> itself.  Also, remember the libs and drivers for the pvr are in their 
> infancy.  If Linux devs could always get their hands on full info 
> regaurding hardware the drivers would be much better and or more 
> frequently updated.
> So with not much else to say, if you wish to use sage you are more 
> than welcome to.  But remember all of the myth-tv devs do this for 
> free without charge to you the enduser.  They do this as a love for 
> technology and for themselves.  So please cut the shoulda, coulda, 
> woulda out as they are doing a darn good job.
> Sorry to be blunt, but if you feel you can do as good of a job as the 
> devs the source code is there so feel free to pitch in where you can 
> help.
>
>
>
>
> Michael Janer wrote:
>
>> Why is it that SageTV can do this channel change with a PVR 250 or 
>> 350 at about the same speed as a Tivo?  I would imagine the engine in 
>> mythtv can be sped up in some way.  Sagetv has a client server setup 
>> also and seems to be able to make the channel changes pretty decent 
>> ~1 second.  I imagine if SageTV can do it with java and windows, 
>> Mythtv should definately be able to do it.
>>
>> Honer
>>
>> ________________________________
>>
>> From: mythtv-users-bounces at mythtv.org on behalf of Bruce Markey
>> Sent: Fri 11/14/2003 5:42 PM
>> To: Discussion about mythtv
>> Subject: Re: [mythtv-users] I'm in....
>>
>>
>>
>> Boyd II, Willy wrote:
>>  
>>
>>> ...
>>> One thing I'm still trying to figure out is how this 3,4-second 
>>> buffer is
>>> determined.  Is it variable, and depending mainly on speed of hardware?
>>>   
>>
>>
>> There isn't one thing that is a 3,4-second buffer. there are a
>> series of steps from when the first frame is available to the
>> encoder on the backend until the frames can be played by the
>> player on the frontend.
>>
>> Think of it like turning the spigot on a hose and waiting for
>> water to come out the nozzle. What's hosed here (yes, old timers,
>> I *will* use this pun every time this comes up ;-) is that the
>> encoder starts and the player sends off its first RequestBlock.
>> First, the backend starts grabbing frames from the card. Once
>> it has a few it can start to compress them and write them to the
>> file. Next, another thread waits until it can read enough data
>> from the file to send it over a socket to the frontend. The read
>> ahead thread on the frontend starts to read data from the socket.
>>
>> Once the read ahead thread is satisfied, the data can be decoded
>> and stuffed into a buffer of decoded frames that the player can
>> play. The player can't start until it has a minimum number of
>> frames. If the player runs out of frames to play, it has to stop
>> and wait for more frames to be decoded. When this happens you see
>> the 'prebuffering pause' message.
>>
>> So, for the player to run smoothly, there needs to be about 50 to
>> 70 frames worth of data in the pipeline. Depending on the bitrate,
>> resolution, compression type and other factors, this will take
>> from 1.7 sec up to maybe 3 sec. There are also other things that
>> need to happen from the time you press a key untime the channel
>> change starts that can add a little to the delay. This has all
>> been sanded and polished but it's just plain going to take more
>> than 2 sec.
>>
>> Now, it's nice to hear people say that TiVo channel changes seem
>> to be instant but this just isn't true. TiVo is a monolithic
>> device where they can handle things a little more directly but
>> there is still about 1 second of delay. MythTV hasn't been a
>> monolithic single process since 0.7. It now splits the frontend
>> and backend to allow multiple systems to work together so there
>> needs to be interprocess communications. It also supports remote
>> frontends so the design has to account for network buffering to
>> allow these will play video smoothly. These things make the "hose"
>> a little longer but the functionality is worth it. Especially
>> considering that you shouldn't ever have to "channel surf" once
>> you understand what you can do with a DVR system.
>>
>> --  bjm
>>
>>
>>
>>
>>
>>  
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> mythtv-users mailing list
>> mythtv-users at mythtv.org
>> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
>>  
>>
>
>
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users