Hey, this kinda reminds me of earlier days on AVSforum ... I expect we might be boring most everyone else reading this thread, though, and this sort of thing does tend to cut down on needed sleep ...
but what the heck ...
Originally Posted by mrvideo
Go back and look again at an ATSC stream with TSReader. Hopefully that is the program you use.
TSreader is one(excellent) tool I use quite often ...
From TSReader website http://www.coolstf.com/tsreader/index.html
Originally Posted by TSreader Info
TSReader is a transport stream analyzer, decoder, recorder and stream manipulator for MPEG-2 systems. It supports DVB, ATSC and Digicipher® II extensions to the base MPEG-2 specification. TSReader gives the user the "big picture" overview of what's being carried inside MPEG-2 transport streams
and can be very useful for finding errors or inefficiencies. If you're not familiar with MPEG-2 transport streams
, we suggest reading our web page about North American MPEG-2 Information as this covers this subject in depth.
PSIP data is NOT, I repeat NOT, embedded in the MPEG-2 video stream.
Of course not, I didn't say it was.
The PSIP streams/tables are muxed with MPEG2 Video and AC-3 audio streams, and MPEG2 PSI info such as is contained in PAT/PMT's, and anything else they might be sending - datacast streams, Null packet stream/etc, h.264 video streams such as when USDTV were using those, whatever --- into a ATSC compliant MPEG2 Transport stream, or "ATSC mux" if that's what you want to call it. Note You'll also find seperate streams for the EIT's (PSIP Event information tables - detailed program info can be here).
The PSIP data stream is its own stream within the ATSC mux.
Call it "ATSC Mux" or MPEG2 Transport stream, either way the PSIP tables and data Streams(plural) just as I said are all encapsulated within it, just as any other stream(including MPEG2 video/AC3 audio streams) contained within the TS, just like I said in my previous message.
The ATSC definition of the mux has workings that is very similiar to DVB.
That's mostly because both use MPEG2 Transport Streams.
Really recommend/suggest you download and study the various ATSC documents, especially the A/53 and A/65 documents.
Here are a couple of links to get you started :http://www.atsc.org/standards.htmlhttp://www.atsc.org/standards/a53.html
any PIDs that are data streams ....
PIDs are packet identifers not "data streams" ..... I would define them as idenfiying which elementary stream a packet "belongs to", but Here's ATSC's current "offical" definition from one of the ATSC A 53 documents :
packet identifier (PID) – A unique integer value used to associate elementary streams of a
program in a single or multi-program transport stream.
TSreader simply lists streams (such as in the "tree List" or bandwidth charts/pid lists) by the PID's "associated" with them .....
So, video, audio and PSIP data are all separately placed into the "mux" that is broadcast via the 8VSB (also incorrectly named) OTA carriers.
They(and any other streams sent within the TS - Datacast streams for instance) are seperate streams with unique PID's(packet Identifiers). for each stream.
8VSB is just another, shorter abbreviation of 8T-VSB. Either abbreviation refers to the signal modulation used for Over the air ATSC DTV, which is (unabbreviated) : Trellis-coded 8-level vestigal sideband.
There's a pretty good explanation of 8VSB(8T-VSB if you like) in ATSC docs, and here :http://www.broadcast.net/~sbe1/8vsb/8vsb.htm
16VSB is also "spec'd" in ATSC standards, but does not use the trellis coding (and can be used for digital cable applications, but isn't used in U.S. for digital cable, instead QAM256 is used), but is probably not widely known (or widely used, if it is used at all for any real world application), which I would guess is probably why we more commonly see the 8VSB abbreviation used rather than 8T-VSB ....
Hell, D* can't even get the closed captioning right.
Along those lines, It has gotten better, but I've noticed many broadcasters seem to have some "issues" implementing the EIA-708 (digital) captions, either at all, or properly ... Note: BTW, EIA-708 captions are implemented as User data that is data which is contained within elementary MPEG2 Video stream ... So is AFD data (although there is also AFD descriptor, I can't remember where it "goes", If I recall correctly without digging it up, I think it goes in PMT and/or VCT ...)
A transport stream is a transport stream.
No. From ATSC A53 part 1 Part 3 – Service Multiplex and Transport Subsystem
Characteristics (A/53, Part 3:2007), section 6.1 :
Originally Posted by ATSC A53
6.1 MPEG-2 Systems Standard
The transport subsystem shall comply with the transport stream definition of the MPEG-2 Systems standard as specified in ISO/IEC 13818-1  and shall be further constrained as specified herein.
As for PSIP within the TS :
Originally Posted by ATSC A53
6.6 Services and Features
6.6.1 System Information and Program Guide Transport Streams shall include system information and program guide data formatted according to the structure and syntax described in ATSC Standard A/65 “Program and System Information Protocol for Terrestrial Broadcast and Cable”  ....System information and program guide data shall be conveyed in Transport Stream packets of PID 0x1FFB, which shall be reserved exclusively for this purpose. System information provides data necessary for navigation among
digital service offerings. The program guide database allows a receiver to build an on-screen grid of program information for the various services that may be available.
220.127.116.11 SI base_PID for TS-M
System information and program guide data shall be conveyed in Transport Stream packets of PID 0x1FFB, which shall be reserved exclusively within TS-R (Figure 9.2) for this purpose.
18.104.22.168 SI base_PID for TS-E
System information and program guide data shall be conveyed in TS-E packets of PID 0x1FF9, which shall be reserved exclusively within TS-R (Figure 9.2) for this purpose.
22.214.171.124 System Information and Program Guide STD Model The STD model for program guide and system information is specified in ATSC Standard A/65
Way too much info in this document to include much of it here, so I'm sure you'll want to utilize the entire document, available here :http://www.atsc.org/standards/a_53-Part-3-2007.pdf
I also have a more detailed document describing MPEG2 Transport streams and how they work in great detail -- I think I'd gotten that off ATSC site as well several years ago, but can't dig it up now (I know I have it archived on a DVDR or CDR somewhere, but it's getting too late for me to dig it up at present) ..
Oh, BTW, the a53 "guide to DTV standard" document is split up into various parts, other sections of it which delve into other aspects of ATSC "DTV standard" (such as signal modulation - 8VSB(or 8T-VSB if you like) and 16VSB included) can also be downloaded from ATSC site as well as more detailed info on each "specific" ATSC standard (a65/PSIP for instance) ...
The video could be H.264
Yes. As just one reference I quickly dug up for MPEG-4, which would include H.264 video(MPEG-4 AVC/x.264/etc),
From a document from "INTERNATIONAL ORGANISATION FOR STANDARDISATIONORGANISATION INTERNATIONALE DE NORMALISATION ISO/IEC JTC1/SC29/WG11 CODING OF MOVING PICTURES AND AUDIO" available here :http://www.chiariglione.org/MPEG/STA...G-4/MPEG-4.HTM
Originally Posted by section 3.1 of doc at link above
In principle, MPEG-4 does not define transport layers. In a number of cases, adaptation to a specific existing transport layer has been defined:Transport over MPEG-2 Transport Stream
(this is an amendment to MPEG-2 Systems)
Transport over IP (In cooperation with IETF, the Internet Engineering Task Force)
Originally Posted by MrVideo
Here's one for ya... what to you call a transport stream that contains 4 H.264 video streams and one MPEG-2 video stream?
If it's ISO/IEC 13818-1  compliant I'd probably call it a MPEG2 Transport Stream
Actually, you give it a TSID value and they tell you who it is assigned to. Even then they don't give the call letters, just the channel numbers and the location. I saw no way to input a call sign and get back that station's TSID.
Yeah, you got me there ... It is the best thing for "TSID lookup" I've ran across so far however, as I haven't found any list/spreadsheet database with the station info*(callsign)+TSID info included ...
It's come in handy for me, especially on one occasion when (verified via TSreader) one local station was sending incorrect TSID (they were sending the analog station's TSID on the digitial - Yes, analog stations have been assigned TSID's as well), This caused problems with EPG for Some E* receivers and new firmware at the time which as I described before was using the "correct" TSID info, which didn't "match" with the incorrect TSID info received via the TS from the station, OTA ... A quick note to the station's engineers and they got on it fairly quickly .....
Originally Posted by MrVideo
They even call it a MPEG-2 transposrt stream.
They, me and up until now, every thing I've ever read about them or anyone else I've ever talked to about them