On Mon, Apr 04, 2005 at 02:03:09AM +0300, Rantanen Teemu wrote:
Klaus Schmidinger wrote:
Well, I can't quote a standard here, but I would say that plain common sense dictates that the PIDs should be set correctly (including language codes) _before_ a broadcast starts.
I wonder whether this excerpt from iso13818-1 is of any significance to this discussion:
Annex C.5 What is a program?
The concept of a program has a precise definition within this standard. For a Transport stream the time base is defined by the PCR. This effectively creates a virtual channel within the Transport Stream.
Note that this is not the same definition as is commonly used in broadcasting, where a "program" is a collection of elementary streams not only with a common time base, but also with a common start and end time. A series of "broadcaster programs" (referred to in this annex as events) can be transmitted sequentially in a transport stream using the same program_number to create a "broadcasting conventional" TV channel (sometimes called a service).
While this excerpt creates even more confusion (it can be interpreted either way), it seems that 13818-1 tries to clarify this topic. Since I have only a copy of an old (1994) draft, I can not check what the wording in the final paper is. Can anyone check the final spec (or even better: post a URL where the final spec can be downloaded ;)
After all, they're not likely to change right in the middle of a movie, are they?
Oh, I would not be very surprised. Lots of movies use multiple languages.
I wouldn't expect them to change in the middle of a movie, but some documentaries may have interviews and actual film footage in different languages.
About two weeks ago there was a report about Einstein where repeatedly the reporter started a sentence in german and interviewed persons fullfilled the sentence in english. I have no clue whether the PIDs changed for that specific report.
But then again, most broadcasters don't even get the running status in sync with the actual broadcasts, so how can we expect the PIDs to be set at the right time. Seems to me like there are a few monkeys sitting at a switchboard, plugging in cables randomly and every once in a while hitting the right spot ;-) I always thought that in today's digital playout centers things would be completely computerized...
Klaus, are you that much convinced that the broadcasters are the problem that you start blaming on them?
See, there might be zillions of other reasons that could lead to the described effect. Just to name one (possible) reason: the code that constructs tables from sections might loose sections now-and-then. Such a bug would lead to the effect described here:
When PMT_SCAN_TIMEOUT is set to the default 10 seconds there is a delay between event change and a PID change, as Lauri Tischler noticed.
I changed the PMT_SCAN_TIMEOUT to 1. Now the delay is gone, and event change and possible PID change happen at the same second (based on syslog).
BTW: Why is PMT_SCAN_TIMEOUT needed at all? I have not looked at the actual code, but the existence of such a timeout looks to me as if someone once noticed a problem with table reconstruction code and decided to cure the symptomps (construct table even when sections are still missing, based on a timeout) instead of curing the real cause (find the reason why sections get lost). Such a "cure" would be very consistent with the effect described above.
Just my 0.02eur. No pun intended.