- September 1, 2008
- 21,577
- 8,224
- Home Country
-
New Zealand
Hello again
Warning: some of the info below is quite technical!
Channel changing with a capture device is always going to be interesting. It happens like this:
MP and TV Server can (and usually do) complete a whole channel change sequence before the external tuner has finished changing channel.
Everything that is done during the channel change, especially selection of codecs, tends to be done as if you were still streaming channel A.
Thus the whole chain from HD-PVR through to your screen will see and have to cope with any glitches that are generated as a natural consequence of the external tuner changing from channel A to B.
By glitches, I mean:
PMT is a "clump" of info about the video, audio and subtitle streams that are present. This info is produced by the HD-PVR and parsed by TsWriter and TsReader. TsWriter (and TV Server in general) don't really care about the content of the PMT except that it determines what streams are included in the timeshift file. For the purposes of an HD-PVR that never changes, so TV Server tends to be pretty immune the the glitches. A key point to keep in mind is that TV Server doesn't remove the glitches either - it can't, because it has no idea when the external tuner actually finishes tuning. Everything just flows right on through to MP (or XBMC or whatever other front end is in use).
The most fragile parts of the chain are the codecs and the RTSP connection (and I suppose TsReader to a lesser degree). When a codec tries to decode garbage it will often result in visible pixelation/freezing or audible pops. My understanding (and @Owlsroost will surely correct me!) is that failure of the audio codec can cause the video to stop as well.
Both are telling me maybe in this particular case the absence of data (ie. the codecs and/or TsReader running out data to decode) is the issue.
Of further interest is that this only happens with S/PDIF. I guess the difference is that from the HD-PVR's perspective, S/PDIF audio data is either present or not. In other words, there is a marked glitch. With line audio, the absence of signal is just silence...
I think:
@Owlsroost
Whaddaya think?
Is there anything that we can do on the TV Server side or in TsWriter to improve the situation? I'm thinking things like suppressing PMT changes by waiting for the second (or even third) PMT before allowing the channel change to complete.
Note: with a Colossus or change involving switching of inputs, often there will be 3 PMTs seen:
1. Old channel PMT.
2. Default PMT (indicating input not detected).
3. New channel PMT.
mm
Warning: some of the info below is quite technical!
Channel changing with a capture device is always going to be interesting. It happens like this:
- Watching channel A, select channel B. MediaPortal tells TV Server to change channel.
- TV Server tells blaster to send command to switch to channel B. The blaster starts doing its thing - this carries on in the background of the following steps.
- TV Server goes through channel change for an analog tuner (ie. make sure correct inputs are selected).
- TV Server/TsWriter start waiting for PMT to determine what audio, video and subtitle streams will be present.
- PMT received, wait for audio and video.
- Audio and video seen, TV Server tells MediaPortal it has finished changing channel.
- MediaPortal sets up TsReader splitter waits to receive PMT.
- TsReader receives PMT, reads and decodes and tells MediaPortal what video, audio and subtitle streams are present.
- MediaPortal connects appropriate/configured codecs and tells TsReader and the codecs to start doing their jobs, the result being that you see video and hear audio.
MP and TV Server can (and usually do) complete a whole channel change sequence before the external tuner has finished changing channel.
Everything that is done during the channel change, especially selection of codecs, tends to be done as if you were still streaming channel A.
Thus the whole chain from HD-PVR through to your screen will see and have to cope with any glitches that are generated as a natural consequence of the external tuner changing from channel A to B.
By glitches, I mean:
- The change from channel A to nothing.
- The nothingness itself... which tends to be garbage.
- The change from nothing to channel B.
PMT is a "clump" of info about the video, audio and subtitle streams that are present. This info is produced by the HD-PVR and parsed by TsWriter and TsReader. TsWriter (and TV Server in general) don't really care about the content of the PMT except that it determines what streams are included in the timeshift file. For the purposes of an HD-PVR that never changes, so TV Server tends to be pretty immune the the glitches. A key point to keep in mind is that TV Server doesn't remove the glitches either - it can't, because it has no idea when the external tuner actually finishes tuning. Everything just flows right on through to MP (or XBMC or whatever other front end is in use).
The most fragile parts of the chain are the codecs and the RTSP connection (and I suppose TsReader to a lesser degree). When a codec tries to decode garbage it will often result in visible pixelation/freezing or audible pops. My understanding (and @Owlsroost will surely correct me!) is that failure of the audio codec can cause the video to stop as well.
I think the most interesting parts of all of this are #3 and #6.
Both are telling me maybe in this particular case the absence of data (ie. the codecs and/or TsReader running out data to decode) is the issue.
Of further interest is that this only happens with S/PDIF. I guess the difference is that from the HD-PVR's perspective, S/PDIF audio data is either present or not. In other words, there is a marked glitch. With line audio, the absence of signal is just silence...
I think:
- it would be worthwhile to try to reproduce the problem on a single-seat system (ie. eliminate RTSP)
- it would be worthwhile to try different audio codecs
@Owlsroost
Whaddaya think?
Is there anything that we can do on the TV Server side or in TsWriter to improve the situation? I'm thinking things like suppressing PMT changes by waiting for the second (or even third) PMT before allowing the channel change to complete.
Note: with a Colossus or change involving switching of inputs, often there will be 3 PMTs seen:
1. Old channel PMT.
2. Default PMT (indicating input not detected).
3. New channel PMT.
mm
