| Age | Commit message (Collapse) | Author |
|---|
|
This is optional, and some systems don't support it. POSIX defines the
_POSIX_THREAD_PRIORITY_SCHEDULING to tell that support is present.
|
|
In dvd_input.c:file_read(), if the read is not done in a single access, the
buffer pointer doesn't get advanced so that the second read overwrites the
data of the first.
I actually don't remember under which circumstances this could happen, but
the flaw in the code is obvious.
The patch is from NetBSD's pkgsrc, and this patch is attributed to an
"unnamed contributor" in the CVS log.
|
|
In demux_loop(), a time value is calculated by adding to the fractional
part. In case a second barrier is crossed, the value is not in its
canonical form anymore - the fractional part is larger than 10^9-1.
It should be normalized for portability. While I haven't found a formal
requirement for this in POSIX, NetBSD's libpthread checks for it and
complains.
|
|
|
|
|
|
|
|
|
|
Recently I've posted a patch for xine-ui which uses a timed lock to avoid a
deadlock when the output callback happens while changing the drawable. It is
possible to avoid this deadlock at all by moving the drawable lock (and the
reinit call which it is not necessary for the callback) after the callback.
As a result the mentioned patch for xine-ui may be reverted.
|
|
It is known to everyone that locking serveral resources requires a consistent
order on all places where these resources are required. Otherwise a deadlock
will happen.
|
|
At least two threads operate on the drawable -- the video output thread and
the xine-ui gui thread. When xine-ui changes the drawable while the output
thread is displaying a frame it is likely that the video output thread
triggers the X11 error bad drawable. Usually XLockDisplay() is used to
synchronize these threads but it causes too much impact and should only be
used to implement short atomic operations. In this case scheduling two
fields of a frame for displaying may take at least one field duration which
is quite a long time. Therefore a separate mutex is used for synchronizing
those threads.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
--HG--
rename : include/xine.h.in => include/xine.h
rename : po/libxine1.pot => po/libxine2.pot
|
|
|
|
progressive mode
|
|
- only mark pictures as reference for vdpau, where actually the slice nals are used for reference
|
|
|
|
|
|
|
|
- only detect before drawing and only once per image insted per field
|
|
- never exceed hard limit of 16 frames in dpb
- use max_dec_frame_buffering parameter when set
|
|
|
|
implemented a proper detection of interlaced/progressive content to enable deinterlacing only when needed
|
|
|
|
wrong list was referenced in dpb_free_all, when clearing the reference picture list. this caused reference pictures not to be freed when stopping
|
|
- discard field pairs, when only one field is available (ie at start of stream)
- fix tff marking
|
|
- fix tff marking
- make code easier to read
|
|
- the dpb is using two xine_lists now to manage reference pictures and pictures delayed for output
- take VUI num_reorder_frames into account to buffer just as many frames as needed
- cleanup reference counting for decoded pictures
|
|
|
|
|
|
Currently, just treat it exactly as if it were Matroska.
|
|
|
|
|
|
|
|
|
|
|
|
removed unused code
added enum for segment type
added missing lf's to log strings
|
|
|
|
--HG--
extra : rebase_source : 74bbd9ee7e0732ce16838356a666a07c9a44acd4
|
|
|
|
|
|
|
|
properly skip the emulation_prevention_three_byte in the bitstream, which fixes some glitches which could happen whenever such a stuffing byte was in one of the parsed sections
|
|
completely reinitialise the h264 parser to avoid messup in the dpb which causes unnecessarily long img-locks, that might cause freezes
|
|
|
|
--HG--
rename : include/xine.h.in => include/xine.h
rename : src/xine-engine/video_out.h => include/xine/video_out.h
|
