Age | Commit message (Collapse) | Author |
|
The problem comes from the fact that into xine_probe_fast_memcpy() there is
a call to xprintf, which excutes some actions to this->log_lock. But the
"log_lock" field is still uninitialized. Under Windows, the xine_init()
always crashes because that type is implemented as a structure, so the lock
receives a NULL pointer and the execution is halted. The attached patch
proposes to move the mutex objects to the top of xine_init() function.
--HG--
extra : transplant_source : %07%1D%7F%F0%97%7D%06%3E%9F%2Ar%03%1DQ%14%F3%D1%EF%1D%93
|
|
With Pthreads for Win32/Win64 I cannot compare two pthread_t items because
they are implemented as structures. This patch fixes the comparison by
using pthread_equal() function.
--HG--
extra : transplant_source : %9D%98%CE%83%5E%BD%A9u%11%C7%3BmP%28%EBH%D0%B6I%DF
|
|
The new function allows us to remove pausing the stream as the image
data can now be retrieved in a single call.
--HG--
extra : transplant_source : %DE%A7%7B%C9%E93%15%AC%1E%3D%A2Ik%E4%D1%AC44w_
|
|
For various operations, VDR needs to know the current PTS. But to have VDR
work correctly, xine-lib's PTS must only be returned to vdr-xine when the
PTS is related to the current stream.
Intercepting the stream's metronom for monitoring discontinuities serves
the need to detect the point in time from which on xine-lib's PTS values
are related to the current stream.
--HG--
extra : transplant_source : %89%DEe%F0uI%CCMK%27%9E%C3%A6%EC%ACk%13Bh%02
|
|
vdr-xine used a padding packet to push out any remaining data before
input_vdr executed "clear" to drop that data. But depending on the way
how input_vdr is connected to vdr-xine it could happen that the padding
packet reached input_vdr after executing "clear" and therefore "clear"
didn't work as expected.
To fix this issue, sync points are introduced by making the padding
packets "unique" in the stream. input_vdr will now drop all data up to
the sync point packet. So even if the padding packet arrives later than
the "clear" command, only data following the sync point will be fed to
the demuxer.
--HG--
extra : transplant_source : %A1%5E%8C%E1vmW%98D%1EW%A7%AF%B4V%5D%84%26%D0%DA
|
|
--HG--
extra : transplant_source : %FFP%FFI%1EgE%7F%15%AAwQt%AD%08%FB6aO%19
|
|
(This can happen when you revert & patch when merging.)
|
|
--HG--
rename : include/xine.h.in => include/xine.h
rename : src/libdts/xine_dts_decoder.c => src/audio_dec/xine_dts_decoder.c
rename : src/libmpeg2/decode.c => src/video_dec/libmpeg2/decode.c
|
|
--HG--
rename : src/libffmpeg/ff_dvaudio_decoder.c => src/combined/ffmpeg/ff_dvaudio_decoder.c
rename : src/libffmpeg/ff_video_decoder.c => src/combined/ffmpeg/ff_video_decoder.c
rename : src/libffmpeg/ffmpeg_decoder.h => src/combined/ffmpeg/ffmpeg_decoder.h
|
|
|
|
HAVE_FFMPEG_AVUTIL_H wasn't being defined, and there were some incorrect checks.
|
|
xine_get_current_frame() relies on the caller to provide a sufficiently
sized buffer. To calculate the required size of the buffer, one has to
call xine_get_current_frame() to retrieve the necessary parameters. But
as the image can change between two successive calls one has to pause
the stream for consistency.
To improve the situation, xine_get_current_frame_s() has been introduced
which requires to specify the buffer size when an image is going to be
retrieved. Furthermore, it will return the required/used buffer size.
In that way, it can prevent copying data into a too small buffer and
therefore can be considered safe.
For convenience, xine_get_current_frame_alloc() is provided which takes
care to allocate a sufficiently sized buffer. This function avoids
pausing the stream as the image will be returned in a single call.
|
|
|
|
|
|
|
|
work for both internal and external FFmpeg (with new layout).
|
|
This also allows to remove the comment stating the includes come from libavutil, as it's now explicit.
|
|
|
|
|
|
--HG--
rename : src/combined/ffmpeg/ff_dvaudio_decoder.c => src/audio_dec/ff_dvaudio_decoder.c
|
|
|
|
|
|
works better.
|
|
--HG--
rename : src/libffmpeg/Makefile.am => src/combined/ffmpeg/Makefile.am
rename : src/libffmpeg/ff_dvaudio_decoder.c => src/combined/ffmpeg/ff_dvaudio_decoder.c
rename : src/libffmpeg/ff_video_decoder.c => src/combined/ffmpeg/ff_video_decoder.c
rename : src/libffmpeg/ffmpeg_decoder.h => src/combined/ffmpeg/ffmpeg_decoder.h
|
|
work for both internal and external FFmpeg (with new layout).
|
|
--HG--
rename : src/combined/demux_wavpack.c => src/combined/wavpack_demuxer.c
|
|
and send it without IEC958 header otherwise - so the receivers can autodetect the raw DTS stream.
--HG--
extra : transplant_source : %7C%02Vm-%DF%B4%CD%8B%B9U3%A7%B9%EDT%3CZ%91%81
|
|
|
|
(Transplanted from f03669a2395d97a3e40615db1089af084a69d299)
|
|
|
|
--HG--
extra : transplant_source : %C2%84%E8%0E%FD%DE%D3%3E%FB%B8%AF%F3%80a%5E%B3v%C5%8B%08
|
|
--HG--
extra : transplant_source : %5C%D4ln%1C%B8Up%88%96R%09%1A%05HQ%3C%F8%CE%08
|
|
|
|
Should fix bug 35.
--HG--
extra : transplant_source : %DD%95%9F%A7%8D%01%BD%98%40%E4R%AAW%F2%ED%93%B2%DE%1A%E9
|
|
|
|
|
|
id3v2_istag has not the same signature in 1.1 and 1.2.
|
|
expected.
add code to set this attribute from xine and mention nvidia-settings, since the user may need to select a sync device as well.
|
|
--HG--
extra : transplant_source : %C0%D71D1%8CQ%889P%21%20%D7%F7%B5%F2T%FE%88%FA
|
|
This should allow big ID3v2 tag to be parsed (i mean tags with embedded pictures).
|
|
This should allow big ID3v2 tag to be parsed (i mean tags with embedded pictures).
(transplanted from ebb0d5507d3208f8e73af78f912230719d37830a)
--HG--
extra : transplant_source : %EB%B0%D5P%7D2%08%F8%E7%3A%F7%8F%91%220q%9D7%83%0A
|
|
|
|
Fixed bug 4 sample playback (nilbymouthclapton.112.mp3).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Make the tracknumber/tracktotal buffer larger (possible overflow).
|