| Age | Commit message (Collapse) | Author |
|---|
|
|
|
SYNC string in the read data; if found, send a XINE_EVENT_UI_CHANNELS_CHANGED event, so that the frontend can go read the new metadata.
|
|
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.
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
defines comes from FFmpeg, but they can easily stay there.
|
|
the cpuid tests; a runtime CPU detection option could be supplied by configure, for instance.
|
|
always there because Intel EM64T machines does not have it.
|
|
|
|
only are used.
|
|
decoder_nsf_init_plugin and demux_nsf_init_plugin.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
read() function, and declare a new buf variable in the function as needed.
|
|
buf parameter, so that any kind of variable can be passed through it.
|
|
|
|
was previously implemented.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
the way, the code is totally broken and does not work as intended.
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
ALSA's DMix can allow to run both xine and aRTs
at the same time for Linux, and if other operating systems lacks a proper
software mixing facility you can consider alternative daemons. Note: aRTs
will not be present in KDE 4.
|
|
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.
|
|
|
|
|
|
close the driver on a return value <0
|
|
|
|
|
|
|
|
close the driver on a return value <0
|
