| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
After adding support for PTS reordering some time ago, any codecs using direct
rendering did no longer pass PTS values to the images due to missing support
for reordered_opaque in xine-lib's custom get_buffer() function.
With this fix, A/V sync should now be as before or even better, due to PTS
reordering (the intent of the earlier changesets).
|
|
|
|
|
|
PIX_FMT_RGBA32 was #defined to PIX_FMT_RGB32 since 2006.
|
|
Their sed doesn't have \s and their tail doesn't handle -ve line counts.
|
|
Don't give up immediately if demux_unstick_ao_loop() reports that xine might
be stuck, because it's not necessarily so.
According to my tests, this fixes
http://bugs.kde.org/show_bug.cgi?id=180339#c42 and
http://bugs.debian.org/514114.
This has been tested with Amarok and kde 4.1.x (with phonon) and kaffeine.
|
|
|
|
|
|
This is intended to make it easier to add new codecs without breaking
compilation with older ffmpeg and to see which codecs need to be added.
|
|
|
|
|
|
|
|
to early
The current code turns of PTS tagging as soon as a match is found. But depending
on picture reordering, there may be later frames which still have the tag. The result
is that most likely the highest bit is set which makes the PTS values large negative
numbers which cause a clock error and make streams unplayable.
To fix this issue, a stable counter is introduced. The two passes of PTS tagging are
now switched after the tag has been seen stable for 100 frames. This should protect
us from picture reordering issues.
--HG--
extra : transplant_source : I%2A%BBi%A5nb/%5E%12%9Ay%7B%BAj%7D%0B%16%0By
|
|
This covers the internal snapshot and the version in Debian lenny.
|
|
|
|
now invalid.
But as PTS values are stored in FFmpeg's decoder, there is no way to reset them to 0.
Therefore PTS tagging has been introduced. At discontinuity a tag is generated and
applied to all new PTS values. Any returned PTS value is checked for this tag and
outdated PTS values are reset to 0. When the tag appears on returned PTS values then
tagging is reset.
|
|
order.
Attaching buffer PTS, which are in decoding order, to decoded images is
simply wrong. FFmpeg meanwhile provides a way to pass PTS values through
its decoder too. As a result they get reordered to display order and can
be attached to the decoded frames.
|
|
playback stopped.
|
|
|
|
- goom initialization
- matroska playing recent files with AAC
- replace free() by ffmpeg's av_free() in ff decoders
|
|
--HG--
extra : transplant_source : %A7%3F%40%BA%27%15%89%8B%F8%28%27%E6%EF%B8%22E%F1%AE%F8%D3
|
|
This could happen where the actual image height is not a multiple of 16.
--HG--
extra : transplant_source : %10%BD%8C%FE%BA%CA0%D5k%8A%9CH%DD%B1-%A7E4%CD%E6
|
|
There is an integer overflow bug in ff_audio_decode_data().
A crafted file could cause heap crash.
--HG--
extra : transplant_source : FxpH6%A3%B7%C5%DA9%5B%F6h%AFKm%93%EA%1Bv
|
|
|
|
|
|
Also don't reset memory after it's allocated if we do that with
calloc.
|
|
The xine_xmalloc() function is going to be deprecated, as its
behaviour is rarely needed as such, and it's thus misused.
With this, almost all uses of xine_xmalloc() with static size (for
instance the value returned by sizeof()) or with a size that is
guaranteed not to be zero (like strlen()+1) are replaced with calls to
either calloc(1, ...) or malloc().
malloc() is used whenever the allocated memory is going to be
immediately overwritten, while calloc() is used in every other case,
as it sets the whole memory area to zero.
--HG--
extra : transplant_source : %8F%98%EC%02%1E%83%F0s%06X%83C%205Y%80%B12%CC%E1
|
|
Occasionally when playing h264-encoded files, green blocks will appear
at the edges of the frame, and get smeared around (following the motion
vectors, of course). This bug has existing in Xine for well over a
year, and I keep hoping it will be fixed, but it never was.
I recently learned that gstreamer had a similar problem and it was fixed
last year. With this as a hint, I found
http://bugzilla.gnome.org/show_bug.cgi?id=364139 and the patch attached
to that bug.
I've adapted that patch to xine, and it is attached. I have compared
clips before and after applying this patch, and in all cases the green
artifacts have gone away, and I have seen no negative side effects.
|
|
|
|
|
|
|
|
|
|
|
|
This patch drops support for RV20.
|
|
|
|
|
|
The source remains compilable with older ffmpeg, whether internal or external.
--HG--
rename : src/libffmpeg/Makefile.am => src/combined/ffmpeg/Makefile.am
rename : src/libffmpeg/ff_audio_decoder.c => src/combined/ffmpeg/ff_audio_decoder.c
rename : src/libffmpeg/ff_dvaudio_decoder.c => src/combined/ffmpeg/ff_dvaudio_decoder.c
rename : src/libffmpeg/ff_mpeg_parser.c => src/combined/ffmpeg/ff_mpeg_parser.c
rename : src/libffmpeg/ff_mpeg_parser.h => src/combined/ffmpeg/ff_mpeg_parser.h
rename : src/libffmpeg/ff_video_decoder.c => src/combined/ffmpeg/ff_video_decoder.c
rename : src/libffmpeg/ffmpeg_decoder.c => src/combined/ffmpeg/ffmpeg_decoder.c
rename : src/libffmpeg/ffmpeg_decoder.h => src/combined/ffmpeg/ffmpeg_decoder.h
rename : src/libffmpeg/ffmpeg_encoder.c => src/combined/ffmpeg/ffmpeg_encoder.c
|
