| Age | Commit message (Collapse) | Author |
|---|
|
1.2 series.
|
|
(transplanted from e9e85d6bcc7e9aafb1dc019f3505de2dafe940bf)
--HG--
extra : transplant_source : %E9%E8%5Dk%CC%7E%9A%AF%B1%DC%01%9F5%05%DE-%AF%E9%40%BF
|
|
size of an item for the number of items.
(transplanted from efc9d92af3d7927cbf5534b5612fd98af541ff95)
--HG--
extra : transplant_source : %EF%C9%D9%2A%F3%D7%92%7C%BFU4%B5a/%D9%8A%F5A%FF%95
|
|
elements by the size of the single element.
(transplanted from 512894f517c423fed0cadeca0d46c6d909403106)
--HG--
extra : transplant_source : Q%28%94%F5%17%C4%23%FE%D0%CA%DE%CA%0DF%C6%D9%09%401%06
|
|
Thanks to Alin Rad Pop, Secunia Research.
|
|
libdvdread uses the file length provided by the UDF fs of the title set IFO
files authoritative. I got a DVD which have parts of this file mapped outside
of the provided file size and according to my memory only the offsets in the
files matters in the standard.
This patch adjusts the internal knowledge of the filesize accordingly and at
least allows mplayer to play the dvd.
(Imported from Debian libdvdread 0.9.7-8)
|
|
--HG--
extra : transplant_source : %90%CC%97%8Fk%C1%FD%9C%A4%FB%0C%9E%07%F5A%B8%29o%EEo
|
|
|
|
|
|
|
|
CVE-2008-0225; ported from mplayer changeset 22821.
|
|
versions 0.10.6+
Note: the old code divided the frequency by 62.5. But, the ivtv driver
expects a different format. I changed the implementation in input_pvr such
that the frequency can be given as provided by cable companies, multiplied by
1000: e.g. 503250 for 503.250 MHz.
|
|
|
|
/usr/bin/totem-video-thumbnailer -s 128 ssh://user@hosts/path/to/video.ext
Will segfault.
All the time.
--HG--
extra : transplant_source : H%1EU%A5%3C%E6r%976%AA%C3%92%E5l%C7w%92dg.
|
|
ivtv now requires the video device to be re-opened when the input is changed.
|
|
|
|
Some instances of "key colour" remain; ffmpeg is unmodified.
This change has caused two strings with two translations to collide (the
strings have become identical since some instances already used "colour").
I have therefore arbitrarily dropped the first of the differing translations,
the one for the string at src/video_out/video_out_directfb.c:1365.
|
|
|
|
|
|
It changes some "defined (__FreeBSD__)" into "defined (__FreeBSD_kernel__)"
and "__FreeBSD_version" into "__FreeBSD_kernel_version".
The changes are performed on places, where feature of kernel is tested. On
some other places, feature of userland/libc is tested, on them "defined
(__FreeBSD__)" remains.
As proposed, include/configure.h cause __FreeBSD_kernel__ be defined if
__FreeBSD__ is defined.
--HG--
extra : transplant_source : %25%96K%05%E4Y%B15%94%60%15%FE1%8Ah%26Xy%8C/
|
|
load_channels was being called without checking the tuner fontend type, so
channels.conf could not be decoded. Tested for ATSC only.
|
|
|
|
--HG--
extra : transplant_source : %E0%D0%C5%8B%BEU%DD%24%5D7%1F%ADV%AD%EB%23%CBU%80%EB
|
|
I'm not sure whether they changed the Server response to the current
"last.fm proxy streamer" or if depending of what server you hit it answer
that rather than the previous "last.fm Streaming Server", so for now just
look if the Server response starts with "last.fm", which covers both
cases.
|
|
This file is released under GPL 2 or later that makes it safe for xine to use.
|
|
For contributed code, leave whatever the version we last synced for is using
to make simpler future syncs.
|
|
>
> /* 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).
|
|
|
|
|
|
Solaris definitions.
|
|
|
|
Inspired by a patch by Albert Lee.
|
|
|
|
|
|
|
|
|
|
|
|
Some plugins may have been missed due to them not being built here.
|
|
|
|
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).
|
|
development branche
Am Samstag, 26. Mai 2007 17:48 schrieb Darren Salt:
> Could you also try not reverting that and instead applying one or
> both of the attached patches? Both playback and eject need to be
> tested. You should use the drive's eject button, though there's no
> harm in also checking xine-lib's eject code.
Ok, here's a modified patch, a combination of your two patches, with a
little fix. It works fine here, pressing the vcd button on xine-ui
starts playing vcd's directly and when pressing the stop button, I can
eject the CD by pressing the eject button on the cd drive.
I hope it's ok for you.
--
Machs gut | http://www.iivs.de/schwinde/buerger/tremmel/
| http://packman.links2linux.de/
Manfred | http://www.knightsoft-net.de
|
|
|
