summaryrefslogtreecommitdiffstats
path: root/demux/demux_lavf.c
Commit message (Collapse)AuthorAgeFilesLines
* Merge branch 'audio_changes'wm42013-05-121-1/+3
|\ | | | | | | | | Conflicts: audio/out/ao_lavc.c
| * core: use channel map on demuxer level toowm42013-05-121-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This helps passing the channel layout correctly from decoder to audio filter chain. (Because that part "reuses" the demuxer level codec parameters, which is very disgusting.) Note that ffmpeg stuff already passed the channel layout via mp_copy_lav_codec_headers(). So other than easier dealing with the demuxer/decoder parameters mess, there's no real advantage to doing this. Make the --channels option accept a channel map. Since simple numbers map to standard layouts with the given number of channels, this is downwards compatible. Likewise for demux_rawaudio.
* | demux_lavf: use demuxer ID for transport streamswm42013-05-051-1/+4
| | | | | | | | | | Might help mapping tracks correctly to stream_bluray, fixing the issue with the track language not being reported.
* | demux_lavf: fix DEMUXER_CTRL_RESYNCwm42013-05-051-1/+1
| | | | | | | | | | | | | | | | | | This used the libavformat current position, instead of the mp stream (which reflects current DVD/Bluray read position). This was broken, because libavformat won't update its position by calling the user's stream callbacks, negating the whole point of DEMUXER_CTRL_RESYNC. Now DVD playback with libavformat seems to work relatively well.
* | demux_lavf: set stream_ptswm42013-05-051-0/+6
| | | | | | | | | | | | | | | | demux_mpg did the same, and doing this in demux_lavf fixes DVD playback when using this demuxer. Additionally this might make bluray work better in the future (but for now, bluray playback doesn't change as it doesn't report stream PTS yet).
* | demux_lavf: fix subtitle seeking before start of the filewm42013-04-211-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When trying to seek before the start of the file, which usually happens when using the arrow keys to seek to the start of the file, external libavformat demuxed subtitles will be invisible. This is because seeking in the external subtitle file fails, so the subtitle demuxer is left in a random state. This is actually similar to the normal seeking path, which has some fallback code to handle this situation. Add such code to the subtitle seeking path too. (Normally, all demuxer support av_seek_frame(), except subtitles, which support avformat_seek_file() only. The latter was meant to be the "new" seeking API, but this never really took off, and using it normally seems to cause worse seeking behavior. Or maybe we just use it incorrectly, nobody really knows.)
* | sub, demux: identify subtitle types with the codec namewm42013-04-201-21/+0
| | | | | | | | | | | | | | | | | | Get rid of the 1-char subtitle type field. Use sh_stream->codec instead just like audio and video do. Use codec names as defined by libavcodec for simplicity, even if they're somewhat verbose and annoying. Note that ffmpeg might switch to "ass" as codec name for ASS, so we don't bother with the current silly "ssa" name.
* | demux_lavf: simplifywm42013-04-201-147/+74
|/ | | | | | | | | | | | | | This removes the stream handling mess by using a single list for all stream types. One consequence is that new streams are always set to AVDISCARD_ALL, which could be an issue if packets are read before initializing other streams. However, this doesn't seem to an issue for various reasons, so we don't do anything about it. The new code strictly assumes that libavformat never removes or reorders streams once added to AVFormatContext->streams. Undefined behavior will result if it does.
* demux_lavf: use avg_frame_rate instead of r_frame_ratewm42013-03-131-2/+2
| | | | | | | | | | | r_frame_rate was deprecated and was finally removed from Libav and FFmpeg git. Not sure what's the correct replacement. avg_frame_rate may or may not be worse than the fallback of using the time_base as guess. The framerate is mostly unused, but needed for frame-based subtitles and for encoding. (It appears encoding guesses a timebase based on the FPS, and I'm not sure why we don't just use the source timebase.)
* Prefix CODEC_ID_ with AV_wm42013-03-131-9/+9
| | | | | | | | | The old names have been deprecated a while ago, but were needed for supporting older ffmpeg/libav versions. The deprecated identifiers have been removed from recent Libav and FFmpeg git. This change breaks compatibility with Libav 0.8.x and equivalent FFmpeg releases.
* core: fix SEEK_FACTORwm42013-03-011-4/+17
| | | | | | | | | | | | | | | | | | | | | | | | | 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).
* demux_lavf: fix percentage display with some file formatswm42013-03-011-1/+2
| | | | | | AVFormatContext.start_time is sometimes AV_NOPTS_VALUE, such as when playing FLAC files. (For most other file formats it's set to 0, even if the format doesn't support arbitrary start times.)
* m_option: don't define OPT_BASE_STRUCT by defaultwm42013-03-011-0/+2
| | | | | | | | | | | OPT_BASE_STRUCT defines which struct the OPT_ macros (like OPT_INT etc.) reference implicitly, since these macros take struct member names but no struct type. Normally, only cfg-mplayer.h should need this, and other places shouldn't be bothered with having to #undef it. (Some files, like demux_lavf.c, still store their options in MPOpts. In the long term, this should be removed, and handled like e.g. with VO suboptions instead.)
* core: use playback time to determine playback percent positionwm42013-02-261-8/+3
| | | | | | | | | | | | | 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.
* demux_lavf: add workaround for broken libavformat seek behaviorwm42013-02-191-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Seeking before the start of a .flac file (such as seeking backwards when the file just started) generates a bunch of decoding errors and audible artifacts. Also, the audio output doesn't match the reported playback position. The errors printed to the terminal are: [flac @ 0x8aca1c0]invalid sync code [flac @ 0x8aca1c0]invalid frame header [flac @ 0x8aca1c0]decode_frame() failed This is most likely a problem with the libavformat API. When seeking with av_seek_frame() fails, the demuxer can be left in an inconsistent state. ffplay has the same issue [1]. Older versions of mpv somehow handled this fine. Bisection shows that commit b3fb7c2 caused this regression by removing code that retried failed seeks with an inverted AVSEEK_FLAG_BACKWARD flag. This code was removed because it made it harder to stop playback of a file by seeking past the end of the file (expecting this is rather natural when skipping through multiple files by seeking, and the internal mplayer demuxers also did this). As a workaround, re-add the original code, but only for the backwards seeking case. Also note that the original intention of the code removed in b3fb7c2 was not dealing with this case, but something else. It also had to do with working around weird libavformat situations, though. It's not perfectly clear what exactly. See commit 1ad332f. [1] https://ffmpeg.org/trac/ffmpeg/ticket/2282
* demux_lavf, ad_lavc, vd_lavc: pass codec header data directlywm42013-02-101-78/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | Instead of putting codec header data into WAVEFORMATEX and BITMAPINFOHEADER, pass it directly via AVCodecContext. To do this, we add mp_copy_lav_codec_headers(), which copies the codec header data from one AVCodecContext to another (originally, the plan was to use avcodec_copy_context() for this, but it looks like this would turn decoder initialization into an even worse mess). Get rid of the silly CodecID <-> codec_tag mapping. This was originally needed for codecs.conf: codec tags were used to identify codecs, but libavformat didn't always return useful codec tags (different file formats can have different, overlapping tag numbers). Since we don't go through WAVEFORMATEX etc. and pass all header data directly via AVCodecContext, we can be absolutely sure that the codec tag mapping is not needed anymore. Note that this also destroys the "standard" MPlayer method of exporting codec header data. WAVEFORMATEX and BITMAPINFOHEADER made sure that other non-libavcodec decoders could be initialized. However, all these decoders have been removed, so this is just cruft full of old hacks that are not needed anymore. There's still ad_spdif and ad_mpg123, bu neither of these need codec header data. Should we ever add non-libavcodec decoders, better data structures without the past hacks could be added to export the headers.
* demux_lavf, ad_lavc, vd_lavc: refactor, cleanupwm42013-02-101-24/+0
| | | | | | | | | 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.
* demux_lavf: remove code duplicationwm42013-02-101-61/+20
| | | | | | | | | | Also move the lang field into the general stream header. (SH_COMMON is an old hack to "share" code between audio/video/sub headers.) There should be no functional changes, other than not printing stream info in verbose mode or with slave mode. (The frontend already prints stream info, and this is just a leftover when individual demuxers did this, and slave mode remains broken.)
* core: redo how codecs are mapped, remove codecs.confwm42013-02-101-12/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Use codec names instead of FourCCs to identify codecs. Rewrite how codecs are selected and initialized. Now each decoder exports a list of decoders (and the codec it supports) via add_decoders(). The order matters, and the first decoder for a given decoder is preferred over the other decoders. E.g. all ad_mpg123 decoders are preferred over ad_lavc, because it comes first in the mpcodecs_ad_drivers array. Likewise, decoders within ad_lavc that are enumerated first by libavcodec (using av_codec_next()) are preferred. (This is actually critical to select h264 software decoding by default instead of vdpau. libavcodec and ffmpeg/avconv use the same method to select decoders by default, so we hope this is sane.) The codec names follow libavcodec's codec names as defined by AVCodecDescriptor.name (see libavcodec/codec_desc.c). Some decoders have names different from the canonical codec name. The AVCodecDescriptor API is relatively new, so we need a compatibility layer for older libavcodec versions for codec names that are referenced internally, and which are different from the decoder name. (Add a configure check for that, because checking versions is getting way too messy.) demux/codec_tags.c is generated from the former codecs.conf (minus "special" decoders like vdpau, and excluding the mappings that are the same as the mappings libavformat's exported RIFF tables). It contains all the mappings from FourCCs to codec name. This is needed for demux_mkv, demux_mpg, demux_avi and demux_asf. demux_lavf will set the codec as determined by libavformat, while the other demuxers have to do this on their own, using the mp_set_audio/video_codec_from_tag() functions. Note that the sh_audio/video->format members don't uniquely identify the codec anymore, and sh->codec takes over this role. Replace the --ac/--vc/--afm/--vfm with new --vd/--ad options, which provide cover the functionality of the removed switched. Note: there's no CODECS_FLAG_FLIP flag anymore. This means some obscure container/video combinations (e.g. the sample Film_200_zygo_pro.mov) are played flipped. ffplay/avplay doesn't handle this properly either, so we don't care and blame ffmeg/libav instead.
* demux_lavf: default PTS to 0 for attached pictureswm42013-02-031-0/+4
| | | | | | The ffmpeg/libav attached picture hack usually set the PTS of video packets to AV_NOPTS_VALUE. Set it to 0 to avoid printing a warning by the filter code.
* demux_lavf: remove weird stream auto-selectionwm42013-02-031-10/+0
| | | | | | | Should be dead code. Stream selection is handled either during demuxer initialization, or via DEMUXER_CTRL_SWITCH_*. (If there were actually situations where this code did something, it was probably broken anyway.)
* demux_lavf: remove "internet radio hack"wm42013-02-031-39/+1
| | | | | | | | | | | | | | | | | | | | | 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.
* demux_lavf: avio_flush in DEMUXER_CTRL_RESYNCRudolf Polzer2013-01-101-0/+2
| | | | This rules out possible avio buffering issues.
* demux_lavf: implement DEMUXER_CTRL_RESYNCRudolf Polzer2013-01-071-0/+15
| | | | | This makes -chapter work with stream_dvd by telling ffmpeg to flush its internal buffers after a stream_dvd seek.
* Fix compilation with ffmpeg 1.0wm42012-12-131-2/+2
| | | | | AVPROBE_SCORE_RETRY was too new, and doesn't even exist in Libav. Go back to using the value explicitly.
* core: allow disabling display of "album art" in audio fileswm42012-12-111-0/+2
| | | | | | | | | | | | | | | | | | 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.)
* stream_lavf/demux_lavf: export/use HTTP MIME typewm42012-12-111-0/+17
| | | | | | | | | | | | | | | | | 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
* demux_lavf: make minimum probe score customizable, remove lavf_preferredwm42012-12-111-53/+33
| | | | | | | | | | | | | | | | | | | | | 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
* core: improve seeking in external fileswm42012-12-111-2/+10
| | | | | | | | | | | | | | | | | | | | | | | | 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.
* audio: improve decoder open failure handlingUoti Urpala2012-12-031-10/+0
| | | | | | | | | | | | | | | | 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).
* demux_lavf: add support for libavdevicewm42012-12-031-25/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* demux_lavf: do not prefix filename passed to libavformat with "mp:"wm42012-12-031-8/+9
| | | | | | | | | | | | | | | 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.
* stream, demux_lavf: minor cleanup for stream size codewm42012-11-201-3/+1
|
* 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.
* subtitles: improve support for libavformat demuxed subtitleswm42012-11-161-6/+1
| | | | | | | | | | 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.)
* Rename directories, move files (step 2 of 2)wm42012-11-121-7/+7
| | | | | | | | | | | | 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/+1092
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.