see [MPlayer-dev-eng] [PATCH] cleanup/uniformize real video packetizing
patch blessed by Roberto
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28503 b3059339-0415-0410-9bf9-f77b7e298cf2
The following commits are reverted partially or completely:
"a valid ASS line contains 9 ',' before actual text"
"demux_mkv: output correctly formated ASS packets"
"libass: add a new ass_process_data() to process demuxed subtitle packets"
These commits converted the internal representation of SSA/ASS
subtitle packets from the format used by Matroska to a custom format
where each packet has contents exactly matching one line in complete
SSA script files. AFAIK no files natively use such a format for muxed
subtitles. The stated reason for this change was to use a format that
could in principle be muxed into a maximal number of containers. SSA
subtitles do not have an implicit duration so both start time and
duration or end time need to be specified explicitly; the new format
moved timing information inside the codec packet data so it could be
muxed without modification into containers that can represent only
start time at the container level. However such a change is wrong from
the viewpoint of program architecture. Timing information belongs to
the demuxer level, but these commits moved not only the duration but
also the authoritative value of the start time to inside the codec
data. Additionally the new format lost the value of the Matroska
ReadOrder field which is used by MPlayer.
This commit changes the internal packet format back to that used by
Matroska and makes the internal Matroska demuxer output that format
again. Libavformat still outputs the "new" format; it could be
converted back to the Matroska format in demux_lavf.c, but I'm not
adding that code at least yet. The current lavf code has similar
problems as the reverted code in MPlayer, and it also currently fails
to provide any way to access the value of the ReadOrder field. I hope
that the lavf side will be improved; if it isn't conversion can be
added later. For now I'll make MPlayer default to the internal Matroska
demuxer instead of the lavf one in a separate commit.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@27550 b3059339-0415-0410-9bf9-f77b7e298cf2
Replace all USE_ prefixes by CONFIG_ prefixes to indicate
options which are configurable.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@27373 b3059339-0415-0410-9bf9-f77b7e298cf2
libmpdemux/demux_mkv.c:2242: warning: 'demux_mkv_reverse_id' defined but not used
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@26784 b3059339-0415-0410-9bf9-f77b7e298cf2
The first default track is chosen for playback if language-based selection
failes. Additionally, for audio tracks, the first one is chosen if there are
no default tracks at all.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@26301 b3059339-0415-0410-9bf9-f77b7e298cf2
of letting individual demuxers and stream readers do their nasty job
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@25987 b3059339-0415-0410-9bf9-f77b7e298cf2
A better solution should be considered later, esp. for the many
broken demuxers that do not treat these flags correctly.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@25911 b3059339-0415-0410-9bf9-f77b7e298cf2
These attachments are passed to libass after demuxer is opened.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@25686 b3059339-0415-0410-9bf9-f77b7e298cf2
This makes the code simpler and more like the other demuxers,
allowing to remove some special cases in mplayer.c
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@23618 b3059339-0415-0410-9bf9-f77b7e298cf2
The seek code searching for the closest position in the index used
"int64_t min_diff=0xFFFFFFFL" as the initial "further from the goal
than any real alternative" value. The unit is milliseconds so seeks more
than about 75 hours past the end of the file would fail to recognize the
last index position as the best match. This was triggered in practice by
chapter seek code which apparently uses a seek of 1000000000 seconds
forward to mean "seek to the end". The practical effect was that trying
to seek to the next chapter in a file without chapters made MPlayer
block until it finished reading the file from the current position to
the end.
Fixed by increasing the initial value from FFFFFFF to FFFFFFFFFFFFFFF.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@23592 b3059339-0415-0410-9bf9-f77b7e298cf2
Those values are not needed anyway.
This fixes stream copying from mkv with mencoder.
Patch by Trent Piepho.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@23534 b3059339-0415-0410-9bf9-f77b7e298cf2