Age | Commit message (Collapse) | Author |
|
|
|
DEMUX_FINISHED from send_header
|
|
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/
|
|
|
|
|
|
Fixed interpretation of "videodatarate" variable.
Export audio bitrate information when variable "audiodatarate" is found.
|
|
That should prevent xine from discarding the first keyframe on non-seekable stream.
|
|
reduced by 50%
|
|
|
|
discard all buffers before calling fifo_wait_empty
|
|
section_length is sometimes 0; this leads to the CRC32 calculation being
performed with a data length of -1 bytes, a.k.a. 4294967295 bytes.
(Reported by Johannes Zellner.)
--HG--
extra : transplant_source : %B6m%D0%0C%84%DA%40%C3%0B%06%11%B1%11%9El%A8%1F%95%27%E5
|
|
load_channels was being called without checking the tuner fontend type, so
channels.conf could not be decoded. Tested for ATSC only.
|
|
|
|
Some servers don't set this information, thus the demuxer fails.
|
|
|
|
This is because, while in shared mode the default resolution is taken from directfb config,
in fullscreen mode the default resolution comes from fbdev configuration.
(transplanted from 2ce76206b5c10b6f9cfc55a9edb0d883bfb446a2)
--HG--
extra : transplant_source : %2C%E7b%06%B5%C1%0Bo%9C%FCU%A9%ED%B0%D8%83%BF%B4F%A2
|
|
(transplanted from 3bea001775a81a2c784e000794ea5cc6d34dc40d)
--HG--
extra : transplant_source : %3B%EA%00%17u%A8%1A%2CxN%00%07%94%EA%5C%C6%D3M%C4%0D
|
|
--HG--
extra : transplant_source : %E0%D0%C5%8B%BEU%DD%24%5D7%1F%ADV%AD%EB%23%CBU%80%EB
|
|
For H.264 content, VO_INTERLACED_FLAG must be set all the time and not only
for interlaced frames. Frames should be allocated so that size is a multiple
of a marcoblock (16x16). Any excess pixels are cropped away. top_field_first
and progressive_frame can be transferred always, not just in demux_mpeg_pes
context. But for bad frames it doesn't make sense to transfer those fields
as the information would be from the previous frame and could be incorrect
for the current frame. Thus, the workaround for demux_mpeg_pes cannot rely
on these fields either and needs to use a separate variable to detect fields
being sent as frames.
--HG--
extra : transplant_source : %A8%25%B9I%A4%5B%E5%AE%DD%EF_c%E35%CBSRn%22%A4
|
|
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.
|
|
* Use arrays and loops instead of chained if()s.
This reduces code size a little.
* Try to dlopen drvc.so instead of just checking for its existence.
The old code could, for example, try to use a dir containing 32-bit libs
on a 64-bit system. (Not that I'd expect this to happen, of course...)
|
|
Ref. http://bugzilla.gnome.org/show_bug.cgi?id=484768#c12
|
|
|
|
The changes include setting VO_INTERLACED_FLAG for interlaced frames,
adjusting frame height to a multiple of 32 lines (i. e. the height of
one macroblock per field) and cropping away the extra lines, setting
progressive_frame and top_field_first as supplied by FFmpeg, fixing
the workaround for demux_mpep_pes sending fields as frames and bad
frame allocation (i. e. use at least 16x32 pixels).
--HG--
extra : transplant_source : %C7c%951J%F5o%C5%F1%16%B4%05%95%D0J%C0j%7F%E6%F8
|
|
The last fix to PTS wrap detection could not handle streams with A/V
offsets larger than 3 seconds. The improved version can deal with
them now.
--HG--
extra : transplant_source : %89%1F%7E%12%D5r%A8%CE%95N%BAG%96%02%60%0C%10%9Aar
|
|
Seen in an AVI in the wild; apparently generated by mencoder.
|
|
>
> /* Special codes used when specifying changer slots. */
> #define CDSL_NONE (INT_MAX-1)
> #define CDSL_CURRENT INT_MAX
|
|
Found this little problem (was causing some "uninitialised variable
accesses" under valgrind) while implementing Podcast reading in RB using
Totem's playlist parser.
--HG--
extra : transplant_source : J%D9/%16%E2i%B2%84%FA%8A%85%888N%A5%B4%16s%BD%16
|
|
When demux_mpeg_pes uses FFmpeg for H.264 streams, it doesn't set
video_step as it doesn't know it. But FFmpeg provides it deriveable
from time_base. So let's use the derived value as long as it isn't
set explicitly.
Furthermore, demux_mpeg_pes set's BUF_FLAG_FRAME_END whenever it
encounters a H.264 access unit delimiter, which appears between
fields or frames, but it doesn't know, whether it deals with fields
or frames. avcodec_decode_video() on the other hand sets got_picture
even when the decoded data specifies just a field. But it also sets
the flag interlaced_frame. So let's use this flag to halve video_step
in order to show the decoded images just for a field duration.
--HG--
extra : transplant_source : %40Q%E3fO%3C%E7%A0%02%BA%9D%1D%BD%81%F0f-%EAs%87
|
|
(wait the main stream to fully initialize)
prevents division by zero in draw_subtitle().
|
|
|
|
(transplanted from 2b2f2adc8a1e0a05d89354ff259f7b2a331aa071)
--HG--
extra : transplant_source : %2B/%2A%DC%8A%1E%0A%05%D8%93T%FF%25%9F%7B%2A3%1A%A0q
|
|
I managed to miss one from my earlier patch, though I could've sworn I
checked this.
Add (prefix)/lib64/real into the real codec path list. It is encountered
in the 64bit PLF Mandriva real-codecs package.
|
|
Successive MPEG1/2 B frames (each with a slice #9) could incorrectly
lead to the assumption of a H.264 stream, as sequence or group start
codes were not seen for these frames. So the detection logic
interpreted the slice #9 start codes as H.264 access unit delimiters
and therefore incorrectly switched to H.264 buffer type instead of
MPEG1/2. Extending the detection logic to consider MPEG1/2 picture
start codes as well (which do not appear in H.264 streams), prevents
false positives.
|
|
These cheats where hiding a frame allocation bug in FFmpeg decoder
which was previously fixed.
|
|
External FFmpeg has recently gained multithreaded H.264 decoding
and to make use of this feature, it is necessary to inform FFmpeg
about the maximum number of threads it may use for decoding.
|
|
When a stream doesn't start with an IDR frame, there will be several
seconds of bad frames and not setting PTS on those frames causes an
unnecessary delay in syncing audio and video.
|
|
When a stream doesn't start with an IDR frame, then frame size isn't
known, but all frames up to an IDR frame are reported as bad frames.
In such a case, a frame of size 1x1 will be allocated as xine-lib
cannot handle 0x0 frames properly, i. e. many output drivers simply
crash.
|
|
|
|
The attached patch to xine-lib adds two more real codec search paths.
/usr/lib/real is encountered in PLF packages for Mandriva, and
/usr/lib/RealPlayer10GOLD/codecs is encountered in RealPlayer package of
Mandriva.
|
|
|
|
Only build-tested due to lack of sample data.
|
|
|
|
|
|
|
|
|
|
|
|
It happend that the previously shown frame was still on screen
while the decoder reused it already and the result was a mixed
picture on screen.
Protection is easy: just keep a reference to previously shown
frame and it cannot be reused by the decoder until a frame
duration has passed which should be sufficient to see the
current frame on screen.
Such referencing has already been implemented although it was
not used for deinterlacing. Therefore it had been disabled to
get an additional frame for decoding in coping with dropped
frames.
The change reenables referencing the previously shown frame.
|