1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

SDV FAQ

Discussion in 'TiVo Series3 HDTV DVRs' started by bdraw, Jul 3, 2007.

  1. Jun 6, 2008 #1641 of 2401
    lrhorer

    lrhorer Active Member

    6,924
    0
    Aug 31, 2003
    San...
    Well, yes, but that doesn't mean the CATV proivider is required to. They can send anything they choose out in the clear. Indeed, while I haven't noticed them doing any such thing in the last couple of years - not that I've paid attention - some CATV companies will host subscriber campaigns designed to get subs to add pay channels by disabling encryption for a time so everyone gets certain channels for a short time for free.

    Edit: Note San Antonio, like Austin, encrypts its SDV channels - although I haven't checked them all I would presume all of them. The only thing you might find is an occasional video rewind stream where someone watching one of the locals on an STB presses <Pause>. I don't know for a fact, but I wouldn't necessarily expect on-demand content spawned from an unencrypted source to be encrypted.
     
  2. Jun 6, 2008 #1642 of 2401
    lrhorer

    lrhorer Active Member

    6,924
    0
    Aug 31, 2003
    San...
    Absolutely. Even if it isn't a mistake, it's a mistake, especially when it comes to porn. Deliberately sending out porn in the clear is a good way to invite a lawsuit.

    OTOH, there was a local automated weather channel on a CATV system in a small town back in the 70s (basically it was just a video camera on a tripod pointed at a dial thermomenter, a dial barometer, a psychrometer, and an anemometer) who had a prank played on them. Some teenagers broke into the site and put a full frontal centerfold model up in front of the meters.

    Apparently no one at the CATV company ever bothered to look at the channel, because the centerfold stayed there for 2 weeks. Even when it did come down, it was because someone called in. Whoever it was didn't complain about the centerfold, he just wanted to know if a storm was coming and couldn't see the barometer. :p
     
  3. Jun 6, 2008 #1643 of 2401
    lrhorer

    lrhorer Active Member

    6,924
    0
    Aug 31, 2003
    San...
    Or anything else the CATV company choses to deliver. The Tru2Way spec requires a middleware socket where the local provider's interactive agent would attach. This enables compatibility with every service delivered by the CATV company, at their discretion, at least at this point.
     
  4. Jun 6, 2008 #1644 of 2401
    routerman

    routerman New Member

    36
    0
    Sep 15, 2006
    Austin, Texas
    Can you clarify the above statement?

    Does this mean that if my cable company uses bigband for SDV, their VOD equipment is also bigband or do you mean the VOD services are transmitted over the SDV equipment?
     
  5. Jun 6, 2008 #1645 of 2401
    ajwees41

    ajwees41 Active Member

    2,010
    1
    May 7, 2006
    Omaha,NE
    If a CATV company is deploying SDV, then their on-demand services will use the SDV platform as a carrier.

    So what are cable companies using to provide ondemand if they aren't using SDV yet?
     
  6. Jun 7, 2008 #1646 of 2401
    cableguy763

    cableguy763 New Member

    525
    0
    Oct 29, 2006
    Austin
    Cable co's can use completely different VOD and SDV platforms. Seachange, SA, Moto, Arroyo all make VOD systems that can work with Bigband, SA, and Moto SDV systems.
     
  7. Jun 7, 2008 #1647 of 2401
    bicker

    bicker bUU

    10,382
    43
    Nov 9, 2003
    Georgia
    Thanks for the info on SDV versus VOD platforms. I had suspected that the two services would be unrelated to each other, and that confirms it.
     
  8. Jun 7, 2008 #1648 of 2401
    moyekj

    moyekj Well-Known Member

    11,142
    31
    Jan 23, 2006
    Mission...
    Once SDV is deployed is it possible to deliver VOD via SDV as well? Cox Orange County VOD system dedicates 8 whole RF channels (with 10 VOD streams per RF using QAM 256) to VOD which seems like a big waste of linear bandwidth that would make much more sense to put under a switched system.
     
  9. Jun 7, 2008 #1649 of 2401
    ah30k

    ah30k Active Member

    2,211
    0
    Jan 8, 2006
    I wouldn't say 'put VOD on SDV' but the deployment of SDV will allow a much more dynamic allocation of bandwidth. It is like the boundary between SDV and VOD will ebb and flow based on demand. You could not do that before without doing channel map changes.
     
  10. Jun 7, 2008 #1650 of 2401
    routerman

    routerman New Member

    36
    0
    Sep 15, 2006
    Austin, Texas
    That would work as long as the peak times for each programming (VOD and SDV) did not occur at the same time. I am guessing that the cable company would give higher priority to the VOD streams since they probably generate more money per resource.

    There should be a way to optimize usage by some kind of algorithm that weighs usage and allocates resources as needed. Kind of like load sharing on web servers and firewalls. Maybe they could allocate 10 channels for both VOD and SDV. 4 could be dedicated for VOD and 4 for SDV. The remaining 2 would be available for either service on an as needed basis.

    just my 2 cents.....
     
  11. Jun 7, 2008 #1651 of 2401
    lrhorer

    lrhorer Active Member

    6,924
    0
    Aug 31, 2003
    San...
    Probably both, although some systems do buy their equipment piecemeal from more than one vendor. Unless contracturally bound, there is nothing fundamentally preventing a company from buying the first set of QAM modulators from Big Band and then another set a year later from C-Cor. There is also nothing that requires them to keep all the content of one type on a particular QAM - as long as both are SDV capable. There is also nothing fundamentally preventing them from deciding to "dedicate" one QAM modulator to regularly scheduled SDV content and another to VOD and other on-demand services, but there also is generally speaking no particularly good reason to do so, either, and doing so will probably reduce the overall efficiency of the switched deployment by at least a small amount.

    While the company is not locked into any one modulator manufacturer, they are in practical terms locked into a single switching protocol. Thus, while one might conceivably find modulators and demodulators from two or more manufacturers in a single headend, one will not find STBs from both Motorola and Cisco in the homes serviced by that headend. There are some 3rd party STB manufacturers - Pace for example - which have licensed both Cisco and Motorola protocols for their STBs, but that doesn't mean a Pace STB in a Cisco plant can be taken to a Motorola plant and still work. It's no doubt possible both could be integrated into a single box, but it would be more expensive, and a better way to handle the situation is to make a single frame and motherboard for both versions of the STB and employ a daughter card of the appropriate type to differentiate the two. STBs with SA compatible daughter cards get shipped to SA systems and ones with Moto compatible daughter cards go to Moto systems. If not daughtercards, then different chipsets would do,as well. They even might manufacture completely different boxes, but I doubt it.
     
  12. Jun 7, 2008 #1652 of 2401
    lrhorer

    lrhorer Active Member

    6,924
    0
    Aug 31, 2003
    San...
    Oh, there are a number. The major one is IPTV, used by FIOS. Any sufficiently intelligent switching protocol will work. It also does not absolutely have to switch on node boundaries (IPTV usually doesn't). It's just that the node boundary is the most efficient and economical switch point in most fiber and aluminum CATV systems. Some systems have toyed around with fiber only implementations (fiber all the way to the house), and in such cases there may be multiple switch boundaries in the system.
     
  13. Jun 7, 2008 #1653 of 2401
    ah30k

    ah30k Active Member

    2,211
    0
    Jan 8, 2006
    The technologies are different between VOD and SDV, and VOD has been launched for quite some time. All VOD is is a dedicated QAM channel for you. Well, it isn't really just sent to you but your STB should be the only one on the plant with trick-play controls and the keys to decrypt the stream (in the early days it wasn't even encrypted). It is a regular QAM channel just like any other. Your STB can watch the stream and send trick-play commands back to the VOD server in the headend (any brand server will suffice) that is streaming your stream using whichever protocol the headend is based on. The VOD server would pause/rewind/play your stream based on your commands. It is not necessarily related to SDV at all. SDV can make the overall usage of the plant's bandwidth better though by not fixing a hard number of QAMs to VOD usage.
     
  14. Jun 7, 2008 #1654 of 2401
    lrhorer

    lrhorer Active Member

    6,924
    0
    Aug 31, 2003
    San...
    It most likely is, depending on the system.

    It's not linear. That they have dedicated 80 streams to VOD ratehr than sharing the modulator arrray between scheduled and on-deman video doesn't mean it is linear. If it were linear, 80 wouldn't be nearly enough. Do you think in Orange county only 80 people at a time make any use of VOD channels? 80,000 might be more like it, especially if they have deployed anything like video rewind.

    Trust me, if it is VOD, it is switched. Otherwise they would require a bandwidth of several thousand MHz.

    The fact they can use mixed platforms doesn't mean they do. What's more, once again the posters are confusing the distinctions between the transport protocols, the content, and the marketing differentiation between products which are in no way physically different.

    The following is lengthy. Consider it a primer on switched video and on-demand services. If you don't wish to read this primer, then by all means skip it. If you don't wish to respond, then don't or if you do then by all measns do. It's not intended as an ordinary debate post, so please squelch any flames about its length.


    Consider the following. HBO, Showtime, Cinemax, etc are all "Premium" channels. In order to obtain them, on most systems the user must pay an extra monthly charge on a channel by channel (or group of channels) basis. Stations like TBS, TNT, Discovery, etc. are all "regular" cable channels, and are usually included in one or more tiers - possibly even the basic tier - as part of the subscriber's regular bill. Local channels are those broadcast over the air by local TV stations. Other than encryption or a lack thereof, there is no physical difference between the three channel types, or fundamentally between the way their respective content is received at the customer's TV. The transport media, however, vary a great deal, and the type of source equipment can vary a lot. The fact the CATV company chooses to bundle them, charge for them, and label them in different ways doesn't mean it takes some sort of special gear to carry premium channels versus basic channels or regular channels, however.

    OK, now what about SDV? SDV is a set of switched protocols. A linear channel does not employ any switching at all in the transport system. Any switching done on a linear channel is done manually, at the Master Control or Technical Operations Center by CATV personnel or automated equipment under their control. For example, when watching a national video feed, if you pay attention you might notice a local commercial right in the middle of a nationally broadcast program. Your local commercial is probably not being broadcast across the entire nation. Rather, either the local network affiliate or the local CATV company switches away from the national feed for a few seconds to insert a local commercial for which the local station or CATV company is paid rather than the National Network. Once leaving the MC or TOC, however, it gets inserted into what can be envisaged as the trunk of a tree, to flow upwards and be split again and again into a series of smaller and smaller tributaries. At the very tip of this maze of tributaries is a large number of individual subscribers. The main point is, the signal reaching every single one of the tips is precisely the same as that entering into the trunk and as that reaching every other tip. This is a linear channel. Any video the company chooses can be placed on one of these channels, including even a VOD or other on-demand stream, if they were completely insane. While technically possible, putting on-demand streams on linear channels would limit the CATV company to only delivering three or four channels, total, because all 70 - 100 QAMs (in a 100&#37; digital system) would have to be dedicated to those 3 or 4 channels. So why have linear channels at all? Eventually, there may not be, but for the time being at least - and ignoring the locals which are under legal restrictions - it makes good sense to have at least a moderate number of linear QAMs.

    Why? In order to answer that question we must look a little closer at the alternatives. There is a different way to provide signals to subscribers than the tree-like linear delivery. Instead, imagine a hub-and spoke arrangement with a central core and a large number of spokes radiating from the hub. The hub can deliver completely independent streams into each spoke, so that what arrives at the end of each spoke is potentially either completely or partially different than what arrives at any other endpoint. (Note if we look closely each spoke is actually a smaller version of the linear "tree" we described above.) The hub can be said to contain a number of switching boundaries, where the decision of what to send down which spoke is implemented. Not made, mind you, but implemented. Logically speaking, where the switch boundary is placed is arbitrary, but in a typical CATV system, by far the best place for a switching boundary is the node. Thus, if part of a switching realm, the signal placed onto a particular node shows up at every single receiver in the node, but not on any receiver outside the node. In implementation, this means hypothetically that in a hub with 100 nodes, at 300.00MHz in the spectrum in a single channel's timeslot there could be 100 different programs being broadcast. In a pure switched digital system with 500MHz of useable bandwidth, such a hubsite could hypothetically broadcast nearly 17,000 HD programs or nearly 92,000 different SD programs to perhaps 50,000 subscribers with maybe 125,000 TVs. That's a heck of a lot better than the linear system which over the same field architecture could only deliver 167 HD programs or 916 SD programs. (Or 83 analog SD programs or 13 analog HD programs. Ugh.)

    So far, so good, but again ignoring the local broadcast channels and angry TiVo-owning subs, why have any linear channels at all? The huge benefit in numbers detailed above presumes that every node will require one for one completely different programs than any other node. This is not the case. For any given number of nodes, if at least 1 subscriber on each node wants the same video, then every one of the nodes will carry it, and for that particular program there is no benefit for switched video at all at that moment. If the content is on a regular scheduled channel and at every point in time at least one sub on every node is watching the channel, then the channel will never be switched off any node, and there is no advantage at all to switching the channel. If a node hosts 400 -500 subscribers and 300 or so timeslots, then any scheduled channel with a minimum daily instantaneous market share in excess of 4% - 5% or so will not be shut down on that node for any significant period of time, and would not be shut down on enough nodes in total for enough time to make switching worthwhile. Such channels are more economically served on linear equipment.

    At the transport level there is absolutely no difference between a regularly scheduled SDV program and a VOD or other on-demand service. The difference lies in two areas. One is the insertion source. For an external source such as satellite video feeds or local broadcast channels, the cATV company simply takes the incoming stream and sends it out to its video switches, tagging it with source and destination addresses. For locally hosted IPPV events, the company may simply have their own of what are basically automated DVRs which begin transmitting specific steams at regularly scheduled times. At the headend or hubsite, the switch receives all of its streams and decides which QAMs are to receive which streams. If a node is dark for a particular stream and a sub on the node changes to the channel in question, the STB / DVR sends a request to the headend to receive the channel. Coordinating between the switch, the video server, and the STB, the decision is made upon which QAM to host the feed on the node and the STB is told on which QAM to find the feed. If it is a "regular" video, then the STB will probably already contain the encryption keys. If it is IPPV -whether scheduled or otherwise, then the server also delivers the encryption keys and notifies the billing computer.

    For an on-demand service, the exact same series of events takes place potentially over exactly the same transport equipment, except that the video server must be capable not of just passing on a video stream received from an external source, but must be capable of seeing to it the stream itself is created and possibly started and stopped. Once again, if the stream is on-demand IPPV, then it notifies the billing computer, selects the QAM to receive the stream, issues the keys if necessary, and starts the stream. In some topologies it can make some sense to segregate the on-demand streams from scheduled switch streams, because the video server for the scheduled streams can be much less capable than the one required for on-demand services. In a system like San Antonio, however, where every single channel can have its stream split off at any moment by a sub pressing <Pause> on his STB remote, it doesn't make all that much sense to segregate channels. Of course, if it happens to be a linear channel, then the linear server continues to happily pump away with the main stream while an on-demand server carries out the funny business around the formerly-linear-now-suddenly-on-demand stream.

    The other area where there is a difference has nothing directly to do with the equipment, but rather with the patterns of the traffic and the bandwidth related thereto. An SDV transmission of a scheduled program may not hit every node in the system, saving bandwidth on those not receiving it, but it is still somewhat likely to hit more than one node in the system, and it usually consists of what are essentially multicast packets. While not sharp, there is nonetheless a vague limit to the number of scheduled programs which can be broadcast in a system because of this. This is perfectly Ok, however, because since the streams are inifinitely continuous, there is also an absolute limit to the number of nodes which can request the stream (all of them, however many there may be) and an exact limit to the number of streams which will be generated to fulfill the channel's broadcast footprint. That number is precisely 1.

    While there is no requirement for any fundamental difference in the underlying transport equipment which delivers on-demand streams, there is a huge difference in the number of streams generated by an on-demand service. Generally speaking, most on-demand streams have one and only one target node. The packets are essentially unicast. The stream is sent out intending to be received by one and only one subscriber. This still doesn't require anything different from the transport system than regularly scheduled SDV content. After all, there is absolutely nothing which says there can't be a channel available which only gets requested by a single sub at some point in time. The only difference so far is the content is being generated by the video server, while the scheduled program might be coming from somewhere else. What happens, however, when 45 seconds later another subscriber somewhere requests the same video? The answer is a completely new stream must be initiated and even if the receiver is on the same node (or even in the same house), a new QAM channel must be assigned to the new stream. Thus, given a system of 100,000 subs, 250,000 receivers, 200 nodes, and 300 scheduled channels with a 500MHz SDV bandwidth, the maximum number of unique streams on the system at any one time is 300, but unless a significant number are SD, all 300 can't be received on every node. If the same system has 100 or so VOD channels, the maximum number of simultaneous streams which could hypothetically be handled is perhaps in excess of 50,000. The number which actually do get assigned is equal to the number of receivers which request on-demand content.

    OK, so back to the original question. Is it necessary to segregate VOD and SDV as different services? Fundamentally, no. There can be a reason, however, to dedicate one group of QAMs to on-demand services and another to scheduled programming. I don't say it's a good reason, but it's a reason. If the CATV system is attempting to move to switched services on the cheap and doesn't have enough QAMs to properly handle all the switched service requests, they might choose to limit the number of on-demand QAMs rather than risk a lot of "channel not available" messages on HBO, Showtime, etc. They might figure a denied on-demand request is less aggravating than a denied request for a scheduled channel.
     
  15. Jun 7, 2008 #1655 of 2401
    cableguy763

    cableguy763 New Member

    525
    0
    Oct 29, 2006
    Austin
    Good gosh I bet your fingers hurt from all that typing.
     
  16. Jun 7, 2008 #1656 of 2401
    Combat Medic

    Combat Medic No guts, no glory

    8,325
    0
    Sep 6, 2001
    San...
    So, what you are saying is that SDV is a band aid trying to let cable tv operators compete with FiOS who does this naturally?
     
  17. Jun 7, 2008 #1657 of 2401
    ZeoTiVo

    ZeoTiVo I can't explain

    25,527
    0
    Jan 2, 2004
    so the dongle can order VOD/PPV. so what? Without a UI interface that the cable company controls they have no real blip on their rader for the Series 3 TiVo DVRs that are out there, especially with the series 4 coming along that will have tru2way and the UI that the cable company controls
     
  18. Jun 8, 2008 #1658 of 2401
    lrhorer

    lrhorer Active Member

    6,924
    0
    Aug 31, 2003
    San...
    Oh that's nothing. You should see my engineering briefs. They aren't. :p
     
  19. Jun 8, 2008 #1659 of 2401
    lrhorer

    lrhorer Active Member

    6,924
    0
    Aug 31, 2003
    San...
    Not really, no. A "bandaid" suggests a temporary or ineffective solution. SDV is neither. It permanently bolsters the effective bandwidth of the CATV plant manyfold. The number of channels is limited only by the number of subs per node. If they start running shy of bandwidth, they can simply add more nodes. While adding a node isn't exactly cheap, it is far, far less expensive than attempting to increase the bandwidth of the transport equipment, and far more effective.

    IPTV is another switched protocol. It's just that it's switch boundaries are different and more fluid. FIOS also has much higher infrastructure costs, so the subscription density has to be much higher. Many homes are going to be left high and dry as far as FIOS is concerned. More to the point, FIOS or not, the conventional CATV plant architecture wastes a tremendous amount of bandwidth for nothing, and SDV is a comparatively inexpensive solution to that problem. It is probably true that without competition from FIOS and much more prominantly D*, the CATV companies would probably not have laid out the capital, or at least not nearly as agressively as they are now. Some still are not, as their senior management apparently does not feel as threatened by D* and FIOS as others.
     
  20. Jun 8, 2008 #1660 of 2401
    lrhorer

    lrhorer Active Member

    6,924
    0
    Aug 31, 2003
    San...
    It suits my needs entirely. As long as the Series 3 continues to work with scheduled programming and as long as the CATV companies continue to offer all the currently scheduled offerings as scheduled offerings rather than VOD, I have no plans to replace my Series 3 boxes. For that matter, even if all the parties collaborate and enable VOD and IPPV on the Series 3, I won't be using them.

    If some of the more advanced interactive services on the horizon are something I just must have, I may revise my stance, or perhaps just get a CATV leased STB.

    Tru2way won't allow the cable company to control the UI, although it will allow the CATV company to create folders and menus on the box. HME and HMO already do that. Galleon and pyTiVo both create a perfectly nice set of folders and menu items on my TiVos. It will allow the CATV company to unilaterally decide what interactive software is loaded on the TiVo and what 2-way features are enabled, including spyware.
     

Share This Page