subreader.c (before this commit renamed to demux_subreader.c) was
special cased to the -sub option. The plan is using the normal demuxer
codepath for all subtitle formats (so we can prefer libavformat demuxers
for most formats).
There are some subtle changes. The probe size is restricted to 32 KB
(instead of unlimitted + giving up after 100 lines of input). For
formats like MicroDVD, the video FPS isn't used anymore, because it's
not available on the subtitle demuxer level. Instead, hardcode it to
23.976 FPS (libavformat seems to do the same). The user can probably
still use -sub-fps to fix the timing. Checking the file extension for
".utf"/".utf8"/".utf-8" is simply removed (seems worthless, was in the
way, and I've never seen this anywhere).
If a subtitle is external, read it completely and add all subtitle
events in advance when the subtitle track is selected. This is done
for text subtitles only. (Note that subreader.c and subtitles loaded
with libass are different and don't have anything to do with this
commit.)
Before this, subtitle packets were returned as data ptr/len pairs, and
mplayer.c got the rest (pts and duration) directly from the demuxer
data structures. Then mplayer.c reassembled the packet data structure
again.
Pass packets directly instead. The mplayer.c side stays a bit awkward,
because the (now by default unused) DVD path keeps getting in the way.
In demux.c there's lots of weird stuff (3 functions that read packets,
really?), but we want to keep the code equivalent for now to avoid
hitting weird issues and corner cases.
Subtitle files are opened in mplayer.c, not using the demuxer
infrastructure in general. Pretend that this is not the case (outside of
the loading code) by opening a pseudo demuxer that does nothing. One
advantage is that the initialization code is now the same, and there's
no confusion about what the difference between track->stream,
track->sh_sub and mpctx->sh_sub is supposed to be.
This is a bit stupid, and it would be much better if there were proper
subtitle demuxers (there are many in recent FFmpeg, but not Libav). So
for now this is just a transition to a more proper architecture. Look
at demux_sub like an artifical limb: it's ugly, but don't hate it - it
helps you to get on with your life.
The frontend doesn't use this.
Also use double for returning the chapter times. Everything uses double
for times, and there's no reason to use float here.
Some preparations to simplify demux_mkv and demux_lavf.
struct demux_stream manages state for each stream type that is being
demuxed (audio/video/sub). demux_stream is rather annoying, especially
the id and sh members, which are often used by the demuxers to determine
current stream and so on. Demuxers don't really have to access this,
except for testing whether a stream is selected and to add packets.
Add a new_sh_stream(), which allows creating streams without having the
caller specify any kind of stream ID. Demuxers should just use sh_stream
pointers, instead of multiple kinds of IDs and indexes.
Matroska files can contain multiple segments, which are literally
further Matroska files appended to the main file. They can be referenced
by segment linking.
While this is an extraordinarily useless and dumb feature, we support it
for the hell of it.
This is implemented by adding a further demuxer parameter for skipping
segments. When scanning for linked segments, each file is opened
multiple times, until there are no further segments found. Each segment
will have a separate demuxer instance (with a separate file handle
etc.).
It appears the Matroska spec. has an even worse feature for segments:
live streaming can completely reconfigure the stream by starting a new
segment. We won't add support for it, because there are 0 people on this
earth who think Matroska life streaming is a good idea. (As opposed to
serving Matroska/WebM files via HTTP.)
The condition that checked whether the chapters are out of order and
should be sorted was inverted. This likely wasn't noticed in testing,
because even if the chapters are unsorted, if the last two chapters
were sorted, the rest got sorted too.
Instead of doing this silly check, always sort the chapters after
demuxer initialization. Also make sure the sort order is stable in case
chapter start times are the same (original_index check).
Makes sure that seeking to a given time position shows the subtitle at
that position. This can fail if the subtitle packet is not close enough
to the seek target. Always enabled for hr-seeks, and can be manually
enabled for normal seeks with --mkv-subtitle-preroll.
This helps displaying subtitles correctly with ordered chapters. When
switching ordered chapter segments, a seek is performed. If the subtitle
is timed slightly before the start of the segment, it normally won't be
demuxed. This is a problem with all seeks, but in this case normal
playback is affected. Since switching segments always uses hr-seeks,
the code added by this commit is always active in this situation.
If no subtitles are selected or the subtitles come from an external
file, the demuxer should behave exactly as before this commit.
Emulate percentage-seeks (SEEK_FACTOR) as normal time-seeks if possible.
This fixes some issues with (let's call it) low quality implementations
of SEEK_FACTOR (e.g. demux_mkv basically interprets this as byte-seek,
and also seeking to 99.9% makes it seek back to the start).
For weird MPEG formats the demuxer level SEEK_FACTOR is still used.
These formats, which can have timestamp resets, are identified by
setting demuxer->ts_resets_possible to true.
Also, have get_current_pos_ratio() follow the same rules, and calculate
the percentage position with the file position if timestamp resets are
possible.
This actually fixes percentage-seeks in .ts files with demux_lavf.c.
This kind of seek is not really used now, but it will be more important
when we add a progress bar.
Note: seeking in chained ogg files is still completely broken. The main
issue is that ffmpeg doesn't provide a sane API for dealing with
timestamp resets, and trying to do byte seeks with ogg confuses demuxer
and decoder (or something like this) and just does random things.
(Tested with two concatenated flac-in-ogg files).
The percent position is used for the OSD, the status line, and for the
OSD bar (shown on seeks). By default, the PTS of the last demuxed packet
was used to calculate it. This led to a "jumpy" display when the
percentage value (casted to int) was changing. The reasons for this were
the presence of video frame reordering (packet PTS is not monotonic), or
getting PTS values from different streams (like audio/subs).
Since these rely on PTS values and correct file durations anyway,
simplify it by calculating it with the current playback position in
mplayer.c instead.
There should be no functional changes, except that way how avoiding
spamming the terminal with the overflow warning is handled changes a
bit.
The removed check for ds->eof looks suspicious, but it should be
redundant now.
Rearrange some code to make it easier readable. Remove some dead code,
and stop printing AVI headers in demux_lavf. (These are not actual AVI
headers, just for internal use.)
There should be no functional changes, other than reducing output in
verbose mode.
Change the only usage of HAVE_BUILTIN_EXPECT, demux.h, to use an #ifdef
instead. In theory, a configure check is better, but nobody does it this
way anyway, and we seek to reduce the configure script.
Improve EOF handling in ds_fill_buffer for the case where one stream ends
much earlier than the others, in particular make sure the "too many ..."
message is not printed over and over.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@32823 b3059339-0415-0410-9bf9-f77b7e298cf2
Conflicts:
libmpdemux/demuxer.c
Try to improve seeking in files with only few video packets,
in particular files with cover art.
This might cause issues with badly interleaved files, particularly
together with -audio-delay, even though I did not see issues
in my very limited testing.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@35486 b3059339-0415-0410-9bf9-f77b7e298cf2
Conflicts:
libmpdemux/demuxer.c
libmpdemux/demuxer.h
Fix code that detects streams temporarily lacking data to work
properly with e.g. DVDs.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@35499 b3059339-0415-0410-9bf9-f77b7e298cf2
Conflicts:
libmpdemux/demuxer.c
Make stream eof detection less sensitive.
Fixes bug #2111.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@35543 b3059339-0415-0410-9bf9-f77b7e298cf2
Conflicts:
libmpdemux/demuxer.c
libavformat wants to read a full ~400KB of data to determine whether
it's really AAC. This causes slow startup with AAC web radio streams [1]
(possible due to a broken initial packet). There are similar issues
with other file formats.
Make the probe "score" (libavformat's mechanism for testing file
formats) configurable with the -lavfdtops:probescore option. This allows
lowering the amount of data read on probing. If the probe score is below
the probescore option value, demux_lavf will try to get a higher score
by feeding more data to libavformat, until the required score or the
max. probe size is reached.
Remove the lavf_preferred demuxer entry. This had a purpose in
mplayer-svn, but now there doesn't seem to be any good reason for it
to exist. Make sure that our native "good" demuxers are above
demux_lavf in demuxer_list[] instead (so that they are preferred).
[1] http://lr2mp0.latvijasradio.lv:8000
Finish renaming directories and moving files. Adjust all include
statements to make the previous commit compile.
The two commits are separate, because git is bad at tracking renames
and content changes at the same time.
Also take this as an opportunity to remove the separation between
"common" and "mplayer" sources in the Makefile. ("common" used to be
shared between mplayer and mencoder.)
Tis drops the silly lib prefixes, and attempts to organize the tree in
a more logical way. Make the top-level directory less cluttered as
well.
Renames the following directories:
libaf -> audio/filter
libao2 -> audio/out
libvo -> video/out
libmpdemux -> demux
Split libmpcodecs:
vf* -> video/filter
vd*, dec_video.* -> video/decode
mp_image*, img_format*, ... -> video/
ad*, dec_audio.* -> audio/decode
libaf/format.* is moved to audio/ - this is similar to how mp_image.*
is located in video/.
Move most top-level .c/.h files to core. (talloc.c/.h is left on top-
level, because it's external.) Park some of the more annoying files
in compat/. Some of these are relicts from the time mplayer used
ffmpeg internals.
sub/ is not split, because it's too much of a mess (subtitle code is
mixed with OSD display and rendering).
Maybe the organization of core is not ideal: it mixes playback core
(like mplayer.c) and utility helpers (like bstr.c/h). Should the need
arise, the playback core will be moved somewhere else, while core
contains all helper and common code.
