| Age | Commit message (Collapse) | Author |
|---|
|
Now all used decoders work without header/preview buffers.
|
|
|
|
--HG--
extra : rebase_source : dd06e80a4a10ee355d073e77044440a1c09dc76e
|
|
|
|
There are two functions that actually set this flag:
int _x_set_file_close_on_exec()
int _x_set_socket_close_on_exec()
(We need two functions because file descriptors and sockets
are not the same under WIN32 - of course).
These function have been assigned "internal" visibility so
that they can be used throughout libxine.so itself while still
not being exported to the global symbol table. In other words,
they're both as close to being "static" as I can make them.
|
|
xine_socket_cloexec() function.
|
|
|
|
|
|
|
|
This patch creates two utility functions:
int open_cloexec(pathname, flags)
int create_cloexec(pathname, flags, mode)
These return a file descriptor with the CLOEXEC flag set, to ensure
that the descriptor is not inherited across a fork/exec operation.
The sockets returned by:
_x_io_tcp_connect_ipv4()
_x_io_tcp_connect()
now also have their CLOEXEC flag set.
|
|
|
|
|
|
|
|
Codec was never opened when using mpeg12 mode.
|
|
(TS_LOG) only when condition is defined
|
|
valid value for PCR)
|
|
This makes HEADERS optional for codecs that don't require extradata.
imported patch 10124.diff
|
|
imported patch 10123.diff
|
|
imported patch 10121.diff
|
|
imported patch 10120.diff
|
|
imported patch 10119.diff
|
|
imported patch 10116.diff
|
|
imported patch 10115.diff
|
|
|
|
handling to separate function.
|
|
|
|
|
|
|
|
|
|
libtool 2.4 does not work with automake-1.8:
Running aclocal: aclocal: macro `_LT_DECL_SED' required but not defined
aclocal: macro `_LT_FUNC_STRIPNAME_CNF' required but not defined
|
|
The order of programs is assumed not to change among otherwise identical PATs. (Not an unreasonable assumption).
|
|
So why does it try to handle SPU_DVD packets? DVB subtitles don't seem to work yet anyway.
|
|
Otherwise we risk not marking the first audio frame in each stream with
BUF_FLAG_HEADER.
This is the final fix for https://bugs.xine-project.org/show_bug.cgi?id=403
|
|
The only way to identify which codec a stream is using is to wait for a
PMT, at which time we know all the PIDs anyway. The codec ID is in no way
related to (0x100 + stream ID), which is what this code was trying to do.
Such a codec ID just hits the default path of "Unknown, using MPEG instead".
|
|
and that each stream object is removed from its parent xine object's
list before it starts destroying itself.
|
|
audio channels. So we must keep discarding packets that cannot be used to
initialise the codec until we receive one that can be.
|
|
|
|
|
|
|
|
|
|
|
|
The problem
When watching live DVB, data is delivered strictly at the broadcasters
speed. We cannot change it through server commands. Our local systems clock
usually runs slightly faster or slower than that, causing a/v fifos to run
empty or full after a few minutes.
Standard network buffering control only handles the first case by pausing
the engine (not nice). The latter case ends up in severe stuttering and an
a/v lag of several seconds (annoying).
I tried quite a few differnt algorithms, and this one made it:
a 3 point controller.
There is a target buffer fill window with a center and some tolerated width:
Minimum:
definition: 1 second
safety: clamped to 38% of fio size
action: switch playback speed to 99.5%
Center:
definition: 2 seconds
safety: clamped to 73% fifo size
action: switch to normal playback speed
Maximum:
definition: 3 seconds
safety: clamped to 98% fifo fill
action: switch playback speed to 100.5%
If the usual dvb audio to video muxing delay is more than 1 second, center
time is increased. On low bitrate radio, window width is increased.
Real TVs do adjust playback audio sampling rate to follow delivery speed.
Some PC sound cards can do that, too. It could be implemented transparently
(although I don't know yet how). This comes quite close, resampling audio to
stretch.
That half percent is large enough to cover clock deviation, and it is small
enough not to cause audible pitch bending. Speed control consists of
adjusting SCR and telling audio out. Doing just the first will cause
metronom to drop and/or insert whole audio frames, not nice with music.
BTW. this one needs demux_ts to send BUF_FLAG_FRAME_START.
|
|
I've now tested this patch on Fedora 15 (FFmpeg 0.7) and Fedora 14 (FFmpeg
0.6), and am happy to report that it works fine on F15 and doesn't break
xine-lib on F14. On F14, it also has the happy side effect of no longer
trying to decode an LATM AAC stream with the xineplug_decode_faad.so plugin.
(Which was something which never ended well anyway.)
|
|
|
|
|
|
avcodec_thread_init() was deprecated in lavc 52.112.0 (2011-02-09)
|
|
This is a small mistake, but I'm fairly sure the index should be "j" and not
"i".
|
|
When watching TV with Kaffeine I frequently had complete engine lockups.
Multiple mutexes were waiting on each other. net_buf_ctrl requires the
demuxer to keep running while playback is still paused.
The diff might look a bit confusing. Basically, all I did was to replace
phtread_mutex_lock ();
...
pthread_mutex_unlock ();
with
if (pthread_mutex_trylock ()) {
...
pthread_mutex_unlock ();
}
at a place where it does the least damage.
|
|
xine_play () gets suspended after start or seek until first frame gets
displayed. This often wont work on slow machines when first frame gets
dropped because its too old. Consequently, UI freezes for full 10 seconds.
Let's wake up xine_play when this happens as well.
OK, this is a luxury convenience fix ;-)
|
|
Audio decoder loop creates a sorted map of available audio channels on the
fly. If neither user nor dvdnav intervene, it will pass the first (= lowest
index) audio channel to decoders.
Now imagine a TV recording with 2 audio channels:
audio.0: eac3 5.1 (fra)
audio.1: eac3 stereo (qaa)
By chance, first audio frame to be demuxed is for channel #1.
Track map will be
[0]: eac3, channel 1
Audio loop opens ffmpeg audio decoder / stereo out. Fine.
Then, first frame for channel #0 comes in.
[0]: eac3, channel 0
[1]: eac3, channel 1
Both are same codec, so audio loop just switches to channel 0 without
further notice. Audio decoder then runs into a mem leak, or worse, crashes
audio out who still thinks we're only stereo.
Whenever we insert something at track map index 0, and its going to be
auto-selected later, reset current codec type. This forces a clean
decoder/output switch.
|
