| Age | Commit message (Collapse) | Author |
|---|
|
According to ITU-T Rec. H.264 (03/2005), Table D-1, there is no such
indicated display of picture. As a result, succeeding enum constants
were mapped to the wrong values.
|
|
The image allocated in decoder_init can immediately be freed after getting
access to accel_data. Accessing the accel pointer afterwards is safe for non
frame related functions although the frame has been freed as freed frames are
not deallocated but put into a free frame queue.
|
|
Currently a parsed picture was only decoded when the parser came across a
NAL unit which started a new picture (aka access unit). An end of sequence
NAL unit must be handled like the access unit delimiter NAL unit, as both
terminate the current access unit.
Handling the end of sequence NAL unit in this way fixes displaying of still
images which end in an end of seqeunce NAL unit. Otherwise they were not
decoded at all (in case of a still frame) or the second field was missing
(in case of a still image which had been coded as a pair of fields).
|
|
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.
|
|
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.
|
|
Transfer of seq_pts to img->pts takes now place at picture header of next
image in decoding order. So far, seq_pts was set to cur_pts at sequence
header and picture header. Hence, img->pts was incorrectly set to pts of
next image in decoding order.
Setting seq_pts only in picture header after call of picture_ready() keeps
the correct pts in seq_pts until it has been transfered to img->pts.
Furthermore, cur_pts of second field must be ignored as we put both fields
into the same image so the image is due at pts of first field.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
During channel changes, the audio stream ends and a new stream begins. This
in turn can lead to 'pa_stream_get_index' ending up in an assertion. Because
of that, a check if there is a stream is a good idea.
|
|
If xine volume is changed from outside the xine frontend, e.g. gnome sound
preferences. xine-lib generates a XINE_EVENT_AUDIO_LEVEL event that
fontends (like xine-ui) can use to update the volume level.
|
|
|
|
Source: informational messages generated by lintian.
|
|
|
|
|
|
|
|
--HG--
extra : rebase_source : 986f546343c08d288d44c3a9ea3a6d4309ace204
|
|
The referenced last_vcl_nal exists only when decoding starts at an IDR frame.
Starting anywhere else may lead to a NULL pointer access.
|
|
|
|
--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
|
|
--HG--
extra : rebase_source : cfee1d5353fa3cacf4df8712fde15cd94e2ee3d4
|
|
The current implementation chooses 4:3 when aspect is within
+/- 0.0075 % of 4:3. Otherwise 16:9 is chosen. But there are
some H.264 channels with almost 4:3 aspect and choosing 16:9
for them is worse. So the new implementation chooses the best
match.
|
|
|
|
|
|
|
|
|
|
The xine libmad adaptor seemed not to forward the pts to the metronome: It
buffers the MPEG audio packets until a threshold is reached (MAD_MIN_SIZE:
2889 bytes) and then has libmad decode the packets which is send to audio
out. The pts of the last audio packet is forwarded on to metronome which can
then sync video with audio.
For the channel4 channels MPEG audio packets have a size of 576 bytes which
means it takes five packets to fill the buffer enough for processing. In the
stream every fifth audio packet contains a pts.
The result of this is: If after a seek, the last audio packet is the one
with the pts, video and audio are in sync. If the pts is in any of the four
previous ones no pts will reach metronome and video and audio will never be
synced before a new seek and even then there's a one in five chance that
video and audio are not synced.
Other channels did not show this behaviour because e.g. BBC One has an audio
packet size of about 750 bytes and send a pts every fifth packet as well.
This means that not every pts from the stream gets through to metronome but
some do. This also means that syncing after a seek is probably not as quick
as it could be but it will sync.
My workaround to this problem is to start decoding not only when a the
buffer has reached a threshold but also when a pts != 0 arrives. This does
mean however that the buffer isn't always filled to the theshold and
decoding might not perform as well as it could.
--HG--
extra : transplant_source : %EC%90%EB%AA%8A%C7%BD%A4%B7%EE%F5%E9%E8SY%89S%9D0s
|
|
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
|
