That does make more sense, if the read and write operations are buffered it does force for a long delay. That's what I was missing. Maybe it would help keeping the disk io buffering small, the OS already has caching that would take care of disk io issues.
As for the nuv encoding/decoding I don't know enough on how it works so that's probably the reason why I didn't expect delays. If it operates on each frame then there should be no delay, if it operates on a group of frames then it definitely needs a buffer. The pause, fast forward or rewind issues are what got me confused. They should not play a role in the delay, as the same concerns occur when you are at the beginning or end of the buffer. The pause and rewind operations actually would help to build the buffer, so they are a benefit. The forward operation would just keep the stream at the end of the buffer (just like you get right now if you try to fast forward beyond what the buffer holds) Thanks, Alberto On Sat, 2005-10-15 at 07:16 -0500, Bob Wiegand wrote: > Alberto Alonso wrote: > > OK, I read the docs that say that the buffering of 4 seconds > > is needed so that fast forward and rewind work. > > > > I am hoping that someone will help me understand why. If the > > buffer doesn't have any back data I can understand the operations > > to just leave the viewing cursor at the present position. However > > if during the viewing they user decided to pause this would start > > filling up the cache. This would then have the effect of being > > able to forward/rewind as needed. > > > > Any explanations? > > > > Thanks, > > > > Alberto > > When you watch TV what MythTV is actually doing is: > > - Encode TV signal > - Save encoded data to disk > - Read encoded data fom disk > - Decode data > - Display decoded data on TV > > All this processing takes time - that's why there is a few second > delay when you change channels. > > If the live TV signal was displayed directly without delay then you > would have a problem when you tried to pause, fast forward or rewind. > There would be a delay waiting for the decoder and the time would skip > backwards a few seconds. > > Putting the delay at startup avoids a discontinuity during playback > and it was also probably easier to implement. > > -- > Regards, > Bob > _______________________________________________ > mythtv-users mailing list > [email protected] > http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
_______________________________________________ mythtv-users mailing list [email protected] http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
