summaryrefslogtreecommitdiffstats
path: root/demux
Commit message (Collapse)AuthorAgeFilesLines
...
* demux_rawvideo: allow setting video codecwm42013-02-241-0/+4
| | | | Can be used to decode some obscure image formats and similar stuff.
* demux_mf: map to codecs directlywm42013-02-242-39/+35
| | | | Instead of going through FourCCs and codec_tags.c.
* demux_rawvideo: remove ancient video dimension presetswm42013-02-231-19/+0
| | | | I can't see much value in them. Just specify the size manually.
* 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_mf: fix breakage after commit 4d016a9wm42013-02-171-0/+1
|
* demux: apply sparse video hack only to demux_lavf and demux_mkvwm42013-02-142-11/+8
| | | | | | | | | | | | | | | | | Apparently this cuases trouble for legacy demuxers. demux_mpg stopped doing PCM audio. (The problem was probably that it read a bunch of video packets on detection, and then the sparse video hack prevented audio packets from being read, because it looked like there were no more audio packets. With sparse video, this normally helps not reading too many audio packets.) Since the legacy demuxers do not need this hack, enable it for demux_lavf and demux_mkv only. Some additional hacks that were needed to handle legacy demuxers can be removed, making the code simpler. Also see commit 4a40eed.
* demux: restructure code that warns about packet buffer overflowswm42013-02-142-34/+33
| | | | | | | | | 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.
* demux_mpg: fix setting codecwm42013-02-141-0/+1
| | | | | This made one case of DVD PCM audio not work. It still doesn't work, but that will be fixed with the following two commits.
* demux: fix video with demux_mpg (DVD playback)wm42013-02-121-1/+4
| | | | | | | | | | Commit 4d016a9 changed how demuxers report the codec of each stream. Some of that was missed in video.c, which is important for legacy demuxers (demux_mpg was broken by this, which is needed for DVD playback). Not sure about the ASF/AVI related change, but this is also a legacy demuxers only codepath.
* demux_lavf, ad_lavc, vd_lavc: pass codec header data directlywm42013-02-105-269/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | 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-102-26/+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-104-65/+24
| | | | | | | | | | 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-1013-90/+479
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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_mkv: support more formats with V_UNCOMPRESSEDwm42013-01-301-0/+6
| | | | | | | Select the generic raw video decoder in codecs.cfg ("MPrv" FourCC), which forces the generic lavc raw video decoder "rawvideo". This means all FourCCs understood by lavc rawvideo are supported, not just whatever has codecs.cfg entries.
* demux: don't use codec_tag for raw PCM formatswm42013-01-301-0/+8
| | | | | | | | | | | In commit 2dd2d9b, raw PCM was switched to always go through ad_lavc, and mapping codec IDs to mplayer internal codec tags was removed, as it was not needed anymore. However, some uncompressed audio lavf demuxers export their own codec tags, which collide with the existing internal mplayer codec tags, leading to incorrect raw PCM codec selection based on the misinterpreted audio tag. Re-add the mapped codec IDs from 2dd2d9b. Map them to an invalid codec tag, so that the generic lavc decoder is selected (assumes ad_lavc is the decoder for raw PCM).
* demux_mkv: support V_UNCOMPRESSED video trackswm42013-01-242-1/+11
| | | | | | Tested with a sample generated by: ffmpeg -i in.mkv -an -vcodec rawvideo out.mkv Also add proper dependencies for the Matroska Perl stuff in Makefile.
* video: decouple internal pixel formats from FourCCswm42013-01-133-31/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | mplayer's video chain traditionally used FourCCs for pixel formats. For example, it used IMGFMT_YV12 for 4:2:0 YUV, which was defined to the string 'YV12' interpreted as unsigned int. Additionally, it used to encode information into the numeric values of some formats. The RGB formats had their bit depth and endian encoded into the least significant byte. Extended planar formats (420P10 etc.) had chroma shift, endian, and component bit depth encoded. (This has been removed in recent commits.) Replace the FourCC mess with a simple enum. Remove all the redundant formats like YV12/I420/IYUV. Replace some image format names by something more intuitive, most importantly IMGFMT_YV12 -> IMGFMT_420P. Add img_fourcc.h, which contains the old IDs for code that actually uses FourCCs. Change the way demuxers, that output raw video, identify the video format: they set either MP_FOURCC_RAWVIDEO or MP_FOURCC_IMGFMT to request the rawvideo decoder, and sh_video->imgfmt specifies the pixel format. Like the previous hack, this is supposed to avoid the need for a complete codecs.cfg entry per format, or other lookup tables. (Note that the RGB raw video FourCCs mostly rely on ffmpeg's mappings for NUT raw video, but this is still considered better than adding a raw video decoder - even if trivial, it would be full of annoying lookup tables.) The TV code has not been tested. Some corrective changes regarding endian and other image format flags creep in.
* video: simplify decoder pixel format handlingwm42013-01-131-1/+0
| | | | | | | | | | | | | | | | | | | | Simplify the decoder pixel format handling by making it handle only the case vd_lavc needs: a video stream always decodes to a single pixel format. Remove the handling for multiple pixel formats, and remove the codecs.conf pixel format declarations that are left. Remove the handling of "ambiguous" pixel formats like YV12 vs. I420 (via VDCTRL_QUERY_FORMAT etc.). This is only a problem if the video chain supports I420, but not YV12, which doesn't seem to be the case anywhere, and in fact would not have any advantage. Make the "flip" flag a global per-codec flag, rather than a pixel format specific flag. (Some ffmpeg decoders still return a flipped image, so this has to be done manually.) Also fix handling of the flip operation: do not overwrite the global flip option, and make the --flip option invert the codec flip option rather than overriding it.
* Replace strsep() useswm42013-01-131-3/+8
| | | | | | This function sucks and apparently is not very portable (at least on mingw, the configure check fails). Also remove the emulation of that function from osdep/strsep*, and remove the configure check.
* configure: remove __builtin_expect checkwm42013-01-131-1/+1
| | | | | | 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.
* demux_mkv: work around bad OutputSamplingFrequency valuesUoti Urpala2013-01-131-0/+8
| | | | | | | | | Something produces corrupt Matroska files with audio tracks that have SamplingFrequency set to 44100 and OutputSamplingFrequency to 96000, when the correct playback rate is 44100. Add a special case for this 44100/96000 combination and override it to 44100/44100; it's unlikely that anyone would ever want to use this 44100/96000 combination for real in valid files.
* 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.
* demux_mpg, ass_mp: fix warningsRudolf Polzer2012-12-281-2/+2
| | | | | | | | The warnings in demux_mpg were silenced by additional no-operation casts. A variable in ass_mp was used only for some versions of libass; now the declaration is in that version #ifdef too to avoid a compiler warning.
* 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.
* demux: fix behavior with files that have sparse video packetsreimar2012-12-113-6/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* core: allow disabling display of "album art" in audio fileswm42012-12-112-1/+4
| | | | | | | | | | | | | | | | | | 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.)
* audio/decode: remove ad_dvdpcm and use ad_lavc for DVD PCMwm42012-12-111-0/+45
| | | | | | | | | | ad_dvdpcm reads MPEG specific headers directly (passed through codecdata by demux_mpg), so you couldn't use ffmpeg's "pcm_dvd" with demux_mpg. Change demux_mpg to set the correct audio parameters directly. The code for this is taken from ad_dvdpcm. ad_dvdpcm is evil because it still does partial packet reads (with demux_read_data()), and it's redundant to libavcodec anyway.
* audio/decode: remove ad_pcm and use ad_lavc for PCMwm42012-12-111-8/+0
| | | | | | | | | | | | | | | Since libavcodec doesn't have a "generic" PCM decoder, we have to go out of out way to make it look like ad_lavc provides one: make it provide a pseudo "pcm" decoder, which maps some format tags manually to the individual libavcodec PCM decoders. Format tags which uniquely map to one libavcodec could be mapped via codecs.conf. Since defining these in tag_map[] is much shorter (one line vs. a full codec entry in codecs.conf), and since we need tag_map[] anyway, we don't use codecs.conf for these. ad_pcm is evil because it still does partial packet reads (with demux_read_data()), and it's redundant to libavcodec anyway.
* 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-114-59/+36
| | | | | | | | | | | | | | | | | | | | | 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
* sub: remove vobsub reader in favor of ffmpeg vobsub demuxerwm42012-12-111-0/+10
| | | | | | | | ffmpeg recently added a demuxer that can read vobsubs (pairs of .sub and .idx files). Get rid of the internal vobsub reader, and use the ffmpeg demuxer instead. Sneak in an unrelated manpage change (autosub default).
* core: improve seeking in external fileswm42012-12-112-2/+14
| | | | | | | | | | | | | | | | | | | | | | | | 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-032-15/+2
| | | | | | | | | | | | | | | | 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_gif: remove this demuxer in favor of libavformatwm42012-12-032-343/+0
| | | | | The gif support in libavformat/libavcodec as of ffmpeg commit 5603b2 can handle animated gif. The internal demuxer is not needed anymore.
* 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.
*