| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
Attached is a little patch that allows using ffmpegvideo w/o direct rendering
to play mpeg2 ts.
It works for both mpeg2 and h264.
|
|
|
|
|
|
|
|
of the file.
|
|
|
|
|
|
Solaris definitions.
|
|
A null pointer dereference happens if reading a xv port attribute
(which has been reported as readable) fails. This issue exists for
example with proprietary (and a bit buggy ...) ati drivers;
nevertheless it shouldn't cause a segmentation fault (the non-xcb
version simply stores an unitialised value).
This patches solves the issue in a clean way for both branches.
Fixes debian bug #428612 :-)
|
|
xine-lib-specific patch.
|
|
Applied to FFmpeg tree already.
|
|
Applied to FFmpeg tree already.
|
|
|
|
Inspired by a patch by Albert Lee.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Some plugins may have been missed due to them not being built here.
|
|
Some plugins may have been missed due to them not being built here.
|
|
|
|
|
|
|
|
config.h is now include/configure.h and no longer #includes os_internals.h.
A new file, include/config.h, #includes both; this breaks a #include loop.
Other files are updated accordingly.
|
|
|
|
I discovered some problems with the framebuffer output driver. The first
problem I had was a segfault when trying to play a 480x360 clip on a 640x480
display. I traced it to the yuv420_rgb16() color conversion function, which
was overrunning the input buffer (the "y" part of the image). The reason
was that it was being called downstack from fb_frame_proc_slice(), multiple
times for each 16-pixel high horizontal slice of the image. When it got to
the last slice, only 8 pixels were left to the bottom but it still tried to
process a 16-pixel high slice.
Nosing around a bit, I compared the configuration of the color converter as
used by the fb driver to the xshm driver and found some oddities:
1) The color converter was configured with a "source height" of 16 pixels no
matter what the size of the image, and a "dest height" based on what was
referred to within video_out_fb.c as a "stripe" -- essentially an input
slice scaled up or down as required by the output size.
2) Apparently to prevent the above from causing problems, the position in
the output buffer was managed by special code -- see the "stripe_incr"
variable.
3) The xshm driver calls yuv2rgb_next_slice() with a NULL argument at the
beginning of each frame to allow the color converter to reset its tracking
of the slice-by-slice progress through the image; the fb driver does not.
I'm not sure exactly why it was done that way, but my best guess would be
that whoever coded it didn't know about the need to call
yuv2rgb_next_slice() with a NULL argument, and the rest was built up to get
it to mostly work without that.
The attached patch changes the behaviour to match that of the xshm driver,
and also removes the reset_dest_pointers() function, replacing its single
invocation with one to fb_frame_field(), which is identical after removing
the "stripe" management.
It fixed my crash. Can anyone see if I've misunderstood what was going on?
If not, it should probably be applied to the official version.
|
