Just an idea. When implemented I will use LiveTV.
Pascal
That sounds similar to what I was suggesting. I don't see why
there needs to be an element of time involved though... just keep on
displaying realtime data until there's a reason not to. Hit pause and
there's a bit of lag while the display transitions from raw capture to
decoded ringbuffer. From then-on, it's ringbuffer until you change
channel.
Lot of extra work + code complexity for extremely minimal gain.
I agree.
But hang on a second, this message is in reply to my message which has
already said that I think you should stop winging about the slow speed
of the buffering because it's fixable, and instead start trying to help
profile it and speed it up. The immediate answer is yet another
suggestion on how to implement live tv?
Look, myth is as simple as this, there is a playback app which plays
back from a file on disk. There is a recording app which records
sheduled programs. So to change channels you just set an immediate
schedule to record the next channel and cancel the last one (well
something like that).
Contrary to your expectation the time needed to implement the above is
millisecs. The delay seems to be in shutting down the old playback
(because it seems to pause and wait for a lot of threads in an
unneccesary way), and then starting up the new playback and recorder
seems to again be waiting far longer for events than neccessary.
I *have* had channel change times on a pre 0.18 myth on DVB of the order
<200ms. It *is* possible. However, I have barely enough time to write
this note and ask you to do something constructive.
The contructive thing to do is to put in a few timing statements into I
think it's NuppleVideoPlayer.cpp and start tracking down the exact
delays (Isaac, please remind me where the main code is). It's actually
fairly tricky because there are multiple threads and they synchronise on
signals, hence you can't just look at the code flow to see all the delays.
For example here's a quick win: I think the audiooutputbase.cpp code
actually waits for the audio output to pause the device before it says
that it's paused. I can't see any reason why this is necessary and it
seems to just cause a short gap in the audio for me (unneccessary). You
can shave a few ms off by removing this.
...OK now it's your turn, go find all the other slowdowns.
This is a really constructive thing that people can help with now, so
please don't sit on your "I don't know how to code" haunches and get on
and start profiling the slowdowns.
Good luck
Ed W
_______________________________________________
mythtv-dev mailing list
[email protected]
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
