| Age | Commit message (Collapse) | Author |
|---|
|
The last fix to PTS wrap detection could not handle streams with A/V
offsets larger than 3 seconds. The improved version can deal with
them now.
--HG--
extra : transplant_source : %89%1F%7E%12%D5r%A8%CE%95N%BAG%96%02%60%0C%10%9Aar
|
|
Seen in an AVI in the wild; apparently generated by mencoder.
|
|
>
> /* Special codes used when specifying changer slots. */
> #define CDSL_NONE (INT_MAX-1)
> #define CDSL_CURRENT INT_MAX
|
|
Found this little problem (was causing some "uninitialised variable
accesses" under valgrind) while implementing Podcast reading in RB using
Totem's playlist parser.
--HG--
extra : transplant_source : J%D9/%16%E2i%B2%84%FA%8A%85%888N%A5%B4%16s%BD%16
|
|
When demux_mpeg_pes uses FFmpeg for H.264 streams, it doesn't set
video_step as it doesn't know it. But FFmpeg provides it deriveable
from time_base. So let's use the derived value as long as it isn't
set explicitly.
Furthermore, demux_mpeg_pes set's BUF_FLAG_FRAME_END whenever it
encounters a H.264 access unit delimiter, which appears between
fields or frames, but it doesn't know, whether it deals with fields
or frames. avcodec_decode_video() on the other hand sets got_picture
even when the decoded data specifies just a field. But it also sets
the flag interlaced_frame. So let's use this flag to halve video_step
in order to show the decoded images just for a field duration.
--HG--
extra : transplant_source : %40Q%E3fO%3C%E7%A0%02%BA%9D%1D%BD%81%F0f-%EAs%87
|
|
(wait the main stream to fully initialize)
prevents division by zero in draw_subtitle().
|
|
|
|
(transplanted from 2b2f2adc8a1e0a05d89354ff259f7b2a331aa071)
--HG--
extra : transplant_source : %2B/%2A%DC%8A%1E%0A%05%D8%93T%FF%25%9F%7B%2A3%1A%A0q
|
|
I managed to miss one from my earlier patch, though I could've sworn I
checked this.
Add (prefix)/lib64/real into the real codec path list. It is encountered
in the 64bit PLF Mandriva real-codecs package.
|
|
Successive MPEG1/2 B frames (each with a slice #9) could incorrectly
lead to the assumption of a H.264 stream, as sequence or group start
codes were not seen for these frames. So the detection logic
interpreted the slice #9 start codes as H.264 access unit delimiters
and therefore incorrectly switched to H.264 buffer type instead of
MPEG1/2. Extending the detection logic to consider MPEG1/2 picture
start codes as well (which do not appear in H.264 streams), prevents
false positives.
|
|
These cheats where hiding a frame allocation bug in FFmpeg decoder
which was previously fixed.
|
|
External FFmpeg has recently gained multithreaded H.264 decoding
and to make use of this feature, it is necessary to inform FFmpeg
about the maximum number of threads it may use for decoding.
|
|
When a stream doesn't start with an IDR frame, there will be several
seconds of bad frames and not setting PTS on those frames causes an
unnecessary delay in syncing audio and video.
|
|
When a stream doesn't start with an IDR frame, then frame size isn't
known, but all frames up to an IDR frame are reported as bad frames.
In such a case, a frame of size 1x1 will be allocated as xine-lib
cannot handle 0x0 frames properly, i. e. many output drivers simply
crash.
|
|
|
|
The attached patch to xine-lib adds two more real codec search paths.
/usr/lib/real is encountered in PLF packages for Mandriva, and
/usr/lib/RealPlayer10GOLD/codecs is encountered in RealPlayer package of
Mandriva.
|
|
|
|
Only build-tested due to lack of sample data.
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
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.
|
|
I noticed that goom visualization plug-in doesn't work / freezes at some
combination of bit rates and its FPS.
Digging through it I found that algorithm that dispatches sound data to goom
is buggy, and so I have rewrote/cleaned it a lot.
Let me explain what is wrong:
I am talking about goom_port_put_buffer
in /xine-lib-1.1.7/src/post/goom/xine_goom.c
The counter this->skip_frame is supposed to hold count of frames that goom
should skip because of _video render unable to render video_.
But that algorithm also skips frames on its own, and still decrements that
counter.
So it goes negative, and no frames are displayed.
Basically to fix that you need to add
if (this->skip_frame > 0)
before this->skip_frame--;
But since I want to fix that properly I decided to learn why goom skips frames
on its own, and I now understand that whole algorithm is buggy.
Thus I reimplemented it properly.
I tested it , and it works with all my sound files, also I added lot of debug
printfs to test whenever it works as expected, and it does.
--HG--
extra : transplant_source : %B6%0C%09%D6%93%B8%00cj%3B8%C7%B5%0B%DB%21%08%92%3E%7B
|
|
|
|
Intent is to allow front ends to rename their old, badly-named, config items.
|
|
|
|
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().
|
|
Thanks to Harald Sitter from Amarok team for reporting a testcase.
|
|
|
|
If there's no signal, the tuner never goes to FE_TIMEDOUT. Add a separate
timeout, to prevent xine waiting forever in these situations.
|
|
We have seen input_rtp lock up in use, and traced the problem to the separate
tail/head locks on the input buffer. Reduce to a single lock, increasing lock
contention between the reader and the writer, but removing the previous
deadlock risk.
Also use select() before recv(), to ensure that we never wait forever for
packets (e.g. if we're trying to receive a multicast stream, but an
administrator has blocked all multicast packets to the device - iptables -A
INPUT --dst 224.0.0.0/4 -j DROP induces this failure for testing).
|
|
show() in osd.c uses realloc in an effort to minimise the amount of
memory actually used for rle objects. In practice, this caused xine to
fragment memory, and gradually use more and more RAM (measured over a
period of 24 to 72 hours).
Change osd.c to allocate the maximum amount of memory it could need;
because it touches this memory in a linear fashion, lazy page allocation
will ensure that most of the memory used is needed. Further, because
this makes the per-drawing allocations the same size, it avoids virtual
address space fragmentation.
|
|
When leaving xine playing DVB with subtitles for a long period of time,
I noticed a gradual increase in memory use, caused by it creating more
and more timeout threads. In addition, the existing thread was not safe
w.r.t destruction of the decoder, and would occasionally segfault xine.
Further, EN 300 743 states that the timeout should be sent by the
broadcaster; the existing thread had a constant 6 second timeout,
whereas (e.g.) BBC NEWS 24 subtitles are broadcast with a 15 second
timeout. In theory, this could result in subtitles being hidden in error.
This rework changes the thread to pick up a timeout set by
draw_subtitles; in addition, it uses pthread condition variables to
avoid any need to kill and recreate the thread.
|
|
When running DVB subtitles for a long period of time (over 24 hours), we
noticed a slow leak of memory. This patch removes one cause of leakage
for us.
|
|
When using DVB subtitles on an SMP machine, we see occasional lockups, which
appear to be caused by one thread acquiring the same ticket twice. Fix this,
by preventing acquire() and release() from blocking if the current thread has
already acquired the ticket.
Code sequences like the following can still block in all acquires and
releases:
ticket->acquire(...)
/* Do something */
ticket->release(...)
However, code sequences like the following, which used to deadlock if ticket
was revoked at just the wrong moment, now succeed:
ticket->acquire(...)
/* Do something */
ticket->acquire(...) /* This acquire cannot block */
/* Do something */
ticket->release(...) /* This release cannot block */
/* Do something */
ticket->release(...)
Without this patch, the inner acquire() and release() calls could block if
ticket was revoked at the wrong time. revoke() would not unblock the blocking
acquire until there have been as many release()s as acquire()s, which cannot
happen.
|
