summaryrefslogtreecommitdiffstats
path: root/demux
Commit message (Collapse)AuthorAgeFilesLines
* stream: libarchive wrapper for reading compressed archiveswm42015-08-172-0/+92
| | | | | | | | | | | | | | | | | | | | This works similar to the existing .rar support, but uses libarchive. libarchive supports a number of formats, including zip and (most of) rar. Unfortunately, seeking does not work too well. Most libarchive readers do not support seeking, so it's emulated by skipping data until the target position. On backwards seek, the file is reopened. This works fine on a local machine (and if the file is not too large), but will perform not so well over network connection. This is disabled by default for now. One reason is that we try libarchive on every file we open, before trying libavformat, and I'm not sure if I trust libarchive that much yet. Another reason is that this breaks multivolume rar support. While libarchive supports seeking in rar, and (probably) supports multivolume archive, our support of libarchive (probably) does not. I don't care about multivolume rar, but vocal users do.
* demux: remove redundant demux_chapter.name fieldwm42015-08-125-15/+11
| | | | | | | | | | Instead, force everyone to use the metadata struct and set a "title" field. This is only a problem for the timeline producers, which set up chapters manually. (They do this because a timeline is a separate struct.) This fixes the behavior of the chapter-metadata property, which never returned a "title" property for e.g. ordered chapters.
* demux_mkv: disable timestamp fixup code againwm42015-08-101-1/+1
| | | | | | | | | | | | This doesn't work too well if sections of the file change to a different framerate. It lowers our chances to guess the correct FPS in the display sync code. For normal playback, this (probably) doesn't help that much anyway, except that the "estimated-vf-fps" property will regress in the simplest mkv case. This will be fixed with the next commit. The now disabled code will probably be removed; it's not useful anymore.
* demux: add options to control maximum queue sizewm42015-08-052-6/+5
| | | | | | | | | | | | | | Add --demuxer-max-packets and --demuxer-max-bytes, which control the maximum size of the packet queue. These can be helpful to avoid excessive memory usage. Memory usage is the reason why there's a limit in the first place. If a file is more or less broken, and audio and video don't line up, the decoders will fill up the packet queue trying to read more audio or video, and the maximum sizes are required to avoid unbounded memory allocation. Being able to override the maximum sizes is useful; either for restricting memory usage further, or enlarging the sizes when attempting to play various broken files.
* demux: remove options to control minimum packet queue sizewm42015-08-051-6/+0
| | | | | | | | Remove --demuxer-readahead-packets and --demuxer-readahead-bytes. These were a bit useless. They could force a minimum packet queue size, but controlling the queue size with --demuxer-readahead-secs is much nicer. It's fairly certain nobody ever used these options.
* player: warn against using HLS URLs with --playlistwm42015-08-041-1/+4
| | | | | | | | | That just makes no sense, but seems to be a somewhat common user error. The detection is not perfect. It's conceivable that EXT-X-... headers are used in normal m3u playlists. After all, HLS playlists are by definition a compatible extension to m3u playlists, as stupid as it sounds.
* player: use demux_open_url() to open main fileswm42015-08-042-4/+17
| | | | | | | | | | | | | | | | Instead of opening a stream and then a demuxer, do both at once with demux_open_url(). This requires some awkward additions to demuxer_params, because there are some weird features associated with opening the main file. E.g. the relatively useless --stream-capture features requires enabling capturing on the stream before the demuxer is opened, but on the other hand shouldn't be done on secondary files like external subtitles. Also relatively bad: since demux_open_url() returns just a demuxer pointer or NULL, additional error reporting is done via demuxer_params. Still, at least conceptually, it's ok, and simpler than before.
* player: remove higher-level remains of DVD/BD menu supportwm42015-08-033-21/+0
| | | | | | | | | | | | | | | Nobody wanted to restore this, so it gets the boot. If anyone still wants to volunteer to restore menu support, this would be welcome. (I might even try it myself if I feel masochistic and like wasting a lot of time for nothing.) But if it does get restored, it should be done differently. There were many stupid things about how it was done. For example, it somehow tried to pull mp_nav_events through all the layers (including needing to "buffer" them in the demuxer), which was needlessly complicated. It could be done simpler. This code was already inactive, so this commit actually changes nothing. Also keep in mind that normal DVD/BD playback still works.
* demux_playlist: skip hidden directorieswm42015-07-291-1/+1
| | | | | | | | The user probably doesn't want these. Conveniently, this also skips the unwanted "." and ".." entries. (This code is triggered if the input stream is a directory - and it's in demux_playlist.c because it's convenient.)
* demux_mkv: remove unnecessary codewm42015-07-201-4/+0
| | | | This did nothing. It's a leftover from ancient times.
* demux_mkv: parse FLAC channel layoutswm42015-07-201-0/+67
| | | | | | | | | | | | | | | | | | Handle a relatively recently introduced hack, that allows FLAC audio to have arbitrary channel layouts, instead of just the predefined fixed ones. This is actually supported by FFmpeg, but since the demuxer (instead of the decoder) handles this in FFmpeg, we need to add special- code to our mkv demuxer. (The way FFmpeg does this seems a bit backwards, since now every demuxer for a format that can handle FLAC needs to contain this logic as well.) The FLAC hack is relatively terrible: we need to parse the FLAC headers, look for a VorbisComment, parse the VorbisComment, and then retrieve the magic WAVEFORMATEXTENSIBLE_CHANNEL_MASK entry. But the hack is officially endorsed, as the official FLAC tools use it. (Although I couldn't find a trace of it in the format specification. Should I be surprised?)
* demux: handle Matroska-style replaygain tags as wellwm42015-07-121-0/+8
| | | | | | | Matroska doesn't follow the usual ReplayGain conventions, and doesn't distinguish between track/album values. Fixes #2128.
* demux: refactor replaygain tag handlingwm42015-07-121-17/+19
| | | | | For the following commit. Also print the replaygain values in verbose mode.
* player: parse and expose m3u playlist titleswm42015-07-101-2/+16
| | | | Requested. Closes #2100.
* demux_mkv: improve video duration detection heuristicwm42015-07-091-16/+29
| | | | | | | | | | | Extend the --demuxer-mkv-probe-video-duration behavior to work with files that are partial and are missing an index. Do this by finding a cluster 10MB before the end of the file, and if that fails, just read the entire file. This is actually pretty trivial to do and requires only 5 lines of code. Also add a mode that always reads the entire file to estimate the video duration.
* player: disable seeking even if the cache is enabledwm42015-07-081-3/+2
| | | | | | | | | | | | | | Until now, if a stream wasn't seekable, but the stream cache was enabled (--cache), we've enabled seeking anyway. The idea was that at least short seeks would typically fall within the cache. And if not, the user was out of luck and terrible things happened. In other words, it was unreliable. Be stricter about it and remove this behavior. Effectively, this will for example disable seeking in piped data. Instead of trying to be clever, add an --force-seekable option, which will always enable seeking if the user really wants it.
* demux_lavf: check for NAN rotation angleswm42015-06-301-3/+5
| | | | Yep, the FFmpeg API can return this.
* demux_mkv: disable ordered chapters if ChapterTimeEnd is missingwm42015-06-281-2/+11
| | | | | | | | | | | | | If the EditionFlagOrdered is set, chapters without ChapterTimeEnd make no sense. Ordered chapters will play the chapters in the order they appear, but will play the ranges the chapters cover. So if the end time is missing, the range is incomplete and it's not clear what should be played. If you assume the start of the next chapter as end time, the ordered flag will have no observable effect, so that's not a useful assumption. This fixes playback of a file which (apparently) had the EditionFlagOrdered set accidentally, with normal chapters.
* demux: export forced flagwm42015-06-273-1/+11
| | | | | | At least Matroska files have a "forced" flag (in addition to the "default" flag). Export this flag. Treat it almost like the default flag, but with slightly higher priority.
* demux_mkv: ignore deprecated FrameRate, do not assume PALwm42015-06-271-8/+2
| | | | | | | | | | | The "FrameRate" element is probably deprecated (it's greyed out in the "spec", and described as "Informational only" in bold). Normally files use DefaultDuration. In fact, the FrameRate field was preferred over DefaultDuration for determining framerate if present. Do not do this and rely on DefaultDuration only. Also, if no framerate is set, do not assume PAL (25 FPS). Such a fallback makes little sense and will cause more problems than it solves.
* demux_mkv: remove some ASCII art log messageswm42015-06-271-8/+4
| | | | | Some of the ASCII art makes sense (like the lines starting with "|"), but these do not make any sense to me and just look annoying.
* demux_mkv: use arrays for codec lookup tableswm42015-06-261-18/+11
| | | | No need to define extra types.
* demux_mkv: minor simplificationwm42015-06-261-3/+1
|
* player, demux: replace some demux_open() uses with demux_open_url()wm42015-06-241-6/+2
|
* demux_lavf: fix chapter titleswm42015-06-241-1/+1
| | | | Obvious bug added earlier today.
* demux_mkv: allow integer and float elements with length 0wm42015-06-241-7/+11
| | | | | | | | Integer and float elements are encoded as a sequence of bytes prefixed by a variable-length encoded length specifier. If the length is 0, then there is no data. Whether this is valid or not is not really clear, but some sample files which do this have surfaced. It's not particularly hard to handle this, so just do it.
* demux: get rid of some bstr thingswm42015-06-248-38/+36
| | | | | Change the demuxer_add_attachment() and demuxer_add_chapter() signatures to take char* instead of bstr, and everything which depends on it.
* demux_mkv: don't use byte stringswm42015-06-242-38/+48
| | | | | | Use char* for strings instead of bstr (data ptr + length pair). Matroska actually (probably) allows "padding" strings with \0 bytes, so using normal C strings instead of byte strings is more appropriate.
* demux: mime types are case-insensitivewm42015-06-211-1/+1
| | | | This one is used for demux_mf and for dmeux_mkv image attachments.
* demux_mkv: share some duplicated codewm42015-06-211-16/+17
| | | | | As a side effect, video tracks now actually export some fields (language, default flag) to the player.
* demux: merge extradata fieldswm42015-06-215-20/+16
| | | | | | | MPlayer traditionally had completely separate sh_ structs for audio/video/subs, without a good way to share fields. This meant that fields shared across all these headers had to be duplicated. This commit deduplicates essentially the last remaining duplicated fields.
* demux_mkv: minor audio extradata cleanupwm42015-06-211-27/+24
| | | | | | Always use the already existing extradata[_len] variable, instead of the awkward switch between manually changed extradata and falling back to passing through extradata at the end.
* demux: rename sh_stream.format to sh_stream.codec_tagwm42015-06-217-13/+11
| | | | | Why not. "format" sounds too misleading for the actual importance and meaning of this field.
* demux_playlist: make mime type comparison case-insensitivewm42015-06-201-1/+1
| | | | | | | | That's how mime types are. (This makes redirection with a specific HLS URL work, because some idiot thought it'd be a great idea to spell the mime type as "application/x-mpegURL".)
* demux_mkv: do not reset bits_per_coded_sample if not neededwm42015-06-191-7/+0
|
* demux_mkv: do not set block_align for codecs which do not need itwm42015-06-191-7/+0
| | | | | These decoders do not reference it. I suspect this was originally done for the sake for MPlayer's vfw/dshow wrappers.
* demux_mkv: do not set bitrate fields for codecs which do not need itwm42015-06-191-7/+0
| | | | | | The only decoders I could find and which (possibly) require this field are codecs which can be used via VfW only, and realaudio sipr. For VfW we still passthrough this field.
* demux_mkv: stricter realaudio extradata handlingwm42015-06-191-11/+13
| | | | | | Verify memory accesses and such. The behavior should be equivalent. (RealAudio causes pain for everyone even in its grave.)
* demux_mkv: separate generic and non-VfW audio codec handling partswm42015-06-191-89/+84
| | | | | | | | | | | | | | | | | | | Native Matroska codec support has to map the Matroska codec IDs to libavcodec ones, and also has to undo codec-specific Matroska strangeness, such as restoring AAC extradata and realaudio handling. The VfW codec support doesn't need it, because AVI maps well enough to libavcodec conventions (possibly because AVI was a dominant codec when libavcodec was created). But there's still some need for generic codec handling, such as enabling parsers and messing with various codec parameters. Separate these two, and move the parts which are guaranteed not to be needed by VfW to the if-else tree that handles the VfW case ("A_MS/ACM"), making the cases exclusive. (This should probably be done more radically, since it's very unlikely that we should or have to mess with the VfW parameters at all - they should just be passed through to the decoder.)
* demux_mkv: remove indirection through defineswm42015-06-192-134/+58
| | | | | This is actually more readable. Most of the defines are used only once, so using a symbol instead of the direct string only obfuscated it.
* demux_mkv: remove FourCCs from audio codec handlingwm42015-06-192-122/+73
| | | | | | | | | | | | | | | | | | | | | | This removes the last traces of the old MPlayer FourCC-based codec mapping code. Forcing all codec IDs through a FourCC table and then back to codec names was confusing at best, so this is a nice cleanup. Handling of PCM (non-VfW case) is redone to some degree. Handling of AC3 is moved below realaudio handling, since "A_REAL/DNET" is apparently AC3, and we must not skip realaudio-specific handling. (It seems unlikely that anything would actually break, but on the other hand I don't have any A_REAL/DNET samples for testing.) Instead of explicitly matching all the specific AAC codec names, just match them all as prefix. Some codecs don't need special handling other than their mapping entries, so they fall away (like Vorbis and Opus). The prores check in mkv_parse_and_add_packet() is not strictly related to this, but is done for consistency with the wavpack check above.
* player: add some debug output for seekingwm42015-06-181-0/+7
|
* Various spelling fixesMarcin Kurczewski2015-06-181-1/+1
| | | | Signed-off-by: wm4 <wm4@nowhere>
* demux_mkv: always copy video extradatawm42015-06-131-16/+14
| | | | | | The existing code avoided doing this for some codecs. I see no point in this, and it seems the original reason this exists was due to some cleanup in 2007. libavformat doesn't do this. So just drop it.
* demux_mkv: fix mpeg2 mappingwm42015-06-131-1/+1
| | | | | | | | It's well possible that we've always ended up invoking the AV_CODEC_ID_MPEG1VIDEO codec, but it's hard to tell. Mangling everything through FourCCs (and then back) makes it hard to analyze. Also, libavformat's Matroska demuxer uses AV_CODEC_ID_MPEG2VIDEO here, so it should be quite safe to do anyway.
* demux_mkv: remove FourCCs from video codec handlingwm42015-06-132-39/+27
| | | | | | | | | | | | | | | | | | | Inherited from MPlayer times, we used FourCCs to identify video codecs. This was later changed to libavcodec codec names (which made life a whole lot simpler). But demux_mkv still uses FourCCs a lot. Change this for video. It's pretty simple, because some preparation was done in the past. We just have to replace some "internal" FourCCs with different handling. One potentially complicated issue is that there is no natural way to set the sh->format (AVCodecContext.codec_tag) field anymore. Most decoders do not need it, though mjpeg is an exception. Note that the AVI compatibility code still requires codec mappings, but these are provided by FFmpeg. Also, the audio code is not changed. For the MKV_V_MPEG2 -> mpeg1video thing see next commit.
* demux_mkv: remove a level of indentationwm42015-06-131-53/+52
| | | | | Replace an else block with a nested if with just "else if". No functional or other changes.
* demux_mkv: remove ms_compat codewm42015-06-131-11/+5
| | | | Reduces the mess slightly.
* demux_lavf: fix wrong printf parameter type on 64 bit systemswm42015-06-021-1/+1
| | | | | "f.len - 4" is size_t, not int. Fix by using BSTR_P() (and a bstr function to adjust the length).
* demux_lavf: do a better job at guessing the vobsub .sub filenamewm42015-05-281-0/+40
| | | | | | | | | | | Vobsubs come as .idx/.sub pair of files. The .idx file is the one that should be opened, but the name of the .sub file is unknown. We can now make our own guess what the name of that file is. In particular, improve support with URLs (as these can have the file extension in the middle of the filename string if there are HTTP parameters). Note that this works only with newer ffmpeg versions, because the recently added sub_name demuxer option is used for this.
* demux: don't get stuck on some cases of timestamp resetswm42015-05-261-1/+2
| | | | | In this case, streaming ogg via mpd over icecast made it buffer infinitely on new tracks.
* demux_edl: fix includeswm42015-05-241-2/+2
| | | | It doesn't need access to the playback core state anymore.
* demux: read cue sheets embedded in tagswm42015-05-191-2/+17
| | | | | | | | | This reads the "CUESHEET" tag, and attempts to parse it as .cue data. If any is found, the cue tracks are added as chapters. This reuses the parser written for demux_cue.c. Fixes #1957.
* demux_cue: move cue parser to a separate filewm42015-05-193-180/+257
| | | | Preparation for the next commit.
* path: make mp_path_join accept normal C stringswm42015-05-094-5/+5
| | | | | Instead of bstr. Most callers of this function do not need bstr. The bstr version of this function is now mp_path_join_bstr().
* demux_lavf: drop dead codewm42015-04-251-7/+1
| | | | stream.url can never be NULL, although it probably used to be.
* demux_mkv: limit timestamp fixing to 1ms maxwm42015-04-231-1/+1
| | | | | And also fix the description. It didn't actually reflect what the code did.
* demux_mkv: attempt to fix rounded timestampswm42015-04-231-1/+18
| | | | | There is some potential for breakage. If it happens, this might have to be disabled by default.
* demux_mkv: move global options to the demuxerwm42015-04-233-10/+39
| | | | | | | The options don't change, but they're now declared and used privately by demux_mkv.c. This also brings with it a minor refactor of the subpreroll seek handling - merge the code from playloop.c into demux_mkv.c. The change in demux.c is pretty much equivalent as well.
* demux_mkv: better seeking after video endwm42015-04-231-15/+7
| | | | | | | | | | | | | | | | | This change allows forward seeking even if there are no more video keyframes in forward direction. This helps with files that e.g. encode cover art as a single video frame (within a _real_ video stream - ffmpeg seems to like to produce such files). Seeking backwards will still jump to the nearest video frame, so this improvement has limited use. The old code didn't do this because of the logic the min_diff variable followed. Instead of somehow using the timestamp of the last packet read for min_diff, use the first index entry for it. This actually makes it fall back to the first/last index entry as the (removed) comment claims. Note that last_pts is basically random at this point (because the demuxer can be far ahead of playback position), so this didn't make sense in the first place.
* demux: report correct cache state close to EOFwm42015-04-201-5/+4
| | | | | | | | | | | | | | | | | | | | | On EOF, this stopped reporting the actual cache duration, and just signalled unknown duration. Fix this and keep reporting whatever is left in the packet queue. This reverts commit 5438a8b3. The commit doesn't give a good explanation as to why it is needed, but I guess it was because the report