| Age | Commit message (Collapse) | Author |
|---|
|
|
|
--HG--
rename : src/xine-utils/attributes.h => include/xine/attributes.h
|
|
capability, and force an error if someone tries to include xine_private.h in an unsuitable source file.
|
|
|
|
--HG--
rename : src/xine-engine/xine_internal.h => include/xine/xine_internal.h
rename : src/demuxers/demux_ogg.c => src/combined/xine_ogg_demuxer.c
|
|
--HG--
rename : src/xine-utils/attributes.h => include/xine/attributes.h
rename : src/xine-engine/xine_internal.h => include/xine/xine_internal.h
rename : src/xine-utils/xineutils.h => include/xine/xineutils.h
|
|
There are two functions that actually set this flag:
int _x_set_file_close_on_exec()
int _x_set_socket_close_on_exec()
(We need two functions because file descriptors and sockets
are not the same under WIN32 - of course).
These function belong to libxine's internal API, i.e. they are
not available for use by plugins.
|
|
xine_socket_cloexec() function.
|
|
This patch creates two utility functions:
int open_cloexec(pathname, flags)
int create_cloexec(pathname, flags, mode)
These return a file descriptor with the CLOEXEC flag set, to ensure
that the descriptor is not inherited across a fork/exec operation.
The sockets returned by:
_x_io_tcp_connect_ipv4()
_x_io_tcp_connect()
now also have their CLOEXEC flag set.
|
|
There are two functions that actually set this flag:
int _x_set_file_close_on_exec()
int _x_set_socket_close_on_exec()
(We need two functions because file descriptors and sockets
are not the same under WIN32 - of course).
These function have been assigned "internal" visibility so
that they can be used throughout libxine.so itself while still
not being exported to the global symbol table. In other words,
they're both as close to being "static" as I can make them.
|
|
xine_socket_cloexec() function.
|
|
This patch creates two utility functions:
int open_cloexec(pathname, flags)
int create_cloexec(pathname, flags, mode)
These return a file descriptor with the CLOEXEC flag set, to ensure
that the descriptor is not inherited across a fork/exec operation.
The sockets returned by:
_x_io_tcp_connect_ipv4()
_x_io_tcp_connect()
now also have their CLOEXEC flag set.
|
|
--HG--
rename : src/xine-engine/buffer.h => include/xine/buffer.h
|
|
--HG--
rename : src/xine-engine/buffer.h => include/xine/buffer.h
rename : src/libxineadec/xine_lpcm_decoder.c => src/audio_dec/xine_lpcm_decoder.c
rename : src/libspuhdmv/xine_hdmv_decoder.c => src/spu_dec/spuhdmv_decoder.c
|
|
When watching TV with Kaffeine I frequently had complete engine lockups.
Multiple mutexes were waiting on each other. net_buf_ctrl requires the
demuxer to keep running while playback is still paused.
The diff might look a bit confusing. Basically, all I did was to replace
phtread_mutex_lock ();
...
pthread_mutex_unlock ();
with
if (pthread_mutex_trylock ()) {
...
pthread_mutex_unlock ();
}
at a place where it does the least damage.
|
|
xine_play () gets suspended after start or seek until first frame gets
displayed. This often wont work on slow machines when first frame gets
dropped because its too old. Consequently, UI freezes for full 10 seconds.
Let's wake up xine_play when this happens as well.
OK, this is a luxury convenience fix ;-)
|
|
Audio decoder loop creates a sorted map of available audio channels on the
fly. If neither user nor dvdnav intervene, it will pass the first (= lowest
index) audio channel to decoders.
Now imagine a TV recording with 2 audio channels:
audio.0: eac3 5.1 (fra)
audio.1: eac3 stereo (qaa)
By chance, first audio frame to be demuxed is for channel #1.
Track map will be
[0]: eac3, channel 1
Audio loop opens ffmpeg audio decoder / stereo out. Fine.
Then, first frame for channel #0 comes in.
[0]: eac3, channel 0
[1]: eac3, channel 1
Both are same codec, so audio loop just switches to channel 0 without
further notice. Audio decoder then runs into a mem leak, or worse, crashes
audio out who still thinks we're only stereo.
Whenever we insert something at track map index 0, and its going to be
auto-selected later, reset current codec type. This forces a clean
decoder/output switch.
|
|
|
|
|
|
and that each stream object is removed from its parent xine object's
list before it starts destroying itself.
|
|
I've now tested this patch on Fedora 15 (FFmpeg 0.7) and Fedora 14 (FFmpeg
0.6), and am happy to report that it works fine on F15 and doesn't break
xine-lib on F14. On F14, it also has the happy side effect of no longer
trying to decode an LATM AAC stream with the xineplug_decode_faad.so plugin.
(Which was something which never ended well anyway.)
|
|
--HG--
rename : src/libxineadec/xine_lpcm_decoder.c => src/audio_dec/xine_lpcm_decoder.c
|
|
|
|
First of all, it improves the qt demuxer, ensuring that 24-bit audio is
marked appropriately, and detecting little vs. big endian audio. It also
adjusts the buffer size when audio is 24-bit, ensuring that samples aren't
chopped in half (8192 does not divide evenly into 3 byte samples).
Secondly, in the lpcm decoder, the patch distinguishes between standard
24-bit lpcm (big and little endian) and special DVD-format 24-bit lpcm (see
http://wiki.multimedia.cx/index.php?title=PCM) and now handles both, instead
of only handling the DVD format.
The result is that xine now correctly plays all the 24-bit lpcm samples I
throw at it, whereas before only a few worked.
|
|
|
|
In opposite to the 'xine_get_current_frame' based snapshot function this grabbing
feature allow continuous grabbing of last or next displayed video frame.
Grabbed video frames are returned in simple three byte RGB format.
Depending on the capabilities of the used video output driver video image data is
taken as close as possible at the end of the video processing chain. Thus a returned
video image could contain the blended OSD data, is deinterlaced, cropped and scaled
and video properties like hue, sat could be applied.
With this patch such a decent grabbing feature is implemented for vdpau video out driver.
If a video output driver does not have a decent grabbing implementation then there
is a generic fallback feature that grabs the video frame as they are taken from the video
display queue (like the xine_get_current_frame' function).
In this case color correct conversation to a RGB image incorporating source cropping and
scaling to the requested grab size is also supported.
A more detailed description can be found in file "xine.h".
|
|
_x_get_current_frame_data() called get_last_frame() and locked the returned
frame afterwards. At the same time, video_out_loop() unlocked last_frame to
assign a different img afterwards. So in case the image got unlocked before
it gets locked again, the image resides already on the free image queue. So
when the image gets unlocked, it will be put a second time to the queue and
hence cause a loop in the list the queue is based on. Getting an image from
the queue will then run endlessly.
To fix this issue, a new mutex is introduced which protects write access to
last_frame and read accesses via get_last_frame() from other threads. Next,
the semantic of get_last_frame() had to be changed to return a locked image
already. Finally, functions calling get_last_frame() had to be adapted to
its new behavior (there was only a single function in xine-lib which had to
be adapted: _x_get_current_frame_data()).
|
|
|
|
decoder thread.
Raising nice priority is not limited to root user only on modern unix/linux systems.
So a log message about failure is helpful to everyone.
|
|
Resulting left and right cropping parameters should be multiple of 2.
Left cropping offset calculation to YUY2 frames fixed.
|
|
Intercepted frames should never pass function vdpau_update_frame_format.
--HG--
extra : rebase_source : d1d05b67865eb6cc79225f96159184852f239262
|
|
--HG--
rename : src/libxineadec/gsm610/Makefile.am => contrib/gsm610/Makefile.am
rename : src/libxineadec/nosefart/diff_to_nosefart_cvs.patch => contrib/nosefart/diff_to_nosefart_cvs.patch
rename : src/libxineadec/nosefart/nes6502.c => contrib/nosefart/nes6502.c
rename : src/libxineadec/nosefart/nes6502.h => contrib/nosefart/nes6502.h
rename : src/libxineadec/nosefart/nes_apu.c => contrib/nosefart/nes_apu.c
rename : src/libxineadec/nosefart/nes_apu.h => contrib/nosefart/nes_apu.h
rename : src/libxineadec/nosefart/nsf.c => contrib/nosefart/nsf.c
rename : src/libxineadec/nosefart/nsf.h => contrib/nosefart/nsf.h
rename : src/libxineadec/nosefart/types.h => contrib/nosefart/types.h
rename : src/libxineadec/nosefart/version.h => contrib/nosefart/version.h
rename : doc/faq/faq.sgml => doc/faq/faq.docbook
rename : src/libsputext/demux_sputext.c => src/spu_dec/sputext_demuxer.c
rename : src/libxinevdec/image.c => src/video_dec/image.c
|
|
downwards within post
plugins because this corrupted the receiving frame acceleration data.
This issue occurs typically when a post plugin retrieves a new frame from the video out stage and
then does a _x_post_frame_copy_down from the frame that is delivered from the video decoder.
In this case the two frames are unrelated and acceleration data get messed up.
|
|
xine-libs OSD stack is event driven and some memory blocks are not copied
but responsibility to free the memory moves to different layers of the
OSD stack.
When argb_layer was introduced, this behavior was not taken into account
and as such it is likely that for example osd_free_object() frees the
argb_layer while vdpau_overlay_* functions still access the memory.
Passing responsibility for the argb_layer is not that easy as it seems as
the design goal of the argb_layer was to not duplicate any memory of the
argb_buffer which all other OSD functions usually do.
To solve this issue, argb_layer_t will be turned into a managed data
structure by introducing a ref_count member. ref_count increases as more
layers of the OSD stack hold a reference to that memory block, and it
decreases when they are no longer interested in it. When ref_count reaches
zero the memory block is freed automatically. To deal with ref counting,
set_argb_layer_ptr() has been introduced.
Some functions of the OSD layers had to be modified to deal with reference
tracking. For convinience, osd_free_object() should clear the argb_buffer
pointer so that the buffer may be freed safely after returning.
|
|
Drawing can only be triggered when a backup image exists. Otherwise it's
useless. Therefore, honor it only when a backup frame exists.
--HG--
extra : rebase_source : bffa00a9d9ed4e8994185655d20ba2b3fc9ad818
|
|
This function is similar to _x_query_buffer_usage() but retrieves also
the total and available (= free) number of buffers besides the number
of buffers ready for processing. For example if one wants to create a
buffering algorithm based on the number of frames ready, it's not that
easy to determine the maximum number of ready frames possible. In case
one configures engine.buffers.video_num_frames:50 it may happen, that
only 30 frames can actually be provided by the video out driver. Next
a video codec like H.264 may hold several frames in its display picture
buffer so that you may end up with only 13 ready frames at maximum. At
the same time, the number of available (= free) frames will be 0 (or
almost zero in case of vo). So it may be even easier to base the buffer
algorithm on the number of free buffers.
The reported numbers may also reveal that too few input buffers have
been provided to compensate a large a/v offset at input stage.
--HG--
extra : rebase_source : 255cb186891fbab5199a99031cf1b1e93ac19923
|
|
Video out flushes the decoder when it runs out of images for displaying,
because the decoder hasn't delivered new frames for quite a while. But
flushing the decoder causes decoding errors for images after the flush.
It is likely that the flush is still required for the issues it was
introduced (DVD still images), but they may have been resolved differently
meanwhile (e. g. by supporting sequence end code). So for now a
configureable option has been introduced which keeps the current behaviour
by default.
--HG--
extra : transplant_source : %AB%B3u%1F%E7%3D%10%0C%3D%40%B2%B0%CB%8E%84%FE%E6%87p%AA
|
|
Video out flushes the decoder when it runs out of images for displaying,
because the decoder hasn't delivered new frames for quite a while. But
flushing the decoder causes decoding errors for images after the flush.
It is likely that the flush is still required for the issues it was
introduced (DVD still images), but they may have been resolved differently
meanwhile (e. g. by supporting sequence end code). So for now a
configureable option has been introduced which keeps the current behaviour
by default.
|
|
Flushing the decoder at a pts wrap causes decoding errors for images after
the pts wrap. It is likely that the flush is still required for the issues
it was introduced (DVD still images), but they may have been resolved
differently meanwhile (e. g. by supporting sequence end code). So for now
a configureable option has been introduced which keeps the current behaviour
by default.
--HG--
extra : transplant_source : %9Cs%D1%9A%E5Sk%27%18%A6%94%5D%AB%0Dd%CA%7E%7E%BA%FD
|
|
Flushing the decoder at a pts wrap causes decoding errors for images after
the pts wrap. It is likely that the flush is still required for the issues
it was introduced (DVD still images), but they may have been resolved
differently meanwhile (e. g. by supporting sequence end code). So for now
a configureable option has been introduced which keeps the current behaviour
by default.
|
|
H.264 decoders store a couple of frames in their display picture buffer.
Calling flush before discontinuity my yield images with pts beyond pts
boundery and therefore cause clock errors.
Calling discontinuity before flush resets all pts to 0 before yielding
the images.
--HG--
extra : transplant_source : %9CNpV%B5%83%83%23%F5%C3%09%E43%E2%DFo.%7E%D9%C7
|
|
H.264 decoders store a couple of frames in their display picture buffer.
Calling flush before discontinuity my yield images with pts beyond pts
boundery and therefore cause clock errors.
Calling discontinuity before flush resets all pts to 0 before yielding
the images.
|
|
|
|
xine_new()). Fixed a leak.
|
|
written only when switching binaries for different platforms.
|
|
- use -no-undefined flag only for building shared libraries (libxine, plugins)
- plugins LDFLAGS unification
- move -no-undefined into LDFLAGS_NOUNDEFINED
- attributes.m4 fix
|
|
|
|
--HG--
rename : po/libxine1.pot => po/libxine2.pot
rename : src/libmad/xine_mad_decoder.c => src/audio_dec/xine_mad_decoder.c
rename : src/libspucmml/xine_cmml_decoder.c => src/spu_dec/cmml_decoder.c
|
|
|
|
This is optional, and some systems don't support it. POSIX defines the
_POSIX_THREAD_PRIORITY_SCHEDULING to tell that support is present.
|
