Log in
Register
Menu
Log in
Register
Home
What's new
Latest activity
Authors
Forums
New posts
Search forums
What's new
New posts
Latest activity
Members
Current visitors
New posts
Search forums
Menu
Log in
Register
Install the app
Install
Forums
3D TV, High Definition Television, HDTV 4K and AV
HD, 4K TV and Receivers
Humax HD
Humax Foxsat PVR locking up on signal degradation?
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Reply to thread
Message
<blockquote data-quote="archive10" data-source="post: 761198"><p>Well, most of the image and audio processing stuff these days is done in hardware, ie. the DCT for MPEG decoding is on-chip straight to the image buffer. The actual transfer from hard-disk to memory and back is usually via DMA, with the CPU only involved in setting up the transfers and the decoding.</p><p></p><p>This of course all varies from chipset to chipset, and with price of chipset. Less special-purpose hardware means more work for the CPU to implement certain functions (and less time for user responsiveness). On the other hand, high-end boxes can even have multiple cores etc, just like PCs, allowing the application to run on one core, while the hardware is managed by the other.</p><p></p><p>So with the Humax box not exactly being cheap, I would care to speculate that it has quite a bit of hardware automation to do the recording and playback.</p><p></p><p></p><p></p><p>You do have a point - but whose programming? Box designer? Chipset manufacturer? Application programmer?</p><p></p><p>The lowest time delay incurred by changing channel is the basic cost of re-tuning. This includes setting the tuner to the new frequency, locking on to the transport stream, and demuxing the elementary streams that make up the audio and video, and feeding those to the decoders. This penalty is induced by the hardware/lowest firmware. Hard to do anything about this.</p><p></p><p>A little bit of cleverness can optimise the channel change, e.g. if changing channels within a transport stream (say, from BBC1 to BBC2), you can skip the tuning and locking step, and just change the elementary streams making up the new service. In theory, you can reduce the channel change time to the time until the next I-frame in the stream.</p><p></p><p>Similarly, if you have two available tuners, you can "cue" the other tuner to the next channel up in the channel list, so that it's already tuned when you decide to go one step further. This is a bit like double-clutch automatic gearboxes in e.g. VAG cars.</p><p></p><p>Combining the two can give quite good results. However, if the other tuner is busy, and you do change between services on different muxes, the delay will be more noticeable.</p><p></p><p>The actual control of channel change is often implemented in the box-specific middleware libraries that control the chipset and peripheral devices. These are often ports of the chip-set manufacturer's standard libraries provided with the license for the chip-set. The libraries provided are not meant to be super-optimised, but are more provided as reference. They are also written for generic designs, so that e.g. dual-tuner designs are not necessarily handled without some adaptation of the code. And that's what cost money.</p><p></p><p>The FoxSat, however, has a reasonable performance, leading me to suspect that they do employ some tricks in their firmware. For example, if recording two channels that happen to be on the same transport stream, it seems to use the same tuner for the two, as I can watch a third channel sometimes.</p><p></p><p>The real answer to fast channel changes is to have always have three tuners to watch live TV, so that you even in worst case can always go up and down at your leisure (tuner 1 on the channel you just left, tuner two on the current, and tuner three on the one up from here). Then you'd want to have at least one or two more tuners to record stuff while you watch other things.</p><p></p><p>The problem is, all extra goodies costs money, and STB design is a careful exercise to balance cost and benefit. Saving $15 on a tuner, or even $2 on less RAM means a lot when you sell millions of boxes.</p><p></p><p>Sorry for the rant. I get carried away some times... <img src="https://www.satellites.co.uk/styles/default/xenforo/smilies/smile.png" class="smilie" loading="lazy" alt=":)" title="Smile :)" data-shortname=":)" /></p></blockquote><p></p>
[QUOTE="archive10, post: 761198"] Well, most of the image and audio processing stuff these days is done in hardware, ie. the DCT for MPEG decoding is on-chip straight to the image buffer. The actual transfer from hard-disk to memory and back is usually via DMA, with the CPU only involved in setting up the transfers and the decoding. This of course all varies from chipset to chipset, and with price of chipset. Less special-purpose hardware means more work for the CPU to implement certain functions (and less time for user responsiveness). On the other hand, high-end boxes can even have multiple cores etc, just like PCs, allowing the application to run on one core, while the hardware is managed by the other. So with the Humax box not exactly being cheap, I would care to speculate that it has quite a bit of hardware automation to do the recording and playback. You do have a point - but whose programming? Box designer? Chipset manufacturer? Application programmer? The lowest time delay incurred by changing channel is the basic cost of re-tuning. This includes setting the tuner to the new frequency, locking on to the transport stream, and demuxing the elementary streams that make up the audio and video, and feeding those to the decoders. This penalty is induced by the hardware/lowest firmware. Hard to do anything about this. A little bit of cleverness can optimise the channel change, e.g. if changing channels within a transport stream (say, from BBC1 to BBC2), you can skip the tuning and locking step, and just change the elementary streams making up the new service. In theory, you can reduce the channel change time to the time until the next I-frame in the stream. Similarly, if you have two available tuners, you can "cue" the other tuner to the next channel up in the channel list, so that it's already tuned when you decide to go one step further. This is a bit like double-clutch automatic gearboxes in e.g. VAG cars. Combining the two can give quite good results. However, if the other tuner is busy, and you do change between services on different muxes, the delay will be more noticeable. The actual control of channel change is often implemented in the box-specific middleware libraries that control the chipset and peripheral devices. These are often ports of the chip-set manufacturer's standard libraries provided with the license for the chip-set. The libraries provided are not meant to be super-optimised, but are more provided as reference. They are also written for generic designs, so that e.g. dual-tuner designs are not necessarily handled without some adaptation of the code. And that's what cost money. The FoxSat, however, has a reasonable performance, leading me to suspect that they do employ some tricks in their firmware. For example, if recording two channels that happen to be on the same transport stream, it seems to use the same tuner for the two, as I can watch a third channel sometimes. The real answer to fast channel changes is to have always have three tuners to watch live TV, so that you even in worst case can always go up and down at your leisure (tuner 1 on the channel you just left, tuner two on the current, and tuner three on the one up from here). Then you'd want to have at least one or two more tuners to record stuff while you watch other things. The problem is, all extra goodies costs money, and STB design is a careful exercise to balance cost and benefit. Saving $15 on a tuner, or even $2 on less RAM means a lot when you sell millions of boxes. Sorry for the rant. I get carried away some times... :) [/QUOTE]
Insert quotes…
Verification
Post reply
Forums
3D TV, High Definition Television, HDTV 4K and AV
HD, 4K TV and Receivers
Humax HD
Humax Foxsat PVR locking up on signal degradation?
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.
Accept
Learn more…
Top