Age | Commit message (Collapse) | Author |
|
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.
|
|
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.
|
|
|
|
|
|
|
|
xine_musepack_decoder.c in libxineadec.
--HG--
rename : src/libmusepack/xine_musepack_decoder.c => src/libxineadec/xine_musepack_decoder.c
|
|
the patching needed.
Contestually, move libmpcdec code in contrib/libmpcdec, so that it's not mixed together with xine code.
The use of MUSEPACK_LIBS/MUSEPACK_CFLAGS intermediate is to make simpler move to pkg-config checks if libmpcdec developers decide to install one.
|
|
|
|
|
|
extend the documentation available before.
|
|
|
|
|
|
as needed for some files where gcc runs out of registers otherwise.
|
|
This fixes linkage problems for people who want this but don't want X.
|
|
|
|
First of all, as we check the presence of the attribute in configure.ac and
we generate the XINE_PACKED definition there, there's no need to do the work
again on attributes.h.
Also remove #pragma pack support for now, as the trick is just not neat enough,
and as it is it's just noise.
Make Wine, libdvdnav and nosefart use XINE_PACKED rather than doing their own
checks, as they are less reliable.
|
|
32-bit value.
|
|
bswap.h already.
|
|
|
|
|
|
|
|
enabled in configuration.
As external FFmpeg does not install its own ffmpeg_config.h, we have
to assume that it supports every buffer type; this should probably
be checked for errors when opening the decode, but at least it should
work to the same extent it worked on 1.1.
|
|
The dvdata.h is never installed by FFmpeg, so when using the external
copy you have to still use the internal dvdata.h file at the moment.
|
|
This way there's no need to fake it when using the external copy.
|
|
|
|
|
|
Altivec code.
|
|
Two of the modified files are headers, but each contains definitions as well as
declarations and is only ever used once.
|
|
|
|
from the FFmpeg's build directory (as it's not easy to take it with relative path).
|
|
With the new way to build FFmpeg, there's no need for a special function
to use when building with internal FFmpeg, so just use the one already
provided by libavcodec.
Codecs that shouldn't be registered should just be disabled in the build.
|
|
it, we should put it in contrib/ instead.
|
|
|
|
|
|
to be video_overlay.
|
|
|
|
get along that well.
|
|
|
|
The only place where this was used was in video_overlay_object_t, which
is not used by anything in xine-lib, nor in xine-ui, gxine, oxine or
Kaffeine.
With this change (that basically reverts most of changeset 1517) the
size of video_overlay_t structure drops from 4MB to less than 3KB.
It also reduces xine-lib's memory consumption by 10MB straight.
|
|
|
|
|
|
|
|
correct location.
|
|
Together with this, define a xinepost_LTLIBRARIES class that is used
to install the post-plugins in the correct directory.
Also add the rule to remove them.
|