It appears this is not needed anymore. ffmpeg can handle "chained" ogg
files fine. These can be created with "cat file1.ogg file2.ogg > chained.ogg",
and are similar (or equal) to some internet radio streams. Apparently
ffmpeg used to add new tracks when crossing boundaries in chained files,
and the hack in demux_lavf.c handled this. At some later point, ffmpeg's
ogg demuxer was improved, and stopped adding new tracks as long as the
codec doesn't change.
Since the hack in demux_lavf.c was hardcoded to Vorbis (i.e. only active
if the new and old track were both Vorbis), it's dead code, and we can
remove it. I couldn't find any stream that triggered this hack, or fails
without it.
Firefox had a similar issue, and its bug tracker makes a good reference:
https://bugzilla.mozilla.org/show_bug.cgi?id=455165
NOTE: this doesn't update metadata on track changes anymore.
ffmpeg pretends that image attachments (such as contained in ID3v2
metadata) are video streams. It injects the attached pictures as packets
into the packet stream received with av_read_frame().
Add the --audio-display option to allow configuring whether attached
pictures should be displayed. The default behavior doesn't change
(images are displayed).
Identify video streams, that are actually image attachments, with "[P]"
in the terminal output.
Modify the default stream selection such that real video streams are
preferred over attached pictures. (This is just for robustness; I do not
know of any samples where images are added before actual video streams
and could lead to bad default stream selection with the old code.)
This is a fix for web radio streams that send raw AAC [1]. libavformat's
AAC demuxer probe is picky enough to request hundreds of KBs data, which
makes for a slow startup. To speed up stream startup, try use the HTTP
MIME type to identify the format. The webstream in question sends an AAC
specific MIME type, for which demux_lavf will force the AAC demuxer,
without probing anything.
ffmpeg/ffplay do the same thing. Note that as of ffmpeg commit 76d851b,
av_probe_input_buffer() does the mapping from MIME type to demuxer. The
actual mapping is not publicly accessible, and can only be used by
calling that function. This will hopefully be rectified, and ideally
ffmpeg would provide a function like find_demuxer_from_mime_type().
[1] http://lr2mp0.latvijasradio.lv:8000
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
This affects streams loaded with -subfile and -audiofile. They could get
out of sync when they were deselected, and the main file was seeked. Add
code to seek external files when they are selected (see
init_demux_stream()).
Use avformat_seek_file() under certain circumstances. Both av_seek_frame()
("old" API) and avformat_seek_file() ("new" API) seem to be broken with
some formats. At least the vobsub demuxer doesn't implement the old API
(and the old API doesn't fallback to the new API), while the fallback
from new API to old API gives bad results. For example, seeking forward
with small step sizes seems to fail with the new API (tested with
Matroska by trying to seek 1 second forward relative to priv->last_pts).
Since only subtitle demuxers implement the new API anyway, checking
whether iformat->read_seek2 is set to test whether the old API is not
supported gives best results. This is a hack at best, but makes things
work.
Remove backwards seeking on seek failure. This was annoying, and only
was there to compensate for obscure corner cases (see 1ad332). In
particular, files with completely broken seeking that used to skip back
to the start on every seek request may now terminate playback.
Reinitialize sh_audio->samplesize and sample_format before falling back
to another audio decoder (some decoders rely on default values). Remove
code setting these fields from demux_mkv and demux_lavf (no decoder
should depend on demuxer-set values for these fields).
Conflicts:
audio/decode/ad_lavc.c
Merged from mplayer2 commit 6b9567. The changes to ad_lavc.c are not
merged, as they are very specific to the mplayer2 libavresample hack;
we deplanarize manually, so we can't get unsupported sample formats
yet (except on raw audio with "pcm_f64le", as we don't support
AV_SAMPLE_FMT_DBL in the audio chain).
libavdevice supports various "special" video and audio inputs, such
as screen-capture or libavfilter filter graphs.
libavdevice inputs are implemented as demuxers. They don't use the
custom stream callbacks (in AVFormatContext.pb). Instead, input
parameters are passed as filename. This means the mpv stream layer has
to be disabled. Do this by adding the pseudo stream handler avdevice://,
whose only purpose is passing the filename to demux_lavf, without
actually doing anything.
Change the logic how the filename is passed to libavformat. Remove
handling of the filename from demux_open_lavf() and move it to
lavf_check_file(). (This also fixes a possible bug when skipping the
"lavf://" prefix.)
libavdevice now can be invoked by specifying demuxer and args as in:
mpv avdevice://demuxer:args
The args are passed as filename to libavformat. When using libavdevice
demuxers, their actual meaning is highly implementation specific. They
don't refer to actual filenames.
Note:
libavdevice is disabled by default. There is one problem: libavdevice
pulls in libavfilter, which in turn causes symbol clashes with mpv
internals. The problem is that libavfilter includes a mplayer filter
bridge, which is used to interface with a set of nearly unmodified
mplayer filters copied into libavfilter. This filter bridge uses the
same symbol names as mplayer/mpv's filter chain, which results in symbol
clashes at link-time.
This can be prevented by building ffmpeg with --disable-filter=mp, but
unfortunately this is not the default.
This means linking to libavdevice (which in turn forces linking with
libavfilter by default) must be disabled. We try doing this by compiling
a test file that defines one of the clashing symbols (vf_mpi_clear).
To enable libavdevice input, ffmpeg should be built with the options:
--disable-filter=mp
and mpv with:
--enable-libavdevice
Originally, I tried to auto-detect it. But the resulting complications
in configure did't seem worth the trouble.
Opening files with the libavformat AVISynth demuxer ("avs"/avisynth.c)
fails, because the filename we pass to avformat_open_input() is prefixed
with "mp:". Normally, this doesn't matter, because data is read with the
stream interface. The AVISynth demuxer can't use this, because the
Avisynth API (apparently) can't read scripts from memory, and requires
a filename.
The "mp:" prefix used to be required when mplayer's stream layer was
made available as protocol to ffmpeg. This was replaced by setting
custom stream callbacks in de4908 (svn commit 25499), but the prefix
wasn't removed. Since this prefix doesn't have any purpose anymore and
prevents AVS playback from functioning, remove it. Fixes#5.
Update endpos each time libavformat asks for it.
Fixes playback of still downloading files to not stop before we
really reached the end.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@35107 b3059339-0415-0410-9bf9-f77b7e298cf2
Conflicts:
libmpdemux/demux_lavf.c
Change STREAM_CTRL_GET_SIZE argument type from off_t to
uint64_t.
Also fix the incorrect type of the uint64_res variable.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@35360 b3059339-0415-0410-9bf9-f77b7e298cf2
Conflicts:
libmpdemux/demux_lavf.c
libmpdemux/muxer_lavf.c
Note: also merges the "forgotten" cache support from r35107.
Make demux_lavf not error out if no video or audio track is present.
This allows opening subtitle files with the demuxer.
Improve the test whether subtitles read from demuxers must do explicit
packet reads. (I'm not sure whether always doing these reads could have
bad effects, such as reading too many audio and video packets at once,
so be conservative.)
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.
