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

Sat Nov 15 00:21:15 EST 2003

>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.

Thank you Tako for seeing what I meant.  I didn't mean to insult anybody, I was just pointing out the fact that this is not a hardware limitation.  I am providing facts and feedback so the developers are aware of the need and concerns for some of the users.  They do a great job and MythTv has evolved so much since I first tried it last year and I am greatful.

Honer

________________________________

From: mythtv-users-bounces at mythtv.org on behalf of Jelle
Sent: Fri 11/14/2003 10:17 P
To: Discussion about mythtv
Subject: Re: [mythtv-users] I'm in....

On Fri, 2003-11-14 at 18:59, Tako Schotanus wrote:
> I'm afraid I don't entirely agree with your analysis of the situation.
>
> You mention a lot of steps as if the very fact that there are a lot of
> them immediately and irrevocably means that there is nothing that can
> be done about it. It maybe explains why there is a 3-4 second wait
> _now_ but it doesn't conclusively prove that it can't be improved
> upon.
>
> The card needs time to start grabbing its data, but when using a PVR
> there's no time lost in mythtv to do any encoding. Running mplayer
> directly on /dev/videoX and manually changing the channel shows that
> it is technically possible to do the recording/encoding phase in under
> a second.
>
> Then we need to start pumping the data over the network, true, but on
> a connection that has already been set up this delay can be neglected,
> so we'd only need some buffers to allow for the occasional peak in
> network traffic.
>
> 50 to 70 frames in the pipeline, any reason why there have to be so
> many?  Does everybody need the same amount of buffers? How about the
> VIA en PVR hardware decoders, couldn't they do with a lot less
> buffering? Couldn't network and decode buffers be combined somehow so
> we don't start connecting "hoses" with different capacities?
>
> The buffering is needed of course, but its not like a Discman's
> shock-proof/anti-skip buffer because there's no way to record live tv
> more quickly than it comes in, so when the buffer runs out it runs out
> and you'll have to wait until the buffer fills again. But maybe a
> setting would be usefull so people can tweak the buffer size to their
> own situation. Maybe some people will even allow the occasional
> pre-buffer pause just to take off half a second from the channel
> switching time.

What about this: Make a 'low delay uncompressed audio/video' mode, lets
call it the 'fastpath'. The fastpath is more restrictive than the normal
path but has a very low latency (mainly for channel surfing...). Accept
restrictions, such as requires a faster CPU/memory bandwidth, and only
when frontend and backend are on the same machine, and only if backend
and frontend drivers support the fastpath feature, and maybe no OSD,
etc. For low CPU power systems, maybe even disable all
compression/recording/pausing on this backend if the fastpath is in use.

Example: If the backend and frontend are on the same system and if they
both support this feature, then allow the backend and frontend to
allocate a chunk of shared memory for a doublebuffered uncompressed
frame. In the backend, the thread/process that has the uncompressed
frames first can then memcpy() the uncompressed frame to the shared
memory, before any compression is started on it. And the frontend can
then resize&copy it onto the screen (of course, with the right
semaphores for the shared memory, and something similar for the audio).
That should result in a latency that comes pretty close to using xawtv
directly.

That would allow people who really want low latency and fast channel
surfing to do that, given that they buy enough CPU and put a frame
grabber in the machine with the frontend where they want low latency.

Some people may then just buy an extra cheap low quality Bt878 in their
frontends just to get fastpath for fast channel surfing. For those
people, it may even be possible to then have a second backend flip
channels in parallel, so that all current live TV features are still
available, with a one-time 4 second time shift that is... Then if you
channel surf, and you stay on the same channel for more than 4 seconds,
you can choose to switch to the 'normal' backend if you accept repeating
the last 4 seconds one time... normal backend if you accept repeating
the last 4 seconds one time...

Jelle.

>
> And very nice that you try to educate people about how to use a DVR
> but besides the fact that it sounds very patronizing you also forget
> that there are lots of people using MythTV in countries that have no
> or only very limited XMLTV support. For those people it is impossible
> to just let the system record the entire selection of interesting
> movies of the coming 2 weeks or "any action movie that has Arnold in
> it".
>
> And finally Isaac has told people on the list more than once that it
> could very well be possible to improve the channel change time and
> that he'll be happy to receive any patches that improve it. As long as
> he (and other) are satisfied with the way it works now he (they)
> probably won't do anything about it. So any work will have to come
> from somebody annoyed enough with the delay that he'll sit down and do
> something about it. (don't expect it to be easy though because like
> Bruce explained, the current situation _is_ like a long hose with
> several connected parts with limited capacity).
>
> -Tako
>
> Bruce Markey wrote:
> > 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 11122 bytes
Desc: not available
Url : http://mythtv.org/pipermail/mythtv-users/attachments/20031115/3d1afbd0/attachment.bin