| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
It happend that the previously shown frame was still on screen
while the decoder reused it already and the result was a mixed
picture on screen.
Protection is easy: just keep a reference to previously shown
frame and it cannot be reused by the decoder until a frame
duration has passed which should be sufficient to see the
current frame on screen.
Such referencing has already been implemented although it was
not used for deinterlacing. Therefore it had been disabled to
get an additional frame for decoding in coping with dropped
frames.
The change reenables referencing the previously shown frame.
|
|
While disabling for progressive frames was ment to improve DVD
playback, it turned out that many TV broadcasters set this flag
too, although their content is not progressive.
Adding an option allows the user now to enable this feature when
the watched streams make correct use of this flag.
Another option allows to disable bob deinterlacing when a scaled
OSD is on screen. As bobbing adds some noise to horizontal lines
the OSD quality might be improved by enabling this option.
|
|
When xine-ui switches to fullscreen mode or back again, it will
change the drawable by sending XINE_GUI_SEND_DRAWABLE_CHANGED.
This may lead to BadDrawable X Errors when the video out thread
is still using the old drawable for drawing.
The changes below block XINE_GUI_SEND_DRAWABLE_CHANGED from
changing the drawable while it is used for drawing.
|
|
|
|
|
|
|
|
|
|
|
|
xine_spudvb_decoder.c has hardcoded frame size (720x576).
While this is fine for most dvb channels, some channels have smaller frame
size (e.g. 544x576) but the dvb subs bitmaps are however still 720 width.
In such case, some right aligned subs appear truncated.
This patch adds a (very basic) function to downscale subs to fit frame width.
|
|
|
|
|
|
|
|
Le dimanche 24 décembre 2006 13:38, Miguel Freitas a écrit:
> Hi Christophe,
>
> On 12/8/06, Christophe Thommeret <hftom@free.fr> wrote:
> > Here is a patch that makes use of different colors for typeface tags.
> > It uses yellow for italics and red for bold.
>
> this is an interesting idea and i agree it is probably better to use
> the "ogm" rendering functions for other formats as well.
>
> however i have one problem with this change: it will override user's
> selection of "ui.osd.text_palette".
>
> how can we implement this without losing ability to select font color?
>
> Miguel
Well, seems i've forgot this one ;)
This new patch honors ui.osd.text_palette
|
|
Actually, audio_decoder_loop stores audio streams in ascending buffer type
order. So, for example a stream with buffer type BUF_AUDIO_A52|channel_num
will always be stored in audio_track_map array before any mpegaudio stream.
This breaks the stream order known by TS demuxer and so a user can get a52
french audio when selecting "deu" ! Bad again. This patch fixes that.
|
|
With current code, ts demuxer stores audio tracks in the order it finds it in
PMT, but doesn't correctly set the buffer type so stream's audio_track_map
may (and often) have a different order and so a user can get german audio
when selecting "ita" ! Bad. This patch fixes that.
It also fixes get_optional_data to return correct spu lang instead of none.
|
|
|
|
This does not touch code in contrib.
|
|
|
|
According to bug 1773769, this breaks foo->open().
The fix (as used in Ville Skyttä's patch, which doesn't cover all cases) is
to replace this with (foo->open)().
This patch was generated using
sed -i -re 's/(([[:alnum:]_]+(->|\.))+open) ?\(/(\1) (/' `grep '[>.]open \?(' include -rIl`
One change (in a comment) is not committed.
|
|
The cause was that the resampling code was using only the samples in the buffer
but not really handling the transition between two buffers (which it would
handle completely independently). The new code remembers the last sample from
the previous buffer and uses it in the resampling. We therefore end up one
sample behind and without the clicks.
|
|
Remove the DVB driver installation instructions in favour of a pointer to the
"getting started" section of the LinuxTV wiki.
Add a pointer to the scan documentation (same site).
Mention the requirement for membership of group "video".
|
|
|
|
|
|
|
|
|
|
post_vdr_video is now able to always intercept any frame as XXMC
and XVMC postprocessing has been fixed.
As long as post_vdr_video's image scaling isn't requested or possible
due too unsuitable frame format, the preprocessing procs shall still
get routed as we will not draw on the frame in that situation.
--HG--
extra : transplant_source : %C4%B3%C9%AC%7C%DBJ%D8%60%E2%EF%B4z%C0%01%97%CCQX%D7
|
|
--HG--
extra : transplant_source : %E9%9C%09%7EQ%19%B6%D8%BCJ587%C5i%AF%D5R%F4%DE
|
|
Some postplugins override a frame's draw function just to get/manipulate
frame related information -- and not for drawing on the frame.
The current implementation disables any preprocessing function even if the
plugin is not going to draw on the frame. By introducing a further callback
function route_preprocessing_procs() a plugin is now able to tell that it
is not going to draw on the frame, i. e. it is ok to route the preprocessing
functions to the intercepted frame, too.
--HG--
extra : transplant_source : %170%82%B8%8F%BA%3D%25%9B%D7%EF%E5%B3%3B%EEg%A0%D1be
|
|
XXMC doesn't work well with the way how intercepting frames is implemented
for postprocessing as xxmc_do_update_frame() may change the native frame's
format after the frame has been intercepted. As intercepting XXMC frames
didn't work in the past, we can imply that postplugins which will support
XXMC do know about this special behaviour.
So the idea is to detect any changes on the native frame and propagate these
changes to all intercepted frames. At the same time, we check that all
intercepted frames still share the same data (which we are about to change)
with the native frame and abort otherwise.
--HG--
extra : transplant_source : c%D5%13%21jF%1E%D4%AB%D7%DB%22%27%0A%CB%0E%7F%CF%84v
|
|
When postprocessing is activated, the decoder will pass intercepted
frames to the video driver. The driver must nolonger assume that a
native frame will be passed from the decoder -- it's necessary to
use the supplied macros which give access to the native frame even
when an intercepted frame gets passed.
--HG--
extra : transplant_source : %19%E7%83q1%F6%FEJ%12%A4%1D%AC%CF%7F%2Cn%5BJ%92Y
|
|
--HG--
extra : transplant_source : %EA%EBm%3Exb%A5%3C%07%BC%F0%D9%E1%00%F7%D1%E0%D5%94%ED
|
|
Accelerated frames share data between decoder and video out driver.
When frames get intercepted for postprocessing the decoder will pass
intercepted frames to the video out driver, but the driver needs to
access it's native frame for accelerated decoding. Putting a pointer
to the native frame into acceleration data is an easy way to achieve
this. Some additional macros simplify accessing the native frame.
--HG--
extra : transplant_source : 0%FB%1B4A%D9%27%92z%A5E%C1%1F%81nB%00y%17%9E
|
|
--HG--
extra : transplant_source : y%93%01Dn%EE%9B%DA%60%84%F0%DAT%B7%99%AD%F9%90%03%B0
|
|
--HG--
extra : transplant_source : IsD%AB%2Ci%A1%0F%AE%21%16eg%F2%98%D5%DD%87%DE%3F
|
|
|
|
|
|
to connections list
|
|
Without copying stream up, _x_post_restore_video_frame() will reset the
native frame's stream to the value at _x_post_intercept_video_frame(),
which is typically NULL. This behaviour differs from normal frame
processing, i. e. without postprocessing.
Copying the stream up reveals that stream refcounting was missing
in several postprocessing functions, which is hereby added.
--HG--
extra : transplant_source : I%F1%0B%86%B5%5E%5D%10_6%BC%B6%BCPZ%11%04y%83/
|
|
Blending functions like _x_blend_xx44() take care to clip the overlay
against the destination bitmap. The same clipping must be applied to
determine the relevant area in the destination bitmap for the call to
XvMCCompositeSubpicture().
|
