Søndag 11 september 2005 04:15, skrev Tim McClarren: > I just started looking at this. > > I instrumented tv_play.cpp and some of RingBuffer.cpp with logging, > because I was curious why it was taking me just under 4s to change > channels.
A tiny tip for you all would be to implement non-blocking reads from the frontend side. This way you could get the decoder to start decoding frames faster, which will improve the prebuffering time. It probably also have the nice side effect of fixing the dreaded deadlocks on tuner failure ;) I'm wondering though, if the truncate of the ringbuffer actually does free the data of a file or not? If so, it could be more efficient to rename the current file, create a new and defer the removal to another thread. Something that would not affect DVB or ATSC would be any delay that the encoder requires, with a few frames this could quickly become noticable, please take this into account. The frontend does something that has been called prebuffering, and the last time I looked this is a 'lineup' of decoded frames that will be played back. What could be done to improve time here is to manage the not-yet-decoded 'frames' in time, so that prebuffering would work on the frame data, which would save a lot of time in decoding frames that would be dropped anyways. Btw, the time between the audio and video stream will increase if you have a cam attached to your dvb adapter, because of the delays in the decryption engine in the cam. This causes MythTV to wait longer before playback is started, since it wants a certain timeslice buffered in any stream. Kenneth _______________________________________________ mythtv-dev mailing list [email protected] http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
