Re: subtitle and transport stream patches

Thanks for your commitment :-)

 > This patch corrects the very poor synchronization between transport
 > streams and external subtitles. It is all very well using bit rate to
 > estimate a seek amount but it is not a good idea to feed such a coarse
 > estimate into a subtitle stream which is trying to synchronize its output
 > when there already exists a highly accurate pts.

Not applied because it breaks many TV streams that jump midway through.
This is the reason for that bitrate estimation thing.
Made some compromise patch instead, try that one.

 > This patch corrects the disconnect between the independent
 > subtitle stream and the selection of the subtitle channel.
 > It also undoes the hack which would mask the problem by
 > disabling the entire osd.

 > Unfortunately there is also a gap between the creation of the
 > subtitle stream and it becoming a slaved stream so there is an
 > additional re-invocation of the subtitle channel selection (this
 > becomes evident when the -u command-line option is used).

Applied for now, please test for possible regressions.

 > Given the correction for control of the slaved subtitle stream
 > it becomes necessary for text subtitles to properly implement
 > channel matching. In particular, the subtitle stream must continue
 > to synchronize with the video decoder and therefore must pause
 > properly even if the subtitle channel does not currently match
 > what the user wants.

Applied.

 > The problem with a construct such as 'sscanf(s, "%d.%d", &a1, &a2)'
 > is that it can produce erroneous results. For example, given input
 > such as "2.1" or "2.01" or "2.001" then a2 will always be 1. So one
 > cannot automatically assume it mean 1/10 or 1/100 or 1/1000.
 > This is the very reason why sscanf has a "%f" conversion.

Applied.

Torsten