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

Sat Nov 15 06:22:27 EST 2003

This might certainly be a possibility. It will probably take a lot of 
work as well.

Another thing I had been thinking of is to allow the GUI/OSD to continue 
working so you could keep switching channels even though the system is 
in the progress of getting all the data through the pipeline. This is a 
far cry from a perfect solution but when "channel surfing" it could give 
you the _feeling_ of having ~1 second channel change times. And if 
you're like me and immediately skip 80% of the channels after having 
seen them for a fraction of a second this migth actually work. It does 
mean of course that when you encounter something worth watching that 
you're probably several channels ahead alreay so you'll have to go back. 
Like I said a far cry from being perfect but it might actually be 
possible to implement without too much hassle. (PS: I did test this once 
using an external channel change script, so in theory it could work :-)

Cheers,
 -Tako

Jelle wrote:

>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
>>    
>>
>
>  
>
>------------------------------------------------------------------------
>
>_______________________________________________
>mythtv-users mailing list
>mythtv-users at mythtv.org
>http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mythtv.org/pipermail/mythtv-users/attachments/20031115/1cfe72ec/attachment.html