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.
--
No software patents!
-- Josef Wolf -- jw@xxxxxxxxxxxxx --
