summaryrefslogtreecommitdiffstats
path: root/stream/stream_lavf.c
Commit message (Collapse)AuthorAgeFilesLines
* stream: remove useless author/comment fieldswm42013-07-121-3/+0
| | | | | | | | | These were printed only with -v. Most streams had them set to useless or redundant values, so it's just badly maintained bloat. Since we remove the "author" field too, and since this may have copyright implications, we add the contents of the author fields to the file headers, except if the name is already part of the file header.
* stream: don't require streams to set a typewm42013-07-121-1/+0
| | | | | Set the type only for streams that have special treatment in other parts of the code.
* Cleanup some include statementswm42013-07-121-1/+0
|
* core: change open_stream and demux_open signaturewm42013-07-121-5/+5
| | | | | | | | | | | This removes the dependency on DEMUXER_TYPE_* and the file_format parameter from the stream open functions. Remove some of the playlist handling code. It looks like this was needed only for loading linked mov files with demux_mov (which was removed long ago). Delete a minor bit of dead network-related code from stream.c as well.
* Remove some leftovers from network removalwm42013-07-071-1/+1
| | | | | | | | stream_vstream.c in particular was actually dependent on the network code, and didn't compile anymore. Cleanup the protocol list in mpv.rst, and add some missing ones supported by libavformat to stream_lavf.c.
* stream: remove weird STREAMTYPE_STREAM special handlingwm42013-07-071-4/+1
| | | | | | | | | This was an old leftover from an earlier cleanup (which happened in 2003), and which used "special" stuff for streams that could be only forward-seeked. Also, don't add mode flags to s->flags; they're supposed to be in s->mode instead.
* Remove internal network supportwm42013-07-071-2/+1
| | | | | | | | | | | This commit removes the "old" networking code in favor of libavformat's code. The code was still used for mp_http, udp, ftp, cddb. http has been mapped to libavformat's http support since approximately 6 months ago. udp and ftp have support in ffmpeg (though ftp was added only last month). cddb support is removed with this commit - it's probably not important and rarely used if at all, so we don't care about it.
* core: make network options available even if old net code is disabledwm42013-07-071-2/+1
| | | | Preparation for removing the old network code.
* stream_lavf: request and read streamcast/ICY metadatawm42013-07-021-4/+89
| | | | Requires recent ffmpeg git, otherwise will do nothing.
* stream: don't set EOF flag in stream implementationswm42013-06-161-1/+0
| | | | | | | | | | EOF should be set when reading more data fails. The stream implementations have nothing to say here and should behave correctly when trying to read when EOF was actually read. Even when seeking, a correct EOF flag should be guaranteed. stream_seek() (or actually stream_seek_long()) calls stream_fill_buffer() at least once, which also updates the EOF flag.
* build: make it work on somewhat older ffmpeg versionswm42013-01-311-1/+1
| | | | | | Tested with n0.10.4. All these version checks are rather tricky, because Libav and FFmpeg change the same thing at slightly different versions.
* stream: fix reconnecting on broken network connectionswm42013-01-241-11/+30
| | | | | | | | | | | | | | | | This didn't work properly for HTTP with libavformat. The builtin HTTP implementation reconnects automatically on its own, while libavformat doesn't. Fix this by adding explicit reconnection support to stream_lavf.c, which simply destroys and recreates the AVIO context. It mostly works, though sometimes it mysteriously fails, spamming crap all over the terminal and feeding broken data to the decoders. This is probably due to itneractions with the cache. Also, reconnecting to unseekable HTTP streams will make it read the entire stream until the previous playback position is reached again. It's not known whether this change makes behavior with "strange" protocols like RTP better or worse.
* stream: implement some HTTP specific options for stream_lavfwm42013-01-241-1/+27
| | | | | | | | | | | | | | | | | | The "http:" protocol has been switched to use ffmpeg's HTTP implementation some time ago. One problem with this was that many HTTP specific options stopped working, because they were obviously implemented for the internal HTTP implementation only. Add the missing things. Note that many options will work for ffmpeg only, as Libav's HTTP implementation is missing these. They will silently be ignored on Libav. Some options we can't fix: --ipv4-only-proxy, --prefer-ipv4, --prefer-ipv6 As far as I can see, not even libavformat internals distinguish between ipv4 and ipv6. --user, --passwd ffmpeg probably supports specifying these in the URL directly.
* stream_lavf: warn if protocol not foundwm42012-12-281-1/+6
| | | | | | | | If ffmpeg returns AVERROR_PROTOCOL_NOT_FOUND, print a warning that ffmpeg should be compiled with network support. Note that stream_lavf.c itself includes a whitelist of directly supported ffmpeg protocols, so it can't happen that a completely unknown/madeup protocol triggers this message. (Unless the ffmpeg:// or lavf:// prefixes are used.)
* Fix compilation with Libavwm42012-12-111-0/+2
| | | | | | | | | | 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.
* stream_lavf/demux_lavf: export/use HTTP MIME typewm42012-12-111-3/+10
| | | | | | | | | | | | | | | | | 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
* stream: handle mms streaming with ffmpegwm42012-12-111-5/+14
| | | | | | | | | | | | | | | | | | | | 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.)
* stream_lavf: use ffmpeg for http/https streamingwm42012-12-031-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* stream, demux: replace off_t with int64_twm42012-11-201-1/+1
| | | | | | On reasonable systems, these types were the same anyway. Even on unreasonable systems (seriously, which?), this may reduce potential breakage.
* stream: change STREAM_CTRL_GET_SIZE argument type to uint64_treimar2012-11-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | 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.
* Rename directories, move files (step 2 of 2)wm42012-11-121-4/+4
| | | | | | | | | | | | 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.)
* Rename directories, move files (step 1 of 2) (does not compile)wm42012-11-121-0/+170
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.