| Age | Commit message (Collapse) | Author |
|---|
|
XDG_CACHE_HOME as a place where to put the data.
|
|
used in a few more cases.
|
|
|
|
/usr/sharee.
Also add a diff from the original sources and add it to the distribution.
|
|
lookup (if the chosen prefix is suitable for it).
|
|
than in the root of it.
|
|
With this commit, also fix the previous mistakes in the iteration.
|
|
With this change, when rendering a font through FreeType2 (and not using
FontConfig) the directories looked up are the ones defined in XDG_DATA_DIRS,
right after XDG_DATA_HOME; this way the user can decide to have fonts data
in a different place than its home directory.
This also splits up the lookup for fontconfig and non-fontconfig cases in
two different functions, to avoid gotos and labels.
|
|
|
|
the check manually.
|
|
This handle can then be used by all plugins and other parts of the
xine engine without having to duplicate it.
|
|
|
|
The libxdg-basedir project, developed by Mark Nevill, implements
a simple way to use the XDG_* variables used to define the paths
for the XDG Base Directory Specification (0.6).
As I was going to reinvent the wheel, I prefer to import this
library that was already written, hoping it will continue being
developed.
|
|
|
|
|
|
Directory Specification.
With this change, xine-lib starts abiding to the XDG Base Directory
Specification, allowing the user to define a different path to save
its cache data (by setting XDG_CACHE_HOME environment variable).
|
|
The introduced functions give "frontend like" plugins a chance to
lock and unlock frontend_lock. This protects such threads for
example from beeing blocked when changing the streams speed.
|
|
The introduced function give "frontend like" plugins a chance to
lock and unlock port rewiring. This protects such threads (when
combined with holding the frontend lock) from beeing blocked when
calling functions like xine_get_current_frame().
|
|
|
|
The idea is to allow only a "single" frontend to rewire ports at
a certain point in time. Regarding a stream, frontend_lock is used
for example to allow only a single frontend to change the speed.
Unfortunately, frontend_lock cannot be used as the rewire functions
are not stream related.
Therefore a new port_rewiring_lock was introduced and used at
appropriate locations. When an arbitrary thread now holds the
frontend_lock and the port_rewiring_lock, it is safe that acquiring
a port ticket in functions like xine_get_current_frame() will
never block the thread.
|
|
One can assume that a still frame is to show when there are no more
frames left to display.
The changed code uses _x_query_buffer_usage() to retrieve the number
of frames waiting to be displayed to integrate this information into
the decision.
|
|
|
|
There are some situations where bob deinterlacing doesn't make much
sense, as the effect doesn't work for example for slow motion. And
in fast motion mode, the sleep between displaying the two fields
lowers the reachable fast motion frame rate. Another annoying effect
is the reduction in vertical resolution for still images.
The changed code tries to detect such issues and disables bob
deinterlacing for such frames. The detection of still images is
still to come.
|
|
Bob deinterlacing is implemented as showing the top field, sleeping
for half the frame duration and showing the bottom field. Most
drivers tend to synchronize displaying a field on the VBI and thus
displaying a field may take up to half the frame duration in certain
cases.
According to the original code, the sleep took always half the
frame duration and therefore the second field could get displayed
too late. As a result, the driver was syncing to VBI most often,
so that things got even worse.
The changed code now calculates the sleep time in a way that the
second field gets displayed half the frame duration after the
first field. Moreover, it monitors how much time was spent to
display the first field and when this time exceeds 75 % of the
field time (= half the frame time), it skips displaying the second
field, as usually this is an indicator that the driver has no
more frame buffers left. So displaying the second field would just
make things go worse.
|
|
The current implementation keeps references to VO_NUM_RECENT_FRAMES
frames (for deinterlacing), but doesn't make any use of them.
As many XXMC capable devices only supply 8 frames at all, keeping
fewer frames referenced makes more available for decoding and thus
avoids frame drops by keeping the number of frames which are ready
for display more often above frame_drop_limit.
|
|
The current code misses the ability to switch back to an
unaccelerated context, e. g. when previously MPEG2 material
was displayed which is then followed by H.264 material. As
the latter is not handled as XINE_IMGFMT_XXMC there was no
way to leave the accelerated context and therefore the images
did not appear on screen.
|
|
This function shall be used to poll the number of remaining frames
from a certain point in time on until the reported numbers are all
0. At that point in time, the content on screen is identical to a
certain state of the stream, at which for example, a hardcopy may
be taken.
|
|
The current code has a race condition which can block arbitrary
threads that call for example xine_get_current_frame() until the
stream gets unpaused again. This can happen when the internal
ticket acquiration collides with a ticket revokation for example
when another thread is going to pause the stream.
There are a few situations where a port ticket needs to be
acquired for calling a port function but where it is absolutely
undesireable to get blocked for an undetermined period of time.
Therefore the ticket system should be extended by nonblocking
functions which allow ticket acquiration even when a ticket
revokation is in progress. And in the case where blocking is
not avoidable, it should simply be indicated that no ticket was
acquired. The caller can then choose to repeat the call at a
later point in time.
|
|
|
|
discover X libraries.
|
|
device, as discussed in xine-devel.
|
|
something I'll be working on for 1.2.
|
|
audio output. Not sure of their status, but they are there.
|
|
streams don't seem to crash anymore, although the real demuxer should be improved.
|
|
satisfy.
|
|
The _x_config_init() and _x_config_change_opt() functions should stay internal
and not be exported by the library, so remove XINE_PROTECTED to hide them.
|
|
The current code implements hardware (a shift register) in software
just to find the byte pattern 00 00 01 xx, which causes remarkable
CPU load on less powerful machines.
The new approach uses memchr() to find the 01 in the buffer, which
most often hits a start code. memchr() seems to be even faster then
implementing a real pattern search (i. e. by just looking at every
third byte to find 01). The new implementation causes significantly
fewer CPU load on less powerful machines.
|
|
The current code emits a frame when a non slice start code is seen.
For still frames, this is typically a sequence end code. But the
current code doesn't call parse_chunk() immediately because it waits
for a further start code to determine the chunk of data to pass to
parse_chunk(). But there isn't such a further start code for still
frames after the sequence end code and thus, the still frame will
not be emitted.
As sequence end code is the only start code which has no data
according to the MPEG specification, let's use this information
to call parse_chunk() immediately.
|
|
The current code cannot detect the absence of AFD once it has been
seen in the stream. As AFD can appear in user data after sequence,
group or picture start codes, the idea is to reset the stored AFD
value when processing the sequence start code. In the case where
AFD is seen in user data, it is stored internally, to have it ready
when the first slice is processed. At least at that time, AFD data
has been seen and can be analyzed for changes. At any change, the
AFD value will then be stored into a stream property. Doing this
only for changes avoids locks while writing the same value over and
over to the stream's property.
|
|
determination.
The current code detects MPEG2 when parsing the sequence extention
which appears only in MPEG2 streams. But this is to late for correct
aspect ratio determination which happens earlier and therefore
assumes MPEG1. The result is a totally wrong aspect ratio.
To fix this issue, the next start code (which is already available
at that time) is passed to parse_chunk() too, which can then be
used to detect a MPEG2 extension start code early enough before
the aspect ratio is determined.
|
|
|
|
|
|
throwing off the test.
|
|
|
|
|
|
|
|
|
|
|
|
pthread_create.
The link is needed to make sure that the LIBS variable is set correctly, otherwise it might just be finding the definition but using the wrong link-time parameter.
Also, feed proper parameters to pthread_create to avoid -Wnonnull to cause a test failure (GCC/GLIBC).
|
|
|
