The _mga/_xmga variables weren't changed to "no", causing a build
failure if mga/xmga support would have been otherwise enabled but was
only switched off because of the swscale test.
issue with PAFF seems solved to me, and disabled correct-pts causes
flickering with -ass (which of course should be fixed as well though).
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@31313 b3059339-0415-0410-9bf9-f77b7e298cf2
This avoids some issues with H.264 PAFF due to dropping PTS values too
early because only every second packet actually produced output.
Just keeping up to one additional pts value would have avoided this
particular issue as well, but this is more generic.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@31312 b3059339-0415-0410-9bf9-f77b7e298cf2
reasonable.
This avoids completely losing A-V sync e.g. when pts was not reordered correctly.
This was tested with http://samples.mplayerhq.hu/V-codecs/h264/PAFF/tv_cut.mkv
for this sample proper pts reordering is the correct solution, but more resilient
handling of the error case is still useful.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@31311 b3059339-0415-0410-9bf9-f77b7e298cf2
This avoids using swscale internals when compiling against a shared libswscale.
Patch inspired by Uoti Urpala's work in his git branch:
cd4e8dc1fa
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@31310 b3059339-0415-0410-9bf9-f77b7e298cf2
Commit 3f076c0fb3 ("options: move -a52drc to option struct") from
yesterday left out setting the default value of the option,
effectively changing the default from 1 to 0. Add the missing part to
change it back to 1.
Change demux_mkv to behave by default as it did with -idx before. The
index generation code in demux_mkv linearly scans the file up to the
seek timestamp (it doesn't read the whole file up front like some
other demuxers do). Doing that is probably a better default for files
with no index than rejecting the seek request and asking user to
specify -idx.
-a52drc range extension was already done earlier (and the svn commit
is buggy for ad_liba52). However keep the man page change (this is the
only part not skipped).
We don't want to use lavf for Matroska demuxing; it's questionable
whether that's a good idea even in svn, and the internal demuxer here
is definitely a better choice.
Instead of only relying on the MIME type, use the file extension as a
fallback for deciding which attachments are fonts and should be fed to
libass.
This also refactors the check into a separate function in mpcommon.
additionallym deprecate palette8torgb16 and its bgr variant without
replacement. These functions are not meant to be used by applications.
Discussed at: http://comments.gmane.org/gmane.comp.video.ffmpeg.devel/109340
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@31301 b3059339-0415-0410-9bf9-f77b7e298cf2
They contain exactly the same code as their 16bit variants, so this is
effectively code de-duplication.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@31298 b3059339-0415-0410-9bf9-f77b7e298cf2
This fixes subtitles duplication when seeking back in ass stream formated
with the "standard" format FFmpeg uses.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@31293 b3059339-0415-0410-9bf9-f77b7e298cf2
Commit fc39d48465 ("demux_mkv: store streams sequentially in
demuxer->[avs]_streams") had a copy-paste error causing it to look up
a video ID where it should have been an audio one. The most likely
visible symptom was a segfault when seeking while playing a
high-numbered audio track. Looks like I was careless with that
original commit, second bug in the same one...
