| Age | Commit message (Collapse) | Author |
|---|
|
|
|
--HG--
rename : src/combined/decoder_flac.c => src/combined/flac_decoder.c
rename : src/combined/demux_flac.c => src/combined/flac_demuxer.c
rename : src/libxineadec/nsf.c => src/combined/nsf_decoder.c
rename : src/demuxers/demux_nsf.c => src/combined/nsf_demuxer.c
rename : src/combined/combined_wavpack.c => src/combined/wavpack_combined.c
rename : src/combined/combined_wavpack.h => src/combined/wavpack_combined.h
rename : src/combined/decoder_wavpack.c => src/combined/wavpack_decoder.c
rename : src/combined/demux_wavpack.c => src/combined/wavpack_demuxer.c
rename : src/demuxers/demux_ogg.c => src/combined/xine_ogg_demuxer.c
rename : src/libxineadec/xine_speex_decoder.c => src/combined/xine_speex_decoder.c
rename : src/libxinevdec/xine_theora_decoder.c => src/combined/xine_theora_decoder.c
rename : src/libxineadec/xine_vorbis_decoder.c => src/combined/xine_vorbis_decoder.c
rename : src/liba52/xine_a52_decoder.c => src/libxineadec/xine_a52_decoder.c
rename : src/libdts/xine_dts_decoder.c => src/libxineadec/xine_dts_decoder.c
rename : src/libfaad/xine_faad_decoder.c => src/libxineadec/xine_faad_decoder.c
rename : src/libmusepack/xine_musepack_decoder.c => src/libxineadec/xine_musepack_decoder.c
|
|
For contributed code, leave whatever the version we last synced for is using
to make simpler future syncs.
|
|
Spanish translation merge needs checking.
|
|
>
> /* Special codes used when specifying changer slots. */
> #define CDSL_NONE (INT_MAX-1)
> #define CDSL_CURRENT INT_MAX
|
|
|
|
|
|
|
|
|
|
|
|
According to bug 1773769, this breaks foo->open().
The fix (as used in Ville Skyttä's patch, which doesn't cover all cases) is
to replace this with (foo->open)().
This patch was generated using
sed -i -re 's/(([[:alnum:]_]+(->|\.))+open) ?\(/(\1) (/' `grep '[>.]open \?(' include -rIl`
One change (in a comment) is not committed.
|
|
|
|
Thanks to Harald Sitter from Amarok team for reporting a testcase.
|
|
|
|
If there's no signal, the tuner never goes to FE_TIMEDOUT. Add a separate
timeout, to prevent xine waiting forever in these situations.
|
|
We have seen input_rtp lock up in use, and traced the problem to the separate
tail/head locks on the input buffer. Reduce to a single lock, increasing lock
contention between the reader and the writer, but removing the previous
deadlock risk.
Also use select() before recv(), to ensure that we never wait forever for
packets (e.g. if we're trying to receive a multicast stream, but an
administrator has blocked all multicast packets to the device - iptables -A
INPUT --dst 224.0.0.0/4 -j DROP induces this failure for testing).
|
|
Add a configuration option, to let input_v4l users select their local TV
standard.
|
|
Make the DVB GUI configurable by config entry, for kiosk applications
|
|
|
|
|
|
|
|
|
|
|
|
Solaris definitions (1.2 branch commit).
|
|
Solaris definitions.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Inspired by a patch by Albert Lee.
|
|
|
|
|
|
|
|
Hopefully, I've applied all of the $(LTLIBINTL) changes correctly...
|
|
|
|
|
|
|
|
|
|
SYNC string in the read data; if found, send a XINE_EVENT_UI_CHANNELS_CHANGED event, so that the frontend can go read the new metadata.
|
|
|
|
|
|
Some plugins may have been missed due to them not being built here.
|
|
|
|
read() function, and declare a new buf variable in the function as needed.
|
|
buf parameter, so that any kind of variable can be passed through it.
|
|
|
|
|
|
Hi, I've been tracking down a very odd bug this afternoon. As it turns
out it is caused by enabling xine's mmap() support for the input_file.c.
I'm running 32 bit linux 2.6.21. The file in question is 0x10e4da000
bytes long (you can probably guess what kind of bug this is by now :)
Anyway, the issue stems from the definition of mmap():
void *mmap(void *start, size_t length, int prot, int flags, int fd,
off_t offset);
compare this to the definition of st_size in struct stat:
off_t st_size; /* total size, in bytes */
On my machine (in input_file.c) sizeof(size_t) ==4, whilst
sizeof(off_t) == 8. However the compiler doesn't generate a warning
when the following is done in xine's code:
if ( (this->mmap_base = mmap(NULL, sbuf.st_size, PROT_READ,
MAP_SHARED, this->fh, 0)) != (void*)-1
So it silently truncates the upper part of the length. Obviously you
cannot mmap() a file that large into (32 bit) memory anyway, but as it turns
out, mmapping() 0xe4da000 succeeds, which causes... problems.
The patch (against xine-lib 1.1.6) does two things:
* Check that the length will not be truncated, while still allowing
for mmap()s of large files under 64 bit OSes.
* A correctness fix: if mmap() fails, this->mmap_base will be set to
0xffffffff. Later on when the file is closed, this means it was
attempting to do munmap(0xffffffff).
|
