| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
Date: Tue Nov 18 2008 00:57:00 +0000
Upstream ImageMagick changed part of the API and did not update their
deprecated support stuff, so bump us along for now to avoid having to
downgrade.
|
|
|
|
--HG--
rename : doc/faq/faq.sgml => doc/faq/faq.docbook
|
|
|
|
|
|
|
|
to early
The current code turns of PTS tagging as soon as a match is found. But depending
on picture reordering, there may be later frames which still have the tag. The result
is that most likely the highest bit is set which makes the PTS values large negative
numbers which cause a clock error and make streams unplayable.
To fix this issue, a stable counter is introduced. The two passes of PTS tagging are
now switched after the tag has been seen stable for 100 frames. This should protect
us from picture reordering issues.
--HG--
extra : transplant_source : I%2A%BBi%A5nb/%5E%12%9Ay%7B%BAj%7D%0B%16%0By
|
|
|
|
|
|
input_vdr's RPC thread needs to lock frontend. But frontend is also locked
during xine_open() and xine_play(). xine_play() furthermore waits up to 10
seconds for the decoder to return the first frame. So it is unlikely that
the RPC thread can lock the frontend to execute VDR's commands before VDR
sends the first frame. Finally the RPC thread gave up locking the frontend
after 5 seconds and the connect to VDR failed.
To fix this issue, the RPC commands during startup phase are now handled
by the thread which has called xine_open() as it already owns the frontend
lock.
|
|
This covers the internal snapshot and the version in Debian lenny.
|
|
|
|
--HG--
rename : src/demuxers/demux_nsf.c => src/combined/nsf_demuxer.c
rename : src/demuxers/demux_ogg.c => src/combined/xine_ogg_demuxer.c
rename : src/libsputext/demux_sputext.c => src/spu_dec/sputext_demuxer.c
|
|
|
|
|
|
implementations.
Some implementations are buggy and lock resources (for example the display or
internal data structures) in different order, which results in deadlocks.
As XVMC_LOCKDISPLAY_SAFE is not defined by default, most API functions will
now be guarded by a LockDisplay()/UnlockDisplay() pair, which imposes a lock
order at least for the resource display and hence avoids those deadlocks.
|
|
|
|
|
|
implementations.
Some implementations are buggy and lock resources (for example the display or
internal data structures) in different order, which results in deadlocks.
As XVMC_LOCKDISPLAY_SAFE is not defined by default, most API functions will
now be guarded by a LockDisplay()/UnlockDisplay() pair, which imposes a lock
order at least for the resource display and hence avoids those deadlocks.
(transplanted from 580a2a9148618131cedfbc9058ac7979ca16f69b)
--HG--
extra : transplant_source : X%0A%2A%91Ha%811%CE%DF%BC%90X%ACyy%CA%16%F6%9B
|
|
|
|
This way one can just run xine vdr://
|
|
|
|
now invalid.
But as PTS values are stored in FFmpeg's decoder, there is no way to reset them to 0.
Therefore PTS tagging has been introduced. At discontinuity a tag is generated and
applied to all new PTS values. Any returned PTS value is checked for this tag and
outdated PTS values are reset to 0. When the tag appears on returned PTS values then
tagging is reset.
|
|
the buffer
|
|
order.
Attaching buffer PTS, which are in decoding order, to decoded images is
simply wrong. FFmpeg meanwhile provides a way to pass PTS values through
its decoder too. As a result they get reordered to display order and can
be attached to the decoded frames.
|
|
Currently, once the tvtime plugin has locked onto a telecine pattern, it
will wait PULLDOWN_ERROR_WAIT (a hardcoded #defined value) number of frames
before switching to filmmode.
This sensitivity is excessively high (i.e. the value is too low) for certain
content -- the kind of content that was shot on film but edited in video
mode, so telecine patterns are constantly breaking (examples like Buffy,
Simpsons and Family Guy are especially egregious offenders).
The attached patch turns this constant into a modifiable post plugin
parameter called pulldown_error_wait.
Xine helpfully emits a XINE_EVENT_POST_TVTIME_FILMMODE_CHANGE event when
film mode changes (a patch I submitted some years back). With the attached
patch, a front-end can monitor the frequency of these events, and
dynamically adjust pulldown_error_wait in a sensible way.
|
|
--HG--
rename : include/xine.h.in => include/xine.h
rename : src/libspudvb/xine_spudvb_decoder.c => src/spu_dec/spudvb_decoder.c
|
|
The ARGB layer is based on the idea and scratch implementation of Julian
Scheel. Each OSD object may be associated with a client ARGB buffer which
holds the content of the OSD, hence there is no need to copy the buffer
content.
So far an OSD's reference coordinate system was defined by coded video
resolution. By specifing an OSD's extent, capable hardware or software
implementations my scale an arbitrarily sized OSD to the video output
area while blending.
Additional constants have been defined to allow vo_drivers to report
their capabilities and to allow clients to check whether an OSD
implementation supports these new features.
|
|
The test stream sometimes causes the ASF demuxer to report "unknown GUID"
several times then act as if the headers have been received, with the audio
output thread waiting forever for data to be passed to it by the decoder, in
this case the ffmpeg audio decoder.
This particular hang occurs if playback is stopped before the demuxer has
decided that headers have been received (later, and we'd have the problem
which the parent cset of this cset fixes); having the demuxer control insert
empty audio buffers where it would otherwise wait forever for the audio
output thread to receive some data.
Test stream: mmsh://213.92.19.8:80/radiodeejay?MSWMExt=.asf
|
|
playback stopped.
|
|
libmms will always fail to request media with URIs containing percent-encoded
characters. This is because the path component in the MMS URI should be
decoded before it is sent to the server.
http://download.microsoft.com/download/9/5/E/95EF66AF-9026-4BB0-A41D-A4F81802D92C/%5BMS-MMSP%5D.pdf
(page 48)
|
|
input->read may return negative error codes or read less than we want
so we should check for the right return value instead of just not 0
|
|
do not forward data if there is not enough
|
|
check buffer lengths to avoid out of bound access when
decoding the header.
Based on a patch by Matthias Hopf <mhopf@suse.de>.
|
|
if the atom size is shorter than the header size, do not try
to decompress anything, as this would lead to zlib reading
out of bound data.
|
|
check the size of allocated buffers to prevent out of bound access
|
|
Based on a patch by Matthias Hopf <mhopf@suse.de>.
|
|
|
|
return error when the allocation function returns NULL
Otherwise xine might be induced to segfault by bad user data.
|
|
Some input plugins (e.g. file) return negative error codes from read,
this should be treated as no (more) data available.
|
|
Currently, this is satisfied in all locations where it is called,
but it is more prudent to add the check.
|
|
get_size might return -1 (e.g. for streams whose size is unknown),
but demux_mod is not able to handle this.
This is particularly bad because it is later assigned to unsigned types
(demux_mod_t.filesize is size_t).
Based on a patch by Matthias Hopf <mhopf@suse.de>.
|
|
Some input plugins (e.g. file) return negative error codes from read,
this should be treated as no (more) data available.
This is particularly bad because the error code is assigned to an
unsigned integer variable for use by the caller.
Based on a patch by Matthias Hopf <mhopf@suse.de>
|
|
matroska
while codec_private_len is unsigned, the size is later used to calculate
the signed xine_bmiheader.size
|
|
Add checks for negative return values in aac,ac3,dts,mpc,
nsf,ogg,shn,slave,ts,tta,vox demuxers.
Some input plugins (e.g. file) return negative error codes from read,
this should be treated as no (more) data available.
This is particularly the negative size is then assigned to buf->size,
potentially causing overflows elsewhere.
The patch also removes the duplication of the (previously) == 0 handler
in demux_ac3.
|
|
When a track's fifo is not set up (typically because the track type is invalid),
do not call init_codec, as all implementations dereference track->fifo,
segfaulting if it is NULL.
|
|
The real_parse_headers function in demux_real.c in xine-lib 1.1.12,
and other 1.1.15 and earlier versions, relies on an untrusted input
length value to "reindex into an allocated buffer," which allows
remote attackers to cause a denial of service (crash) via a crafted
value, probably an array index error.
|
|
xine-lib 1.1.12, and other 1.1.15 and earlier versions, relies on an
untrusted input value to determine the memory allocation and does not
check the result for (1) the MATROSKA_ID_TR_CODECPRIVATE track entry
element processed by demux_matroska.c; and (2) PROP_TAG, (3) MDPR_TAG,
and (4) CONT_TAG chunks processed by the real_parse_headers function
in demux_real.c; which allows remote attackers to cause a denial of
service (NULL pointer dereference and crash) or possibly execute
arbitrary code via a crafted value.
|
