(transplanted from 4988e864d1a9db84756668ea33a9f6860ded879e)

--HG--
extra : transplant_source : I%88%E8d%D1%A9%DB%84ufh%EA3%A9%F6%86%0D%ED%87%9E

supply decoded frames.
There can still be scheduling delays which may let the number of
frames ready for displaying to drop below frame drop limit just
for a short period of time.
Therefore the changes remember that the decoder should have been
asked to drop some frames but do not actually have the decoder to
drop some frames. When the situation has improved at the next time
when the check is performed, the remembered frame drop is canceled
or otherwise (when the number of frames is still below frame drop
limit) executed.
(transplanted from b016e80a8206a56ba3996021bacff88b8ba44621)

--HG--
extra : transplant_source : %B0%16%E8%0A%82%06%A5k%A3%99%60%21%BA%CF%F8%8B%8B%A4F%21

allocated frames.
The current code uses a hard coded frame drop limit of 3 and
doesn't adhere to it's documentation when testing whether frames
shall be dropped. As a result frame drop limit is actually 4,
which means that the decoder is asked to drop some frames when
the number of frames waiting for displaying is less then 4.
Consider a video out device like xxmc which only supplies 8
frames. For MPEG2 decoding, two frames will be used by the
decoder (for the current frame and the forward reference frame)
and two further frames will be used in the video out loop (the
current and the previous frame) so that at any given time (under
perfect conditions) there will be 4 frames waiting to be displayed.
But when there are delays in scheduling, it might happen that
there are only 3 frames ready for displaying and thus will result
in asking the decoder to drop frames.
The changes therefore determine the maximum frame drop limit in
dependence of the number of allocated frames and make the
detection work like documented. In the above scenario, the maximum
number actually used for frame drop limit will then be 2 which
allows to compensate some scheduling delays without causing the
decoder to drop frames.
(transplanted from 2936fd493eafe3f176f2e791340167513b4e8048)

--HG--
extra : transplant_source : %296%FDI%3E%AF%E3%F1v%F2%E7%914%01gQ%3BN%80H

available.
Usually it's a good idea to avoid reallocating frames especially
when a deinterlacer needs a different format than the decoder, as
this would then happen all the time.
But when there is only a limited number of frames available, then
even a single frame which is not scheduled at frame allocation may
let the number of frames ready for displaying drop below frame
drop limit and thus resulting in unnecessary frame drops.
(transplanted from 235058555243755d3aebff03d898f1a5b94ff95e)

--HG--
extra : transplant_source : %23PXURCu%5D%3A%EB%FF%03%D8%98%F1%A5%B9O%F9%5E

drops.
When a video out device provides only a little number of video
frames, the video decoder should be scheduled immediately to
provide a decoded frame as soon as possible. Otherwise, the
number of available frames for displaying may go below frame
drop limit and thus resulting in unnecessary frame drops.
(transplanted from 33960e92decd90e6010d904476f9d45b1173153a)

--HG--
extra : transplant_source : 3%96%0E%92%DE%CD%90%E6%01%0D%90Dv%F9%D4%5B%11s%15%3A

I watch a lot of movies with subtitles and I need "vobsub subtitles"
work in xine, then I decide to write this patch.
It may support SSA tags for all text subtiles (ssa, ass, srt, ...)

This patch :

1. Remove all SSA tags from stream (they are ugly : {\a6})
2. Handle some of them (b, i, a, an, pos). The other ones control
colours, shadow, animation, ... I can't make them work in an easy way.
3. Correct wrap algorithm which have minors bugs (we can see them only
with SSA patch...)


Modified files :

libsputext/demux_sputext.c
just remove unneeded code (which remove some of SSA-tags)

libsputext/xine_sputext_decoder.c
the main modified file.

video_out/video_out_xshm.c
video_out/video_out_xv.c
xine-engine/video_out.h
get video output (position and size). See below.


1.
Removing SSA tags is done in ogm_render_line_internal() like for
html-like tags. (this was done in the previous version of xine)


2.
b(bold) and i(italic) are implemented like html-ones, in
ogm_render_line_internal().

The other tags this patch support are :
aX       : alignment in SSA-code
anX      : alignment in numpad code
pos(X,Y) : position, depend on alignment

For those ones, I need in first a full-screen OSD, not a five lines one.
Then, I need to remember where the last subtitle was drawn, in order to
erase it. At last, I need a translation function to convert subtitle
coordinates in screen coordinates.
For this last point, I first write a full-screen translation (don't care
about blacks borders), but it's not really good: the 'pos' tag is
sometime used to point out something in the video. (Moreover, ASS spec
say we have to draw subtitle on the video)
For doing this, I need the real video output size and position, which
are only know by the video output driver! Then I had 4 VO properties
(in xine-engine/video_out.h) for video driver could give us those
informations.
I implement it only in xshm and xv drivers (I can't test other ones).
If video driver can't give us those informations, the patch fallback in
a full-screen translation.


3.
there was 3 problem with the wrap algorithm :
1. It was in double: exactly the same, twice. Look like a merge problem.
I remove one and all work fine.
2. It want to cut string in equivalent display length but it cut it in
equivalent byte length. In most cases, this is the same, but if we have
UTF-8 chars or long SSA-tags (which will not be displayed) the result is
strange.
3. If we have a too-long part (in bytes) of the string without spaces
(bad subtitle file or long SSA-code), the algorithm don't know what to
do. (this case is not handled)

I re-write the wrap algorithm to correct those problems. Note that my
version is slower than previous one : working with bytes is really
faster than computing text-length. Maybe I should had to propose an
other patch for this part...

Some instances of "key colour" remain; ffmpeg is unmodified.

This change has caused two strings with two translations to collide (the
strings have become identical since some instances already used "colour").
I have therefore arbitrarily dropped the first of the differing translations,
the one for the string at src/video_out/video_out_directfb.c:1365.