Sign in with
Sign up | Sign in
Your question

DTV and MATV systems

Last response: in Home Theatre
Share
Anonymous
August 26, 2005 1:31:50 AM

Archived from groups: sci.engr.television.advanced,alt.video.digital-tv (More info?)

How will the cutover to DTV in the USA affect MATV systems, such as
typically found in apartment buildings and apartment complexes doing
basic OTA reception?

Obviously some changes need to be made due to the channel changes most
stations are going through, depending on how that MATV system is set
up. Typically, these systems convert UHF to VHF to reduce the coaxial
loses. I'm sure there are some smaller ones that just leave everything
on the same channel, even on UHF. Since they are generally only OTA
channels, there would rarely be more than 12 channels involved, anyway.

How will being converted to another channel affect ATSC transmissions?

Will analog channel-to-channel converters be adequate for 8VSB? What
if they have an IF stage and are doing some analog VSB processing?

Are there any ATSC to bit stream back to ATSC converters (demodulator
followed by modulator) on the market?

Is it possible to convert from 8VSB to 64QAM or 256QAM and preserve the
entire ATSC bit stream so that a TV on the MATV system can receive all
the programming carried on that OTA signal? Or would the TV be confused
expecting a different kind of bit stream?

--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------

More about : dtv matv systems

Anonymous
August 26, 2005 1:31:51 AM

Archived from groups: sci.engr.television.advanced,alt.video.digital-tv (More info?)

<phil-news-nospam@ipal.net> wrote in message
news:D eldc60g6l@news3.newsguy.com...
> How will the cutover to DTV in the USA affect MATV systems, such as
> typically found in apartment buildings and apartment complexes doing
> basic OTA reception?
>
> Obviously some changes need to be made due to the channel changes most
> stations are going through, depending on how that MATV system is set
> up. Typically, these systems convert UHF to VHF to reduce the coaxial
> loses. I'm sure there are some smaller ones that just leave everything
> on the same channel, even on UHF. Since they are generally only OTA
> channels, there would rarely be more than 12 channels involved, anyway.
>
> How will being converted to another channel affect ATSC transmissions?
>
Changing the frequency should be possible with no problem, except - see
below

> Will analog channel-to-channel converters be adequate for 8VSB? What
> if they have an IF stage and are doing some analog VSB processing?
>
Existing analog processors won't work for digital signals because they have
internal filtering and circuitry that deals with audio and video portions of
the signal separately. The 8-VSB signal occupies the entire channel space,
so such filtering and processin would destroy it.

> Are there any ATSC to bit stream back to ATSC converters (demodulator
> followed by modulator) on the market?
>
> Is it possible to convert from 8VSB to 64QAM or 256QAM and preserve the
> entire ATSC bit stream so that a TV on the MATV system can receive all
> the programming carried on that OTA signal?

Yes, that's what cable companies do with the off-airs.

> Or would the TV be confused
> expecting a different kind of bit stream?
>

Depends on the TV. Some have no tuner at all (or NTSC only) some have ATSC
(8-VSB) and some have ATSC and QAM tuners. The "bit stream" is standard MPEG
video with AC3 audio, regardless of the modulation type.

> --
> -----------------------------------------------------------------------------
> | Phil Howard KA9WGN | http://linuxhomepage.com/
> http://ham.org/ |
> | (first name) at ipal.net | http://phil.ipal.org/
> http://ka9wgn.ham.org/ |
> -----------------------------------------------------------------------------
Anonymous
August 26, 2005 6:55:02 AM

Archived from groups: sci.engr.television.advanced,alt.video.digital-tv (More info?)

In sci.engr.television.advanced Mike Rush <mikelr@avenuespamfreecable.com> wrote:
| <phil-news-nospam@ipal.net> wrote in message
| news:D eldc60g6l@news3.newsguy.com...
|> Are there any ATSC to bit stream back to ATSC converters (demodulator
|> followed by modulator) on the market?
|>
|> Is it possible to convert from 8VSB to 64QAM or 256QAM and preserve the
|> entire ATSC bit stream so that a TV on the MATV system can receive all
|> the programming carried on that OTA signal?
|
| Yes, that's what cable companies do with the off-airs.

So the bit stream over the cable is (carried by 64QAM/256QAM) will be
the same as the bit stream over the air (carried by 8VSB)? It was my
understanding that at least 256QAM had a much higher bit rate than
8VSB.


|> Or would the TV be confused
|> expecting a different kind of bit stream?
|>
|
| Depends on the TV. Some have no tuner at all (or NTSC only) some have ATSC
| (8-VSB) and some have ATSC and QAM tuners. The "bit stream" is standard MPEG
| video with AC3 audio, regardless of the modulation type.

The bit stream for ATSC is not MPEG, per se. If you demodulate the RF
carrier, reverse the trellis coding and scrambling, the resultant bit
stream is still a channelized layer that contains video/audio in MPEG
in each channel. What my concern is, is whether the cable headends
will be taking that ATSC multiplex apart and re-assembling things back
together again for the cable's modulation in whatever QAM. But since
it is a higher bit rate in 6 MHz of bandwidth, it would seem a waste to
pass the ATSC bit stream unchanged.

An MATV system still could just operate on pure ATSC/8VSB (provided it is
a clean flat band transfer). That would avoid the issue. But it seems
all of the available equipment is assuming QAM instead. An apartment
complex I used to live in converted several UHF channels to VHF and used
VHF-only amplifiers. Given the higher attenuation of UHF in any coax,
there would have to be more amplifiers in a larger MATV system if UHF
were carried as-is.

As I understand it, the FCC is interpreting the "must carry" law as being
only applicable to the primary channel of any DTV broadcaster. If the
additional programming that comes over a DTV channel is of any interest
to the public, and the cable systems don't choose to carry it, people in
their own homes may be able to put up an antenna to get it (subject to
various local laws and covenants). People in apartment buildings and
complexes would have to depend on the landlord to provide a common TV
antenna system so that can get what is only OTA.

I'd rather see the law changed (or clarified) to require all free OTA
programming be carried by cable systems to customers inside the station
grade B contour.

--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
Related resources
Anonymous
August 26, 2005 7:07:54 AM

Archived from groups: sci.engr.television.advanced,alt.video.digital-tv (More info?)

In sci.engr.television.advanced Mike Rush <mikelr@avenuespamfreecable.com> wrote:

|> Or would the TV be confused
|> expecting a different kind of bit stream?
|>
|
| Depends on the TV. Some have no tuner at all (or NTSC only) some have ATSC
| (8-VSB) and some have ATSC and QAM tuners. The "bit stream" is standard MPEG
| video with AC3 audio, regardless of the modulation type.

Can you tell if this equipment would be modifying the signal? Would it be
outputting ATSC? 8VSB? QAM?

http://www.blondertongue.com/digital/dhdp.pdf

--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
Anonymous
August 26, 2005 8:11:45 AM

Archived from groups: sci.engr.television.advanced,alt.video.digital-tv (More info?)

On 26 Aug 2005 02:55:02 GMT, phil-news-nospam@ipal.net
posted:

>What my concern is, is whether the cable headends
>will be taking that ATSC multiplex apart and re-assembling things back
>together again for the cable's modulation in whatever QAM. But since
>it is a higher bit rate in 6 MHz of bandwidth, it would seem a waste to
>pass the ATSC bit stream unchanged.

Actually, some cable companies do something more sinister to
the OTA ATSC signal:

<http://www.terayon.com/tools/static_page/view.html?phas...;

Today, only one statistical remultiplexing platform—the
Terayon CherryPicker—has the ability to rate shape both HD
and SD streams in the same channel. It remultiplexes and
optimizes bit rates in real-time, increasing available
bandwidth by up to 70 percent while always staying within
the digital domain to maintain the highest possible image
quality.

---

Terayon claims their rate shaping decode re-encode process
can reduce the HDTV data rate by 25% with minimal effect on
the picture quality.

Kirk Bayne
alt.video.digital-tv Home Page
<http://www.geocities.com/lislislislis/avdtv.htm&gt;
Anonymous
August 26, 2005 9:19:45 AM

Archived from groups: sci.engr.television.advanced,alt.video.digital-tv (More info?)

In alt.video.digital-tv K. B. <hotmail.com@lis2lis2> wrote:
| On 26 Aug 2005 02:55:02 GMT, phil-news-nospam@ipal.net
| posted:
|
|>What my concern is, is whether the cable headends
|>will be taking that ATSC multiplex apart and re-assembling things back
|>together again for the cable's modulation in whatever QAM. But since
|>it is a higher bit rate in 6 MHz of bandwidth, it would seem a waste to
|>pass the ATSC bit stream unchanged.
|
| Actually, some cable companies do something more sinister to
| the OTA ATSC signal:
|
| <http://www.terayon.com/tools/static_page/view.html?phas...;
|
| Today, only one statistical remultiplexing platform?the
| Terayon CherryPicker?has the ability to rate shape both HD
| and SD streams in the same channel. It remultiplexes and
| optimizes bit rates in real-time, increasing available
| bandwidth by up to 70 percent while always staying within
| the digital domain to maintain the highest possible image
| quality.
|
| ---
|
| Terayon claims their rate shaping decode re-encode process
| can reduce the HDTV data rate by 25% with minimal effect on
| the picture quality.

OK, that lets them stick more stuff in the ATSC stream, assuming the
broadcaster hasn't already used this device to squeeze even more out
of their own bandwidth.

But how will with a TV set handle this? Can it recognize the channels
after more is added on? Can it do this if the signal comes in as 8VSB?
As QAM?

What I am most curious about is taking the 19.39 mbps of ATSC and
remodulating it as 64QAM or 256QAM instead of 8VSB.

--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
Anonymous
August 26, 2005 10:30:43 AM

Archived from groups: sci.engr.television.advanced,alt.video.digital-tv (More info?)

On 26 Aug 2005 05:19:45 GMT, phil-news-nospam@ipal.net
posted:

>But how will with a TV set handle this? Can it recognize the channels
>after more is added on? Can it do this if the signal comes in as 8VSB?
>As QAM?

Here's an example of converting some of my local 8VSB OTA
DTV/HDTV 6MHz signals to 64-QAM or 256-QAM 6MHz signals:
OTA HDTV KMBC (ABC) DT-7 (labeled 9.1) and
OTA HDTV KCTV (CBS) DT-24 (labeled 5.1)
combined into 1 6MHz cable signal by using rate shaping to
combine DT-7 and DT-24 into an HDTV multicast and grooming
to relabel DT-7 as channel 2.1 and DT-24 as 2.2 (then
remodulate using 64-QAM or 256-QAM).

An ATSC DTV doesn't care about how many channels (or what
type - HDTV,EDTV,SDTV) are in a multicast so long as the
signal is an ATSC compliant datastream.

A DTV would need an QAM demodulator.

>What I am most curious about is taking the 19.39 mbps of ATSC and
>remodulating it as 64QAM or 256QAM instead of 8VSB.

Just remove all of the 8VSB specific error correction and
then remodulate the ATSC datastream with the modulation
system of your choice (even an OFDM based scheme) ;) 

Kirk Bayne
alt.video.digital-tv Home Page
<http://www.geocities.com/lislislislis/avdtv.htm&gt;
Anonymous
August 26, 2005 12:42:16 PM

Archived from groups: sci.engr.television.advanced,alt.video.digital-tv (More info?)

<phil-news-nospam@ipal.net> wrote in message
news:D em12a1fh8@news4.newsguy.com...
> In sci.engr.television.advanced Mike Rush <mikelr@avenuespamfreecable.com>
> wrote:
>
> |> Or would the TV be confused
> |> expecting a different kind of bit stream?
> |>
> |
> | Depends on the TV. Some have no tuner at all (or NTSC only) some have
> ATSC
> | (8-VSB) and some have ATSC and QAM tuners. The "bit stream" is standard
> MPEG
> | video with AC3 audio, regardless of the modulation type.
>
> Can you tell if this equipment would be modifying the signal? Would it be
> outputting ATSC? 8VSB? QAM?
>
> http://www.blondertongue.com/digital/dhdp.pdf
>
>

Looking at that spec sheet, it appears the output would be 8-VSB with its
frequency converted from broadcast channel frequencies to CATV frequencies.
Any set with an ATSC tuner should work for that as long as its tuning mode
could be switch to cable, which uses frequencies not in the normal VHF and
UHF bands.
Anonymous
August 26, 2005 4:01:28 PM

Archived from groups: sci.engr.television.advanced,alt.video.digital-tv (More info?)

In alt.video.digital-tv K. B. <hotmail.com@lis2lis2> wrote:
| On 26 Aug 2005 05:19:45 GMT, phil-news-nospam@ipal.net
| posted:
|
|>But how will with a TV set handle this? Can it recognize the channels
|>after more is added on? Can it do this if the signal comes in as 8VSB?
|>As QAM?
|
| Here's an example of converting some of my local 8VSB OTA
| DTV/HDTV 6MHz signals to 64-QAM or 256-QAM 6MHz signals:
| OTA HDTV KMBC (ABC) DT-7 (labeled 9.1) and
| OTA HDTV KCTV (CBS) DT-24 (labeled 5.1)
| combined into 1 6MHz cable signal by using rate shaping to
| combine DT-7 and DT-24 into an HDTV multicast and grooming
| to relabel DT-7 as channel 2.1 and DT-24 as 2.2 (then
| remodulate using 64-QAM or 256-QAM).

So I take it these broadcasters are not using this rate shaping device themselves.


| An ATSC DTV doesn't care about how many channels (or what
| type - HDTV,EDTV,SDTV) are in a multicast so long as the
| signal is an ATSC compliant datastream.

So how many channels can you get in there? Is there an upper limit on
number of channels?


| A DTV would need an QAM demodulator.

But would one (a few do have it) that has QAM know to interpret the
bitstream the ATSC way?


|>What I am most curious about is taking the 19.39 mbps of ATSC and
|>remodulating it as 64QAM or 256QAM instead of 8VSB.
|
| Just remove all of the 8VSB specific error correction and
| then remodulate the ATSC datastream with the modulation
| system of your choice (even an OFDM based scheme) ;) 

I understand any bit stream can be sent over any modulation scheme
designed for bit streams. But my real interest is knowing if the
set/tuner knows to interpret the bits it gets as ATSC when it switches
to QAM demoulation. What bit stream format does cable normally use
behind that 64QAM or 256QAM modulation? Wouldn't the set/tuner switch
to interpreting the bits as that format when switched to cable tuning
mode?

I could not download the documents that would tell what standards cable
TV uses because it was restricted to member organizations, only
(presuming the useful documents were there, which is not even a
certainty). So I really don't know if cable TV is just doing a copycat
of ATSC but changing the modulation. It would be great if they were
using the ATSC bit stream format. But it seems everyone wants to
invent their own thing.


FYI, I'm still looking for a demodulator that will output the whole
bitstream (all channels and data together ... no demultiplexing)
suitable for computer ingest (over USB, Firewire, or ethernet ... or as
a PCI card) ... AND a corresponding modulator that can take the same
stream as input and put it on an RF channel. That would then be a way
for me to re-integrate different channel streams in different ways, and
re-label them, etc., using my own computer software logic to do it in
special ways. Note, I also need it to be usable on Linux, even if I
have to write my own driver(s) (which I can do). Maybe I can just send
19.39 mbps of my own raw data over a 6 MHz RF channel on my own coaxial
cable or in a ham radio UHF/SHF band. If it can also do 64QAM, 256QAM,
and even 16VSB (at other bit rates, obviously), that would be even
better.

--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
Anonymous
August 26, 2005 8:09:01 PM

Archived from groups: sci.engr.television.advanced,alt.video.digital-tv (More info?)

In alt.video.digital-tv Mike Rush <mikelr@avenuespamfreecable.com> wrote:
| <phil-news-nospam@ipal.net> wrote in message
| news:D em12a1fh8@news4.newsguy.com...
|> In sci.engr.television.advanced Mike Rush <mikelr@avenuespamfreecable.com>
|> wrote:
|>
|> |> Or would the TV be confused
|> |> expecting a different kind of bit stream?
|> |>
|> |
|> | Depends on the TV. Some have no tuner at all (or NTSC only) some have
|> ATSC
|> | (8-VSB) and some have ATSC and QAM tuners. The "bit stream" is standard
|> MPEG
|> | video with AC3 audio, regardless of the modulation type.
|>
|> Can you tell if this equipment would be modifying the signal? Would it be
|> outputting ATSC? 8VSB? QAM?
|>
|> http://www.blondertongue.com/digital/dhdp.pdf
|>
|>
|
| Looking at that spec sheet, it appears the output would be 8-VSB with its
| frequency converted from broadcast channel frequencies to CATV frequencies.
| Any set with an ATSC tuner should work for that as long as its tuning mode
| could be switch to cable, which uses frequencies not in the normal VHF and
| UHF bands.

So it should be suitable for an MATV system wanting to convert channels from
UHF to VHF to minimize the coax loss, and has no interest in making a system
that works on QAM like cable TV does (e.g. so it just works fine with regular
DTV tuners). It did appear to me that equipment could also output at regular
broadcast frequencies, too.

--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
Anonymous
August 27, 2005 6:36:56 AM

Archived from groups: sci.engr.television.advanced,alt.video.digital-tv (More info?)

(phil-news-nospam@ipal.net) wrote in alt.video.digital-tv:
> | An ATSC DTV doesn't care about how many channels (or what
> | type - HDTV,EDTV,SDTV) are in a multicast so long as the
> | signal is an ATSC compliant datastream.
>
> So how many channels can you get in there? Is there an upper limit on
> number of channels?

Yes, it's in the ATSC specs, which you claim to have read.

They allocate a byte for the sub-channel number, but the specs say that
they can only use 1 to 99 for FTA sub-channels. It's unclear whether 100-255
can be used for pay sub-channels.

--
Jeff Rife | "Damn it, I miss the sound of her voice. I tried
| putting silverware down the disposal, but it
| wasn't the same."
|
| -- Ned Dorsey, "Ned and Stacey"
Anonymous
August 27, 2005 9:41:53 AM

Archived from groups: sci.engr.television.advanced,alt.video.digital-tv (More info?)

On 26 Aug 2005 12:01:28 GMT, phil-news-nospam@ipal.net
posted:

>So I take it these broadcasters are not using this rate shaping device themselves.

The local DTV stations are doing the original DTV/HDTV
encoding of the Network DTV/HDTV feeds so their encoder
settings serve the same function as rate shaping done later
in the DTV transmission process.

>Is there an upper limit on
>number of channels?

Yes, but I don't know what the maximum number of multicast
programs/channel is.

>But would one (a few do have it) that has QAM know to interpret the
>bitstream the ATSC way?

The ATSC receiver processing would have to support a much
higher data rate because, in a 6MHz channel, 64-QAM and
256-QAM can transmit more data than 8VSB (I don't know
what the maximum input data rate is for ATSC decoders).

>But my real interest is knowing if the
>set/tuner knows to interpret the bits it gets as ATSC when it switches
>to QAM demoulation. What bit stream format does cable normally use
>behind that 64QAM or 256QAM modulation? Wouldn't the set/tuner switch
>to interpreting the bits as that format when switched to cable tuning
>mode?

Yes, the ATSC receiver would switch to a different error
correction system when using QAM rather than 8VSB (I don't
know the specifics of the cable QAM system or how easy it
would be to convert an 8VSB delivered ATSC datastream to a
cable QAM compliant ATSC datastream).

>So I really don't know if cable TV is just doing a copycat
>of ATSC but changing the modulation. It would be great if they were
>using the ATSC bit stream format. But it seems everyone wants to
>invent their own thing.

Looks like cable will use an ATSC compliant datastream
transmitted using QAM but perhaps squeezed through rate
shaping at the headend.

>FYI, I'm still looking for a demodulator that will output the whole
>bitstream (all channels and data together ... no demultiplexing)
>suitable for computer ingest (over USB, Firewire, or ethernet ... or as
>a PCI card) ... AND a corresponding modulator that can take the same
>stream as input and put it on an RF channel. That would then be a way
>for me to re-integrate different channel streams in different ways, and
>re-label them, etc., using my own computer software logic to do it in
>special ways. Note, I also need it to be usable on Linux, even if I
>have to write my own driver(s) (which I can do).

You might find some useful info at the MPEG-2 Information
link on the alt.video.digital-tv Home Page.

Kirk Bayne
alt.video.digital-tv Home Page
<http://www.geocities.com/lislislislis/avdtv.htm&gt;
Anonymous
August 27, 2005 9:41:54 AM

Archived from groups: sci.engr.television.advanced,alt.video.digital-tv (More info?)

K. B. (hotmail.com@lis2lis2) wrote in alt.video.digital-tv:
> The local DTV stations are doing the original DTV/HDTV
> encoding of the Network DTV/HDTV feeds so their encoder
> settings serve the same function as rate shaping done later
> in the DTV transmission process.

Except for Fox and some PBS stations, this is true. Fox stations receive
an ATSC-ready MPEG-2 stream of about 15Mbps, and they then splice in their
logo (if they want) without re-encoding. They then add PSIP and null
packets until they reach 19.3Mbps (assuming they don't multicast).

Some PBS stations also take the national feed and send it out raw, because
it is (or at least was) available in a less than 19Mbps version.

There is a rumor that WB sends a 19Mbps feed over the satellite, but since
their stations don't have the splicing technology like the Fox stations,
it makes very little difference if they add a logo. They could send it out
without modification, though.

--
Jeff Rife |
| http://www.nabs.net/Cartoons/OverTheHedge/PizzaDelivery...
Anonymous
August 28, 2005 1:53:15 PM

Archived from groups: sci.engr.television.advanced,alt.video.digital-tv (More info?)

In sci.engr.television.advanced Jeff Rife <wevsr@nabs.net> wrote:
| (phil-news-nospam@ipal.net) wrote in alt.video.digital-tv:
|> | An ATSC DTV doesn't care about how many channels (or what
|> | type - HDTV,EDTV,SDTV) are in a multicast so long as the
|> | signal is an ATSC compliant datastream.
|>
|> So how many channels can you get in there? Is there an upper limit on
|> number of channels?
|
| Yes, it's in the ATSC specs, which you claim to have read.

I have not gone over it with a fine tooth comb, yet. As soon as I find
a means to demodulate an RF signal into a bitstream, and modulate a
bistream into an RF signal, then I plan to deal with all the details
so I can implement some ATSC manipulation software.


| They allocate a byte for the sub-channel number, but the specs say that
| they can only use 1 to 99 for FTA sub-channels. It's unclear whether 100-255
| can be used for pay sub-channels.

Maybe it'll confuse a TV, but it can be useful for some of the things I
plan to do.

--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
Anonymous
August 28, 2005 2:02:18 PM

Archived from groups: sci.engr.television.advanced,alt.video.digital-tv (More info?)

In sci.engr.television.advanced Jeff Rife <wevsr@nabs.net> wrote:
| K. B. (hotmail.com@lis2lis2) wrote in alt.video.digital-tv:
|> The local DTV stations are doing the original DTV/HDTV
|> encoding of the Network DTV/HDTV feeds so their encoder
|> settings serve the same function as rate shaping done later
|> in the DTV transmission process.
|
| Except for Fox and some PBS stations, this is true. Fox stations receive
| an ATSC-ready MPEG-2 stream of about 15Mbps, and they then splice in their
| logo (if they want) without re-encoding. They then add PSIP and null
| packets until they reach 19.3Mbps (assuming they don't multicast).

Given that the typical modern digital ready TV station is wired with SDI
going around, and SDI carries uncompressed video/audio digitally, and the
switchers are processing it in that form, it would seem that the MPEG-2
would normally be decided and re-encoded. That's not to say they haven't
set up a direct bypass when feeding network.


| Some PBS stations also take the national feed and send it out raw, because
| it is (or at least was) available in a less than 19Mbps version.
|
| There is a rumor that WB sends a 19Mbps feed over the satellite, but since
| their stations don't have the splicing technology like the Fox stations,
| it makes very little difference if they add a logo. They could send it out
| without modification, though.

So why is it that the splicing technology is specific to Fox stations?
The network included in their equipment? I've never seen a Fox station
that adds a local logo with the network logo when feeding network. I
have seen one PBS station do that (channel 13 in Dallas) but that was
SD over analog, so not likely an MPEG issue.

--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
Anonymous
August 28, 2005 2:09:09 PM

Archived from groups: sci.engr.television.advanced,alt.video.digital-tv (More info?)

In article <des23a12iq9@news3.newsguy.com>, phil-news-nospam@ipal.net
wrote:

> So why is it that the splicing technology is specific to Fox stations?
> The network included in their equipment? I've never seen a Fox station
> that adds a local logo with the network logo when feeding network. I
> have seen one PBS station do that (channel 13 in Dallas) but that was
> SD over analog, so not likely an MPEG issue.

KLRU PBS in Austin also adds a local logo to all of their subchannels,
100% of the time, but now that you mention it, I don't recall seeing any
of the other local stations putting a station logo over HD content.

KLRU also has the ability to down-sample its third and fourth
subchannels when it switches to HD in the evening, to the point that
they can confuse MPEG decoders. Sometimes I'll switch the amp over to
the HD tuner and just listen to the audio while I'm doing something else
(video game, etc.) on the TV.
Anonymous
August 28, 2005 4:35:40 PM

Archived from groups: sci.engr.television.advanced,alt.video.digital-tv (More info?)

(phil-news-nospam@ipal.net) wrote in alt.video.digital-tv:
> | Except for Fox and some PBS stations, this is true. Fox stations receive
> | an ATSC-ready MPEG-2 stream of about 15Mbps, and they then splice in their
> | logo (if they want) without re-encoding. They then add PSIP and null
> | packets until they reach 19.3Mbps (assuming they don't multicast).
>
> Given that the typical modern digital ready TV station is wired with SDI
> going around, and SDI carries uncompressed video/audio digitally, and the
> switchers are processing it in that form, it would seem that the MPEG-2
> would normally be decided and re-encoded.

Not for Fox. Maybe you should read a bit more at AVS Forum, where the Fox
engineers hang out.

> | Some PBS stations also take the national feed and send it out raw, because
> | it is (or at least was) available in a less than 19Mbps version.
> |
> | There is a rumor that WB sends a 19Mbps feed over the satellite, but since
> | their stations don't have the splicing technology like the Fox stations,
> | it makes very little difference if they add a logo. They could send it out
> | without modification, though.
>
> So why is it that the splicing technology is specific to Fox stations?
> The network included in their equipment?

First, you have a true network (unlike PBS). Second, Fox was late to the
HD game, so they looked at what others had done right or wrong, and made
decisions based on that. So, they saw that if they spent a *lot* of money
on a network-level encoder, they could allow their stations to save money
by purchasing less expensive equipment. The logic is that locally sourced
material is from an SD source 99% of the time, so you don't need as good
an encoder.

So, Fox outfitted their stations with equipment that allows them to do
things differently than other networks, but this ensures a more consistent
look for network programming on all affiliates.

> I've never seen a Fox station
> that adds a local logo with the network logo when feeding network.

Of course, you don't have an HDTV, so you don't know what the HD programs
from Fox look like.

--
Jeff Rife |
| http://www.nabs.net/Cartoons/OverTheHedge/BrokenInterne...
Anonymous
August 28, 2005 4:37:31 PM

Archived from groups: sci.engr.television.advanced,alt.video.digital-tv (More info?)

(phil-news-nospam@ipal.net) wrote in alt.video.digital-tv:
> | Yes, it's in the ATSC specs, which you claim to have read.
>
> I have not gone over it with a fine tooth comb, yet.

In other words, you haven't really read it at all.

> As soon as I find
> a means to demodulate an RF signal into a bitstream, and modulate a
> bistream into an RF signal, then I plan to deal with all the details
> so I can implement some ATSC manipulation software.

Maybe you should let people that know what they are doing do the work.
There's lots of open-source code available.

--
Jeff Rife |
| http://www.nabs.net/Cartoons/OverTheHedge/HighTech.gif
Anonymous
August 29, 2005 12:42:20 AM

Archived from groups: sci.engr.television.advanced,alt.video.digital-tv (More info?)

In sci.engr.television.advanced Jeff Rife <wevsr@nabs.net> wrote:
| (phil-news-nospam@ipal.net) wrote in alt.video.digital-tv:
|> | Except for Fox and some PBS stations, this is true. Fox stations receive
|> | an ATSC-ready MPEG-2 stream of about 15Mbps, and they then splice in their
|> | logo (if they want) without re-encoding. They then add PSIP and null
|> | packets until they reach 19.3Mbps (assuming they don't multicast).
|>
|> Given that the typical modern digital ready TV station is wired with SDI
|> going around, and SDI carries uncompressed video/audio digitally, and the
|> switchers are processing it in that form, it would seem that the MPEG-2
|> would normally be decided and re-encoded.
|
| Not for Fox. Maybe you should read a bit more at AVS Forum, where the Fox
| engineers hang out.

If you think AVS Forum is so great, why is it you hang out here? Could
it be that you'd get kicked out of AVS Forum if you behaved there like
you do here, and this is the only place for you to "let it hang out"?

--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
Anonymous
August 29, 2005 12:42:21 AM

Archived from groups: sci.engr.television.advanced,alt.video.digital-tv (More info?)

phil-news-nospam@ipal.net wrote:
> In sci.engr.television.advanced Jeff Rife <wevsr@nabs.net> wrote:
> | (phil-news-nospam@ipal.net) wrote in alt.video.digital-tv:
> |> | Except for Fox and some PBS stations, this is true. Fox stations receive
> |> | an ATSC-ready MPEG-2 stream of about 15Mbps, and they then splice in their
> |> | logo (if they want) without re-encoding. They then add PSIP and null
> |> | packets until they reach 19.3Mbps (assuming they don't multicast).
> |>
> |> Given that the typical modern digital ready TV station is wired with SDI
> |> going around, and SDI carries uncompressed video/audio digitally, and the
> |> switchers are processing it in that form, it would seem that the MPEG-2
> |> would normally be decided and re-encoded.
> |
> | Not for Fox. Maybe you should read a bit more at AVS Forum, where the Fox
> | engineers hang out.
>
> If you think AVS Forum is so great, why is it you hang out here? Could
> it be that you'd get kicked out of AVS Forum if you behaved there like
> you do here, and this is the only place for you to "let it hang out"?
>

What makes you think that Jeff doesn't behave exactly the same way
there? It's pretty clear you haven't spent much time researching on
avsforum.

Matthew

--
Thermodynamics and/or Golf for dummies: There is a game
You can't win
You can't break even
You can't get out of the game
Anonymous
August 29, 2005 12:53:38 AM

Archived from groups: sci.engr.television.advanced,alt.video.digital-tv (More info?)

In sci.engr.television.advanced Jeff Rife <wevsr@nabs.net> wrote:
| (phil-news-nospam@ipal.net) wrote in alt.video.digital-tv:
|> | Yes, it's in the ATSC specs, which you claim to have read.
|>
|> I have not gone over it with a fine tooth comb, yet.
|
| In other words, you haven't really read it at all.

I skimmed it all. I'm not trying to remember every detail in every chart
or data structure, yet. In fact, I don't ever intent to memorize it. At
the time I need to (e.g. writing computer code), I will consult it.


|> As soon as I find
|> a means to demodulate an RF signal into a bitstream, and modulate a
|> bistream into an RF signal, then I plan to deal with all the details
|> so I can implement some ATSC manipulation software.
|
| Maybe you should let people that know what they are doing do the work.
| There's lots of open-source code available.

If such projects exist, I dare you to tell me what devices can be
attached to a computer that gets the demodulated ATSC bit stream, and
can also (separate device OK) output a bit stream that gets modulated
to an ATSC RF channel.

--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
Anonymous
August 29, 2005 3:05:32 AM

Archived from groups: sci.engr.television.advanced,alt.video.digital-tv (More info?)

Matthew L. Martin (nothere@notnow.never) wrote in alt.video.digital-tv:
> What makes you think that Jeff doesn't behave exactly the same way
> there?

Remember Vidguy? He's the same at AVS Forum as he was here. Luckily, there
are a lot of other people who actually have open minds and want to do the
research.

The truly depressing thing is I'd take Vidguy over Phil any day, since at
least Vidguy had several HDTVs and STBs.

--
Jeff Rife |
| "He chose...poorly."
|
| -- Grail Knight, "Indiana Jones and the Last Crusade"
Anonymous
August 29, 2005 3:24:02 AM

Archived from groups: sci.engr.television.advanced,alt.video.digital-tv (More info?)

(phil-news-nospam@ipal.net) wrote in alt.video.digital-tv:
> | Maybe you should let people that know what they are doing do the work.
> | There's lots of open-source code available.
>
> If such projects exist, I dare you to tell me what devices can be
> attached to a computer that gets the demodulated ATSC bit stream,

Generally nothing, since the de-modulation is done inside the computer
through hardware...various PCI cards exist for this. You can even do it
100% in software with raw RF input and GNU Radio (since people have done
it).

But, you can also do it with any ATSC tuner that has FireWire output. The
data over FireWire is the ATSC bitstream without any FEC packets, but it
still includes PSIP and other "in band" non-audio/video data.

Once you have that, you can manipulate it with any code that groks
transport streams.

> and
> can also (separate device OK) output a bit stream that gets modulated
> to an ATSC RF channel.

There's no need to do this, so nobody has ever written any code. You'd
need custom hardware to do the 8VSB modulation, and it's generally pretty
expensive. But, if you find some, I can guarantee you can just feed it a
transport stream via FireWire and get what you want.

It's far easier to send the transport stream across 100Mbps Ethernet to a
device in another room (since that the goal you have stated before), and
just let that device decode the transport stream for display. The
advantages are huge:

- no shielding of cable necessary
- one wire can carry multiple streams with no real effort and no special
hardware (with my switched 1000Mbps system, I don't notice if 4 or 5
streams are bouncing around the wires...I'm sure I could do more, but
there's only so many rooms in the house)
- essentially infinite distance possible by using Ethernet switches as
repeaters
- multicasting is easy (within a home network, anyway)
- you could use the same protocol to send the stream over the Internet
(assuming you have enough bandwidth)

--
Jeff Rife | copy protection: n. A class of methods for
| preventing incompetent pirates from stealing
| software and legitimate customers from using it.
| Considered silly.
| -- Jargon File version 4.4.6
!