| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
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.
|
|
|
|
|
|
Certain ffmpeg audio decoders use 32 bit float samples internally (wma,
eac3, ...). They are then exported to the calling application as 16 bit
integer.
That conversion is done by faster sse2 code if your processor supports it.
However, sse2 instructions require data buffers to be 16 byte aligned, or
hit a segfault otherwise.
Plain malloc() / realloc() ensures only 8 byte alignment, giving a 50%
chance of a crash.
FFmpeg internally uses aligned buffers a lot. It seems to be a good idea to
do likewise for input buffers as well, even if current version does not
strictly need it yet.
Libavutil/av_realloc() has a bug that can break the alignment when enlarging
an existing buffer. Thus I included a fixed version of it within
ff_audio_decoder.c.
|
|
|
|
|
|
|
|
pids.
|
|
negative value (that results writing out of buffer when buffering payload). Check buffer size before checking substream header bytes.
|
|
skips pes header
|
|
parsing pts.
|
|
6 is not enough ; anything less than 9 is invalid (header length byte at [8] can't be used if it is outside of buffer). Moved check to beginning of parse_pes_header() to avoid reading outside of buffer.
|
|
stream_id >= 0xbc)
|
|
|
|
|
|
|
|
|
|
4 lowest bits are 0 --> Handle as 24-bit BluRay PCM.
|
|
bit BE, not in DVD format.
|
|
|
|
|
|
|
|
hide/show. Hide overlay when there are no objects to display.
|
|
point, not at end of display set
|
|
This is a backport of the 1.2 code that was commited to utilize the new API
provided by FFmpeg for awhile now but this is especially important because
the old API has been eliminated all together from said copies of FFmpeg.
|
|
|
|
First of all, it improves the qt demuxer, ensuring that 24-bit audio is
marked appropriately, and detecting little vs. big endian audio. It also
adjusts the buffer size when audio is 24-bit, ensuring that samples aren't
chopped in half (8192 does not divide evenly into 3 byte samples).
Secondly, in the lpcm decoder, the patch distinguishes between standard
24-bit lpcm (big and little endian) and special DVD-format 24-bit lpcm (see
http://wiki.multimedia.cx/index.php?title=PCM) and now handles both, instead
of only handling the DVD format.
The result is that xine now correctly plays all the 24-bit lpcm samples I
throw at it, whereas before only a few worked.
|
|
demux_aac.c looks for 2 signatures in the given stream to detect if it is an
AAC stream, however only the absence of the second signature is used to rule
out a positive match. This may lead to false positives.
|
|
decoder thread.
Raising nice priority is not limited to root user only on modern unix/linux systems.
So a log message about failure is helpful to everyone.
|
|
recalculation of displayed window.
This issue comes up when a post plugin only changes the cropping parameters of a frame without changing width, height or ratio of the frame.
|
|
Resulting left and right cropping parameters should be multiple of 2.
Left cropping offset calculation to YUY2 frames fixed.
|
|
downwards within post
plugins because this corrupted the receiving frame acceleration data.
This issue occurs typically when a post plugin retrieves a new frame from the video out stage and
then does a _x_post_frame_copy_down from the frame that is delivered from the video decoder.
In this case the two frames are unrelated and acceleration data get messed up.
|
|
Video out flushes the decoder when it runs out of images for displaying,
because the decoder hasn't delivered new frames for quite a while. But
flushing the decoder causes decoding errors for images after the flush.
It is likely that the flush is still required for the issues it was
introduced (DVD still images), but they may have been resolved differently
meanwhile (e. g. by supporting sequence end code). So for now a
configureable option has been introduced which keeps the current behaviour
by default.
--HG--
extra : transplant_source : %AB%B3u%1F%E7%3D%10%0C%3D%40%B2%B0%CB%8E%84%FE%E6%87p%AA
|
|
Flushing the decoder at a pts wrap causes decoding errors for images after
the pts wrap. It is likely that the flush is still required for the issues
it was introduced (DVD still images), but they may have been resolved
differently meanwhile (e. g. by supporting sequence end code). So for now
a configureable option has been introduced which keeps the current behaviour
by default.
--HG--
extra : transplant_source : %9Cs%D1%9A%E5Sk%27%18%A6%94%5D%AB%0Dd%CA%7E%7E%BA%FD
|
|
H.264 decoders store a couple of frames in their display picture buffer.
Calling flush before discontinuity my yield images with pts beyond pts
boundery and therefore cause clock errors.
Calling discontinuity before flush resets all pts to 0 before yielding
the images.
--HG--
extra : transplant_source : %9CNpV%B5%83%83%23%F5%C3%09%E43%E2%DFo.%7E%D9%C7
|
|
|
|
|
|
--HG--
extra : rebase_source : 97225919cd1c6c2327ccbb43b17a6b049e82946c
|
|
There was added memory limits checks, which will improve stability when playing
corrupted NSF files.
|
|
|
|
|
|
|
|
Reserved space on the start of block_data for the headers during reading to
avoid temporary memory buffers and memcpy()'s.
|
|
|
