1
0
mirror of https://github.com/mpv-player/mpv synced 2024-12-28 01:52:19 +00:00
Commit Graph

58 Commits

Author SHA1 Message Date
wm4
0fba387f72 Fix compilation with Libav
Doesn't define AVPROBE_SCORE_RETRY for some reason. They use
AVPROBE_SCORE_MAX/4 directly internally. AV_DISPOSITION_ATTACHED_PIC
is not defined with the most recent Libav release.

AVIOContext.av_class exists in Libav, but is apparently disabled in
old releases. Disable it for now until people stop torturing me with
old crap releases.
2012-12-11 15:26:02 +01:00
wm4
180944fe28 stream_lavf/demux_lavf: export/use HTTP MIME type
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
2012-12-11 00:37:54 +01:00
wm4
eb787267c8 stream: handle mms streaming with ffmpeg
Use ffmpeg (stream_lavf) instead of internal mms support (asf_streaming.c)
for mms://, mmsh://, mmst:// URLs.

The old implementation is available under mp_mms:// etc.

There are some caveats with this:
- mms:// now always maps to mmsh://. It won't try mmst://. (I'm not sure
  if mms:// URLs really can use the mmst protocol, though.)
- MMS streams under the http:// prefix are not handled. (ffmpeg ticket
  #2001.) (Was already broken in mpv since c02f25.)
- It downloads all video streams now. MMS streams often have redundant
  video streams, which encode the main stream at different quality. The
  client is supposed to select one according to its bandwidth
  requirements. (Explicit MMS stream selection has been broken in mpv
  for a while, because MPOpts.vid maps to the stream number, not the
  demuxer's stream ID - but the old logic doesn't work anyway when
  using demuxer_lavf as opposed to demux_asf.)
2012-12-11 00:37:54 +01:00
wm4
c02f252938 stream_lavf: use ffmpeg for http/https streaming
The internal mplayer http implementation is terrible and old. Try to use
ffmpeg instead. Enable ffmpeg https as well (we don't have native
support for it and never will).

Enable the cache for ffmpeg streams. In theory, we want to enable the
cache for network streams only (or at least, not enable it for files),
but there doesn't seem to be any way to query this. ffmpeg has its own
read-cache, but apparently it doesn't get filled asynchronously (only
to the degree internal socket/kernel buffers do).

Should it turn out that the mplayer implementation is better than
ffmpeg's in some way (unlikely), this commit might be reverted until
ffmpeg is ready. So far, the ffmpeg implementation seems to work very
well though.

The original mplayer stream implementation is made available under
"mp_http://" and "mp_http_proxy://". This is for testing, until the
http implementation is completely removed. Note that this is unlikely
to happen soon: ffmpeg doesn't support Microsoft streaming, while
mplayer has some support. This code has dependencies on http.

Note: "http_proxy://" doesn't work anymore. Use "httpproxy://" to get
the ffmpeg implementation of it.

Using https requires enabling OpenSSL in ffmpeg by adding
the --enable-openssl switch to ffmpeg's configure.
2012-12-03 21:08:52 +01:00
wm4
ddffcce678 stream, demux: replace off_t with int64_t
On reasonable systems, these types were the same anyway. Even on
unreasonable systems (seriously, which?), this may reduce potential
breakage.
2012-11-20 18:00:15 +01:00
reimar
51dac4e070 stream: change STREAM_CTRL_GET_SIZE argument type to uint64_t
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.
2012-11-20 18:00:14 +01:00
wm4
4873b32c59 Rename directories, move files (step 2 of 2)
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.)
2012-11-12 20:08:18 +01:00
wm4
d4bdd0473d Rename directories, move files (step 1 of 2) (does not compile)
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.
2012-11-12 20:06:14 +01:00