[iptv-users] STB/video stream monitoring

[Kevin Shymkiw]

For MDU's, why don't you run FTT"x" and put it in a common area, and 
terminate it into a Multi-Layer Switch?  Then run Cat6 from the Common 
Area, into each apartment.  This allows you to still target MDU's, and 
have all the flexibility you would need, just like FTTH.

As well, I guess my mindset is a bit different as far a SHE is 
concerned, since I am in a company where the Network is so big, and we 
own so much fiber, that sometimes my ideas, don't scale well for the 
smaller MSO's/ISP's/CATV Operators =).

Kevin

Alex Moen wrote:
> Actually, we're kind of moving away from the super head end model.  
> Transport agreements are getting harder to get.  As long as whoever is 
> maintaining the SHE is responsive to the other member's requests and 
> input, things go well.  When the managers of the SHE start changing 
> things without consent of the group, or are not available when things 
> break, it can get very frustrating.
>
> We are moving to FTTH, but have to deploy video on ADSL2+ to customers 
> who do not have fiber, or those in areas that cannot get fiber (ie, 
> apartment bldgs).  We are looking at VDSL, but so far we haven't found 
> a system that we like or that is mature.
>
> Alex
>
>
>
> On Jul 2, 2009, at 6:59 AM, Kevin Shymkiw wrote:
>
>> That seems to be the model we want to move to is a "super head end".  
>> It seems to make more sense in terms of managing and verifying 
>> content quality.
>>
>> I hear alot of you talking about DSLAM issues, etc... are most of you 
>> doing IPTV through DSL or VDSL Networks?
>>
>> Kevin
>>
>> Frank Bulk wrote:
>>>
>>> Since we use a state-wide shared head end , if there’s an issue with 
>>> an encoder other service providers in the state see it, too.  
>>> Additionally the organization that manages the headend has 
>>> Ineoquest, too.  Today we pick up the MPEG-2 video over OC-3s, so we 
>>> have all the ATM PM counters, too, in regards to transport.
>>>
>>> Frank
>>>
>>> From: Kevin Shymkiw [mailto:kshymkiw at gmail.com]
>>> Sent: Wednesday, July 01, 2009 7:24 AM
>>> To: frnkblk at iname.com
>>> Cc: 'Alex Moen'; iptv-users at puck.nether.net
>>> Subject: Re: [iptv-users] STB/video stream monitoring
>>>
>>> In all honesty, we have had alot of Finger Pointing that ended up 
>>> being bad feeds from the source, especially since we pick up alot of 
>>> our feeds from other Video/Cable Providers.  But without a doubt, if 
>>> you have a video probe at your edge before you go to the Copper 
>>> Plant, it makes it very easy to point the finger at them and have 
>>> the proof to support it.
>>>
>>> We do also seem to have alot of issues, when we are doing >6-8G of 
>>> Multicast over some of the Cisco Cards we have deployed, so at 
>>> times, that does come back to bite us.
>>>
>>> Kevin
>>>
>>> Frank Bulk wrote:
>>> When you have this finger-pointing, what does the problem actually 
>>> end up
>>> being?  The vast majority of our video quality issues relate to the 
>>> copper
>>> plant.  Only a minority have been related our transport gear's 
>>> ability to
>>> drop the content off the DSL port.
>>>
>>> Frank
>>>
>>> -----Original Message-----
>>> From: Alex Moen [mailto:alexm at ndtel.com]
>>> Sent: Tuesday, June 30, 2009 11:35 AM
>>> To: frnkblk at iname.com
>>> Cc: iptv-users at puck.nether.net
>>> Subject: Re: [iptv-users] STB/video stream monitoring
>>>
>>> Take a look at Ineoquest's iVMS (for transport quality monitoring) and
>>> iCMS (for video/audio content quality and end-user experience
>>> monitoring).  We use both of these products, and they can be both a
>>> lifesaver and a "finger-pointing" resolver.
>>>
>>> http://www.ineoquest.com
>>>
>>> Alex
>>>
>>>
>>> On Jun 30, 2009, at 11:02 AM, Frank Bulk wrote:
>>>
>>>
>>> Is anyone doing any video stream error monitoring/checking from the
>>> point-of-view of the STB?  I know that there is at least one vendor
>>> out
>>> there, Psytechnics, that has a module it can integrate into the
>>> middleware
>>> of the STB, but I haven't see IPTV middleware vendors picking that
>>> up.  I
>>> know that the Amino 110 writes out some rudimentary stats to the
>>> drive.
>>>
>>> We track most of our video problems based on the 15-minute PM bins
>>> that our
>>> transport gear's ADSL ports record, but nothing L4 and up.
>>>
>>> Ideally every STB would have something Psytechnic-like built in.
>>>
>>> Frank
>>>
>>>
>>> _______________________________________________
>>> iptv-users mailing list
>>> iptv-users at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/iptv-users
>>>
>>>
>>>
>>> _______________________________________________
>>> iptv-users mailing list
>>> iptv-users at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/iptv-users
>>>
>>>
>
>