ISDB-T PID Planning

More channels means more money for the techs, right?
Post Reply
spellkaw
Posts: 6
Joined: Mon Oct 10, 2016 12:36 am

ISDB-T PID Planning

Post by spellkaw » Mon Oct 10, 2016 1:44 am

Hi,

I was wonderng if someone could help me on my problem re ISDB-T planning.
My first question, are there any rules applied in assigning Packet ID? for example how do we assign Network ID, Servce ID, PMT, Video PID, Audio PID, PCR PID etc.?
My second question, what is a Virtual Channel and how can I assign it? because nowadays, I noticed there are many brandnew TV with built-in ISDBT receiver. How did it determine the channe of a particular TV station? For example, if the display channel is 32.16, 32.17, 32.18 etc. how can we modify or change this channel into let say, 3.01, 3.02, 3.03? this is something that confuses me for several weeks now and I really want to know the answer.

Thank you in advance.

User avatar
PID_Stop
Posts: 467
Joined: Thu Apr 01, 2010 11:58 am
Location: Syracuse, New York
Contact:

Re: ISDB-T PID Planning

Post by PID_Stop » Mon Oct 10, 2016 7:51 am

Right up front, you should know that I work in the United States and know very little about ISDB-T per se -- but my understanding is that it uses the same sort of PID structure as ATSC and other DVB systems, so this should give you a general idea of what to look for.

PIDs -- Packet Identifiers -- are simply an address attached to each data packet that tells processing and receiving equipment about the purpose of that particular chunk of data. PIDs can range rumerically from 0 (decimal) to 8191 (decimal); some people prefer to think of them in hexadecimal, where the range is expressed as 0h to 1FFFh. Using hexadecimal makes a certain sense, because PIDs tend to be organized in blocks of sixteen.

A few PIDs are assigned for specific purposes and never change; others are defined by the service or services being transmitted. The most important fixed PID is the Program Association Table or PAT, which is PID 0 (0h). This is the overall directory for your transport stream, and it tells you how many program services it contains and on which PID each starts. If you are transmitting four services, your PAT will contain four pointers to the start of each service's block of sixteen PIDs.

One might think that services should start with #1, and continue with #2, #3, #4, and so on... but no. In the ATSC system (and I suspect this has become typical elsewhere), the first program service is #3, followed by #4, #5, and up. There are two reasons for this: the first is that the service ID (which is what these numbers are really called) is the first part of the PID numbers assigned to that service, as shown in hexadecimal. Service #3 uses PIDs from 30h through 3Fh (that's 48 through 63 in decimal); service #4 uses PIDs from 40h through 4Fh (64 through 79 in decimal). Service 16 (as in your example of 32.16) would start at PID 160h (352 decimal) and run through 16Fh (367 decimal). Now you see why many people like to use hexadecimal, even though it's not as familiar! So... if you are seeing programs expressed with fairly high numbers like 32.16, 32.17, and 32.18, it's very likely that you are seeing the actual service numbers.

The other reason systems like ATSC begin with service 3 is that the range of lower numbered PIDs is reserved for special purposes. (This has changed over time... when we began transmitting ATSC, most stations began with service ID 2... the standard changed, so we had to annoy a number of our viewers by changing our program mapping and forcing them to rescan their sets. So typically, in a system like ATSC, the service numbers can range from 3 (with PIDs from 30h to 3fh) up to 510 (1FEh to 1FEFh).

So... we said that our sample transport stream contained four program services: 3, 4, 5, and 6. Our PAT at PID 0h will say that there are four services, and will point to PIDs 30h, 40h, 50h, and 60h. All four of these PIDs are a second kind of table called the PMT, or Program Map Table, that tells the receiver what kinds of content make up that program. For instance, program service 3 might include one video and two audio components (called "elementary streams"); the PMT points to each one, with enough supporting information to tell the receiver how to process each. So the PIDs for this service 3 would contain:
  • PID 30h -- PMT (Program Map Table) for service 3
    PID 31h -- Video for service 3
    PID 34h -- Main program audio for service 3
    PID 35h -- Secondary audio for service 3 (another language, for example)
You would have a similar group for the other services. In ATSC, it's common to find the video PID one count higher than the PMT's PID, and for the audio to begin four counts higher than the PMT. It is possible to put the video and audio in other places within the group of 16 PIDs -- the PMT will point to them wherever they are -- but it's a good idea to observe normal conventions, since not all consumer equipment handles unusual cases gracefully.

We've gotten from PID 0h, the PAT, through the PMTs for each program service, which finally point us to the video and audio PIDs we really want. There are just a handful of other special-case PIDs that you should know:

PID 1FFFh (8191 decimal) is called a null packet; it doesn't contain any information, and is tossed in to fill space if no other data is waiting to be transmitted. This keeps the data running at a uniform rate; think of an escalator at the department store, where a new step pops up every second or so. A step might hold a man, a woman, a child, or it might have a shopping bag sitting on it... or there might be nothing at all. Even if there's nobody around to ride the escalator, the empty steps keep popping up... and in the same way, otherwise unused packets are filled with nulls, with PID 1FFFh. The receiver see that PID and knows to ignore the packet.

The other special case packet (in the ATSC system) lives at PID 1FFBh, and is called PSIP -- Program and System Information Protocol. This contains a handful of tables that mostly make life easier for the viewer, including the virtual channel table and program guide information. You were asking about the virtual channel table (VCT) originally; think of it as an alias for each program service. Your station might be known as channel 3 in the community, but you might have been assigned some other physical channel for your digital signal -- 32, maybe. Your transport stream might contain services 16, 17. and 18... but 32.16, 32.17, and 32.18 aren't very easy for your viewers to remember. So you set up the virtual channel table to rename them... and 32.16 now shows up as 3.1 for your viewers, 32.17 becomes 3.2, and 32.18 becomes 3.3.

You assign PID numbers for your elementary streams -- that is the video and audio for each service -- in each service's encoder. Virtual channel numbers, and other supporting data, are usually set either in the multiplexer (which combines all of the services and supporting data into a single data stream), or in the PSIP generator (which creates supporting data like virtual channel tables, program guides, and so on).

As I said, your country's standard will have its own quirks... but it should look something very much like this. Hopefully, this will give you enough of a head start to make sense of what's going on in your area.

Regards,

Jeff

spellkaw
Posts: 6
Joined: Mon Oct 10, 2016 12:36 am

Re: ISDB-T PID Planning

Post by spellkaw » Tue Oct 18, 2016 10:06 pm

Dear Jeff,
First, I need to thank you for your long yet very informative reply.
Though, I can’t fully grasp the whole idea, somehow it helped me understand basic principles.
Anyway, if you wouldn’t mind, can I ask some follow up questions to you?
Here’s the deal, I am planning to have another transport stream and come up with the following:
excel.jpg
My questions are:
1. Is my table correct? i'm afraid its incorrect.
2. Are network id, original network id, and TS id are assigned by company or government? in case we don't have such assignment yet, can I assume whatever values?
3. My goal is to have ISDB-T receiver pickup the channel as 3.01, 3.02, 3.03 and 3.04. I stumbled to some research article and it says service id dictates this, that's why i changed my service id. But I have no idea how to change the PMT, Video/Audio PID. I intend to use embedded PCR that is why i have the same PID with video.
4. How can I really achieved 3.01, 3.02, 3.03 and 3.04, I have no idea where the virtual channel is being configured. is it in the encoder or multiplexer?

Thanks again.
Attachments
image3.JPG
Image2.jpg

w9wi
Posts: 804
Joined: Tue Feb 05, 2008 11:40 am
Location: Pleasant View, Tennessee
Contact:

Re: ISDB-T PID Planning

Post by w9wi » Wed Oct 19, 2016 4:28 am

I think when Jeff refers to "PSIP", in countries where ISDB-T is used, it's called a "LCN", "Logical Channel Number".

I should let Jeff answer the rest of your questions but I won't:)
My questions are:
1. Is my table correct? i'm afraid its incorrect.
I would think as long as the PAT and PMTs contain the same information, your table is correct.
2. Are network id, original network id, and TS id are assigned by company or government? in case we don't have such assignment yet, can I assume whatever values?
In the USA, the TS id (usually written "TSID") is assigned by the government. It's important that it be unique for each station in the same service area. In the USA, TSIDs are unique nationwide. (the station I work for uses TSID 0x0AA1, and it is the ONLY station anywhere in North America using that TSID) I don't think I'd use TSID 1 as if your government isn't assigning TSIDs, some other station will probably also select 1!
3. My goal is to have ISDB-T receiver pickup the channel as 3.01, 3.02, 3.03 and 3.04. I stumbled to some research article and it says service id dictates this, that's why i changed my service id. But I have no idea how to change the PMT, Video/Audio PID. I intend to use embedded PCR that is why i have the same PID with video.
4. How can I really achieved 3.01, 3.02, 3.03 and 3.04, I have no idea where the virtual channel is being configured. is it in the encoder or multiplexer?
It's probably possible to configure it in the multiplexer.

In the USA we usually use an external computer known as a "PSIP generator". This allows some of the PSIP tables to be "dynamic" -- to change over time. We do that to provide an EPG. (Electronic Program Guide, also known in the USA as "ETT" and "EIT" but I don't think that terminology is used in other countries) The PSIP generator feeds the multiplexer as if it were an additional encoder.
--
Doug Smith W9WI
Pleasant View, TN EM66

User avatar
PID_Stop
Posts: 467
Joined: Thu Apr 01, 2010 11:58 am
Location: Syracuse, New York
Contact:

Re: ISDB-T PID Planning

Post by PID_Stop » Wed Oct 19, 2016 7:33 am

Doug is spot on, and saved me a lot of typing! :)

If you have a number of separate encoders, then your multiplexer is where your service numbers are typically enforced, because that's where the PAT, which describes the entire group of services, is created. But your PSIP generator, if it's a standalone computer feeding the multiplexer, must be configured to reflect the same settings as your encoders and multiplexer.

There is a somewhat different approach that you might consider, that we switched over to this early this year. All four of our encoders and the multiplexer are combined within one device (we're using a Harmonic Electra 9200); you don't have to worry about hooking up a bunch of separate devices. Better still, this allows the encoders to interact with each other so that they share the available bitrate more efficiently: if one program has a lot of random motion (sporting events, especially), it can automatically borrow bandwidth from other encoders that don't need so much at that moment. This is generally called statistical multiplexing.

In our case, the Harmonic box is doing only static PSIP, creating only the bare essential tables for a receiver to recognize the program services, but not including stuff like electronic program guides. We feed the Harmonic's output through a Nevion CP505A processor, which is a nifty box that automatically downloads the program guide information and inserts that and other PSIP tables into the program stream automatically. Much simpler and more reliable than having a Windows computer running PSIP software that occasionally crashes or does unannounced Windows updates. This particular box is specific to ATSC, but I imagine that being a Norwegian company with offices worldwide, they have a device that would be appropriate to processing your transmission standards.

Regards,

Jeff

spellkaw
Posts: 6
Joined: Mon Oct 10, 2016 12:36 am

Re: ISDB-T PID Planning

Post by spellkaw » Wed Oct 19, 2016 11:39 pm

Hi,

Thank you so much for the information Doug and Jeff. :D
I realized now that we need to be consistent and unique as possible in terms of planning our PIDs.
Actually, we will be using a Harmonic Prostream 9100 multiplexer but we have separate Electra X2 encoders.
Since you've mentioned statmux, is their a way we can protect or prioritize our main channel within statmux group? let's say whatever happens, this particular main channel will receive certain bitrate to prevent pixellation (macroblocking) or whatever picture impairments.
Another question if I may, where did set top box gets its time display? is it in the multiplexer server clock system, or designed by the manufacturer? or can we hook up to a network time (NTP) server for consistent timing?

Sorry I have a lot of queries.
Thanks.

spellkaw
Posts: 6
Joined: Mon Oct 10, 2016 12:36 am

Re: ISDB-T PID Planning

Post by spellkaw » Thu Jan 19, 2017 7:30 pm

Hello,

it's me again, we are now on commissioning of our system.
Problem is, its still unclear how we can identify our service id.

We use 12545 (decimal) network ID, and 8800 (decimal) original network id.
I read somewhere that service Id is a combination of network id, service type and service number.
Could someone explain to me how?

w9wi
Posts: 804
Joined: Tue Feb 05, 2008 11:40 am
Location: Pleasant View, Tennessee
Contact:

Re: ISDB-T PID Planning

Post by w9wi » Sun Jan 29, 2017 8:56 am

spellkaw wrote:
Thu Jan 19, 2017 7:30 pm
Hello,

it's me again, we are now on commissioning of our system.
Problem is, its still unclear how we can identify our service id.

We use 12545 (decimal) network ID, and 8800 (decimal) original network id.
I read somewhere that service Id is a combination of network id, service type and service number.
Could someone explain to me how?
I think these items are specific to ISDB-T. We don't have an original network ID in ATSC and I think our definition of "service ID" is different.

I'm not familiar with the Prostream but I'm certain there is a way of prioritizing a main program in the mux.

In my experience in the USA, different set-top boxes and TV sets get their time display from different places..... In our case the PSIP generator computer provides the STT -- System Time Table -- which is used for the time display on many TV sets. Yes, we've connected that computer to a NTP server.

At least in the ATSC standard, there is a provision for telling the TV receiver whether you're on standard time or summer time. We have found that some models of TV set (notably older Samsung TVs) ignore this setting. If you find some viewers are displaying a time that's wrong by an hour, the problem may be their receiver.
--
Doug Smith W9WI
Pleasant View, TN EM66

User avatar
KPJL FM
Posts: 532
Joined: Fri Nov 16, 2007 9:28 am
Location: planet Earth, 3rd rock from sun

Re: ISDB-T PID Planning

Post by KPJL FM » Mon Jan 30, 2017 8:23 am

I have to reset my Samsung 40" twice a year for Daylight time.
Trim to fit, paint to match, tune for minimum smoke.

spellkaw
Posts: 6
Joined: Mon Oct 10, 2016 12:36 am

Re: ISDB-T PID Planning

Post by spellkaw » Mon Feb 06, 2017 10:09 pm

w9wi wrote:
Sun Jan 29, 2017 8:56 am
spellkaw wrote:
Thu Jan 19, 2017 7:30 pm
Hello,

it's me again, we are now on commissioning of our system.
Problem is, its still unclear how we can identify our service id.

We use 12545 (decimal) network ID, and 8800 (decimal) original network id.
I read somewhere that service Id is a combination of network id, service type and service number.
Could someone explain to me how?
I think these items are specific to ISDB-T. We don't have an original network ID in ATSC and I think our definition of "service ID" is different.

I'm not familiar with the Prostream but I'm certain there is a way of prioritizing a main program in the mux.

In my experience in the USA, different set-top boxes and TV sets get their time display from different places..... In our case the PSIP generator computer provides the STT -- System Time Table -- which is used for the time display on many TV sets. Yes, we've connected that computer to a NTP server.

At least in the ATSC standard, there is a provision for telling the TV receiver whether you're on standard time or summer time. We have found that some models of TV set (notably older Samsung TVs) ignore this setting. If you find some viewers are displaying a time that's wrong by an hour, the problem may be their receiver.
Thank you so much Mr. Doug Smith. Appreciated your response.
I'm a newbie to this field and I wanted to improve my skills and understanding. This site has helped me gain information to the topics I am so confused about. Again thank you so much,

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest