summaryrefslogtreecommitdiffstats
path: root/demux
Commit message (Collapse)AuthorAgeFilesLines
* demux: print initial metadatawm42014-07-071-0/+1
| | | | | This was accidentally broken in 7e209185, and metadata was printed only when it changed.
* Remove stream_pts stuffwm42014-07-064-7/+0
| | | | | This was used by DVD/BD, but its usage was removed with one of the previous commits.
* dvd, bd: enable precise seekingwm42014-07-061-4/+1
| | | | | | | | | | | | | | | | | | | This should work now, at least kind of. Note that actual success depends on the behavior of the underlying lib{dvd{nav,read},bluray} implementation, which could go very wrong. In the worst case, it could happen that the underlying implementation seeks a long time before the seek target time. In this case, the player will just decode video until the target time is reached, even if that requires e.g. decoding 30 mintues of video before refreshing. In the not-so-bad but still bad case, it would just miss the seek target, and seek past it. In my tests, it works mostly ok, though. Seeking backwards usually fails, unless something like --hr-seek-demuxer-offset=1 is used (this makes it seek to 1 second before the target, which may or may not be enough to compensate for the DVD/BD imprecision).
* dvd, bluray: handle playback display time handling differentlywm42014-07-061-12/+80
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a pretty big change. Instead of doing a half-hearted passthrough of the playback timestamp, we attempt to rewrite the raw MPEG timestamps such that they match with the playback time. We add the offset between raw start timestamp and playback time to the packet timestamps. This is the easy part; but the problem is with timestamp resets. We simply detect timestamp discontinuities by checking whether they are more than 500ms apart (large enough for all video faster than 2 FPS and audio with reasonable framesizes/samplerates), and adjust the timestamp offset accordingly. This should work pretty well. There may be some problems with subtitles. If the first packet after a timestamp reset is a subtitle instead of video, it will fail. Also, selecting multiple audio or video streams won't work (but mpv doesn't allow selecting several anyway). Trying to demux subtitles with no video stream enabled will probably fail. Untested with Bluray, because I have no Bluray sample. Background: libdvdnav/libdvdread/libbluray make this relatively hard. They return a raw MPEG (PS/TS) byte stream, and additionally to that provide a function to retrieve the current "playback" time. The playback time is what should be displayed to the user, while the MPEG timestamps can be completely different. Even worse, the MPEG timestamps can reset. Since we use the libavformat demuxer (instead of parsing the MPEG packets in the DVD/BD code), it's hard to associate between these timestamps. As a result, the time display is special cased in the playloop, and of low quality (updates only all 1 or 2 seconds, sometimes is incorrect). The fact that the stream cache can be between demuxer and the stream source makes things worse. All the libs seem to provide an event that tells whether timestamps are resetting. But since this signalling is byte based, it's hard to connect it to the demuxed MPEG packets. It might be possible to create some sort of table mapping file positions to discontinuities and new timestamps. (For simplicity, this table could be 2 entries large, sufficient to catch all discontinuities if the distance between them is larger than the total buffering.)
* demux: fix a corner case related to demux_discwm42014-07-061-5/+8
| | | | | | It can happen that demux_fill_buffer() adds more than 1 packet, and then the packets would add up. Affects demux_disc.c only (nothing else uses this function).
* dvd: fix first subtitle with delayed subtitle streamswm42014-07-063-1/+5
| | | | | | This was accidentally broken with moving the DVD code to demux_disc.c. Also remove an abort() call meant for debugging.
* demux: minor simplificationwm42014-07-066-11/+8
| | | | Oops, should have been part of commit 37085788.
* tv: move demuxer parts to separate filewm42014-07-051-0/+251
| | | | | Now all demuxer implementations (at least demuxer API-wise) are in the demux directory.
* demux: minor simplification to internal APIwm42014-07-058-31/+21
| | | | Also some other unrelated minor changes.
* dvd: move angle switching codewm42014-07-052-46/+0
| | | | | No need to provide a "nice" API for it; just do this stuff directly in the command code.
* dvd: flush buffers properly on seekwm42014-07-051-3/+4
| | | | | | | | | | | Suggested by tholin on github issue #882. This is not entirely clean, but the fields we're accessing might be considered internal to libavformat. On the other hand, existence of the fields is guaranteed by the ABI, and nothing in the libavformat doxygen suggestes they're not allowed to be accessed. CC: @mpv-player/stable
* dvd, bluray, cdda: add demux_disc containing all related hackswm42014-07-054-88/+295
| | | | | | | | | | | | DVD and Bluray (and to some extent cdda) require awful hacks all over the codebase to make them work. The main reason is that they act like container, but are entirely implemented on the stream layer. The raw mpeg data resulting from these streams must be "extended" with the container-like metadata transported via STREAM_CTRLs. The result were hacks all over demux.c and some higher-level parts. Add a "disc" pseudo-demuxer, and move all these hacks and special-cases to it.
* demux: set filepos field when dequeuing a packetwm42014-07-051-3/+2
| | | | Otherwise the position can be too far ahead.
* demux: cosmetics: minimize codewm42014-07-051-16/+3
|
* demux: make start time a simple fieldwm42014-07-053-17/+8
| | | | Simpler, especially for later changes.
* demux, stream: change metadata notificationwm42014-07-053-22/+22
| | | | | | | | | | | | (Again.) This time, we simply make it event-based, as it should be. This is done for both demuxer metadata and stream metadata. For some ogg-over-icy streams, 2 updates are reported on stream start. This is because libavformat reports an update right on start, while including the same info in the "static" metadata. I don't know if that's a bug or a feature.
* demux: make replaygain per-trackwm42014-07-054-8/+10
| | | | | | It's unlikely that files with multiple audio tracks and with replaygain actually happen, but this change might help avoid minor corner cases with later changes.
* demux: move packet functions to a separate source filewm42014-07-054-108/+133
|
* demux: move packet list functionswm42014-07-053-73/+49
| | | | Move them to the only place where they are used, demux_subreader.c.
* demux_lavf: for now, ignore the new libavformat image demuxerswm42014-07-051-0/+3
| | | | | | | | | | | | Recently, libavformat added demuxers to open image files like normal demuxers. This is a good thing, but for now they interfere with the operation of demux_mf. Add them to the blacklist until there is a proper solution. (The list doesn't contain _all_ recognized image formats, just those that might interfere with demux_mf.) CC: @mpv-player/stable
* demux_lavf: support OTF fonts in Matroskawm42014-07-051-3/+10
| | | | Apparently it's FFmpeg only.
* demux_lavf: don't dump transport stream programswm42014-07-051-13/+0
| | | | Probably useless.
* demux_lavf: cleanup debug outputwm42014-07-051-19/+10
| | | | Remove unnecessary prefix, remove some messages.
* demux_lavf: fix read_seek return valuewm42014-07-051-3/+1
| | | | | | | This returned a stream error value directly to libavformat, which can't make sense. For example STREAM_ERROR (0) means success in libavformat error codes. (The meaning of the libavformat read_seek return value is underdocumented too.)
* demux_mkv: cosmeticswm42014-07-051-45/+27
|
* demux: drop AVI special codewm42014-07-021-8/+0
| | | | | | | I'm pretty sure libavformat does this automatically, and we don't have other demuxers where this could happen. Still, slightly "risky" - so let's see.
* demux_mkv: minor improvement to overflow checkwm42014-07-021-2/+3
| | | | CC: @mpv-player/stable
* Audit and replace all ctype.h useswm42014-07-013-4/+2
| | | | | | | | | | | | | | | | Something like "char *s = ...; isdigit(s[0]);" triggers undefined behavior, because char can be signed, and thus s[0] can be a negative value. The is*() functions require unsigned char _or_ EOF. EOF is a special value outside of unsigned char range, thus the argument to the is*() functions can't be a char. This undefined behavior can actually trigger crashes if the implementation of these functions e.g. uses lookup tables, which are then indexed with out-of-range values. Replace all <ctype.h> uses with our own custom mp_is*() functions added with misc/ctype.h. As a bonus, these functions are locale-independent. (Although currently, we _require_ C locale for other reasons.)
* demux: minor cleanupswm42014-07-014-26/+0
|
* demux_mkv: cosmeticswm42014-06-292-26/+20
|
* demux_mkv: add some overflow checks etc.wm42014-06-292-59/+111
| | | | | | | | | | | Some of these might be security relevant. The RealAudio code was especially bad. I'm not sure if all RealAudio stuff still plays correctly; I didn't have that many samples for testing. Some checks might be unnecessary or overcomplicated compared to the (obfuscated) nature of the code. CC: @mpv-player/stable
* demux_lavf: remove unused symbolwm42014-06-231-2/+0
|
* demux_mkv: add S_DVBSUBwm42014-06-172-0/+2
| | | | Probably works; untested.
* demux: use position as signed integerwm42014-06-141-1/+1
| | | | Seeing (uint64_t)-1 as value when position was unset was annoying.
* options: turn --idx, --forceidx into --indexwm42014-06-132-2/+2
| | | | | | | | | | | | Also clarify the semantics. It seems --idx didn't do anything. Possibly it used to change how the now removed legacy demuxers like demux_avi used to behave. Or maybe it was accidental. --forceidx basically becomes --index=force. It's possible that new index modes will be added in the future, so I'm keeping it extensible, instead of e.g. creating --force-index.
* demux: use av_malloc for packetswm42014-06-131-2/+2
| | | | | | | | Probably "needed" to get the correct alignment, although I'm not aware of actual breakages or performance issues. In fact we should probably always just allocate AVPackets, but for now use the simple fix.
* demux: simplify packet resizingwm42014-06-133-15/+5
| | | | | Actually we don't need to resize packets; we just need to make them shorter.
* demux: fix compilation with FFmpeg gitwm42014-06-122-11/+4
| | | | | | | | | FFmpeg requires a bullshit padding after each input buffer, and they just increased that padding without warning and without ABI or API bump. We need this only in one file (although mp_image hardcodes something similar, for which no FFmpeg API define is available), so drop our own define.
* demux_lavf: make option struct localwm42014-06-111-16/+34
| | | | Similar to previous commits.
* Add more constwm42014-06-113-9/+9
| | | | | | | While I'm not very fond of "const", it's important for declarations (it decides whether a symbol is emitted in a read-only or read/write section). Fix all these cases, so we have writeable global data only when we really need.
* demux_raw: remove global option variableswm42014-06-111-51/+78
|
* demux_mf: remove global option variableswm42014-06-112-9/+6
|
* command: redo ancient TV/DVB/PVR commandswm42014-06-111-0/+7
| | | | | | | | | | | | | | | | | | Convert all these commands to properties. (Except tv_last_channel, not sure what to do with this.) Also, internally, don't access stream details directly, but dispatch commands with stream ctrls. Many of the new properties are a bit strange, because they're write- only. Also remove some OSD output these commands produced, because I couldn't be bothered to port these. In general, this makes everything much cleaner, and will also make it easier to e.g. move the demuxer to its own thread. Don't bother updating input.conf, but changes.rst documents how old commands map to the new ones. Mostly untested, due to lack of hardware.
* demux_lavf: support new rotation metadata APIwm42014-06-011-1/+11
|
* command: improve video-bitrate propertyAndrey Morozov2014-06-011-0/+3
| | | | | | Signed-off-by: wm4 <wm4@nowhere> Includes some cosmetic changes over the original PR.
* player: hide audio/video codec and file format messageswm42014-05-311-3/+3
| | | | | None of these are very important usually. For error analysis, the plain log is useless anyway, and this information is still printed with "-v".
* af_fmt2bits: change to af_fmt2bps (bytes/sample) where appropriateMarcoen Hirschberg2014-05-281-1/+1
| | | | | | In most places where af_fmt2bits is called to get the bits/sample, the result is immediately converted to bytes/sample. Avoid this by getting bytes/sample directly by introducing af_fmt2bps.
* audio: rename i_bps to 'bitrate' to avoid confusionMarcoen Hirschberg2014-05-283-5/+5
| | | | Since i_bps now contains bits/sec, rename it to reflect this change.
* audio: change values from bytes-per-second to bits-per-secondMarcoen Hirschberg2014-05-283-5/+5
| | | | | | | The i_bps members of the sh_audio and dev_video structs are mostly used for displaying the average audio and video bitrates. Keeping them in bits-per-second avoids truncating them to bytes-per-second and changing them back lateron.
* stream: don't use end_poswm42014-05-244-22/+32
| | | | | | | | | | | | | | | | | | | Stop using it in most places, and prefer STREAM_CTRL_GET_SIZE. The advantage is that always the correct size will be used. There can be no doubt anymore whether the end_pos value is outdated (as it happens often with files that are being downloaded). Some streams still use end_pos. They don't change size, and it's easier to emulate STREAM_CTRL_GET_SIZE using end_pos, instead of adding a STREAM_CTRL_GET_SIZE implementation to these streams. Make sure int64_t is always used for STREAM_CTRL_GET_SIZE (it was uint64_t before). Remove the seek flags mess, and replace them with a seekable flag. Every stream must set it consistently now, and an assertion in stream.c checks this. Don't distinguish between streams that can only be forward or backwards seeked, since we have no such stream types.
* stream: kill start_pos, remove --sb optionwm42014-05-243-11/+10
| | | | | | | | | | | | | | | | | | | | stream.start_pos was needed for optical media only, and (apparently) not for very good reasons. Just get rid of it. For stream_dvd, we don't need to do anything. Byte seeking was already removed from it earlier. For stream_cdda and stream_vcd, emulate the start_pos by offsetting the stream pos as seen by the rest of mpv. The bits in discnav.c and loadfile.c were for dealing with the code seeking back to the start in demux.c. Handle this differently by assuming the demuxer is always initialized with the stream at start position, and instead seek back if initializing the demuxer fails. Remove the --sb option, which worked by modifying stream.start_pos. If someone really wants this option, it could be added back by creating a "slice" stream (actually ffmpeg already has such a thing).
* demux_subreader: remove support for some subtitle formatswm42014-05-191-629/+4
| | | | | | | | | | | | | | | | Drop: sami, vplayer, rt, pjs, mpsub, aqt, jacosub. None of these seem to be actually in use, except sami. Sami is very complex, and the results subreader produces are not very useful. For all these formats, there are still parsers in FFmpeg. We remove the subreader implementation, because it might contain security relevant bugs and such. (This is old, unmaintained C string parsing code, written in times where absolutely nobody cared about security. The kind of awesome code.) We keep the other formats, because they're (mostly) commonly used and relatively simple, for UTF16 support (still missing in FFmpeg), and for the sake of Libav.
* demux_playlist: fix m3u detection logicwm42014-05-111-1/+1
| | | | | | | | | Caused failure to detect .pls files, because they were misdetected as m3u. The problem is that "forcing playlist files" and "forcing a specific playlist format" are not really treated separate, and in both cases p->force is set to true. This made m3u detect all files as m3u if --playlist was used. So correctly check whether the file format is actually being probed or not.
* demux_playlist: don't require header for m3uwm42014-05-061-4/+3
| | | | | | | | | Because the http playlist URL I had for testing claimed to be m3u by file extension and mime type, but didn't have the header. Note that this actually changes behavior only in the case the format is detected by mime type. Then p->force will be set before calling the parser, and the header becomes optional.
* demux_playlist: add some mime typeswm42014-05-061-2/+4
|
* demux_playlist: allow recognizing format by mime typewm42014-05-061-0/+21
| | | | | This commit just adds basic support. The following commit will add actual mime types.
* demux_lavf: one more hack for mp3 from networkwm42014-05-041-1/+1
| | | | | | | | | | | | | | mp3 has a hack lowering the probescore for format detection. This is because detecting mp3s is hard due to their nature, and the fact that ID3v2 tags are sometimes several megabytes big. When playing mp3 from network, the mime-type is usually set, and that matches the format hack entry meant for webradios, overriding the normal mp3 entry. This can lead to network mp3s not being detected. Lower the network case to the same probescore as on-disk mp3s. The difference is that for network mp3s, we don't load the full probe-buffer, and we lower the amount of audio the demuxer will read to collect data on opening (0.5 seconds instead of typically 5 seconds).
* options: remove deprecated --identifyMartin Herkt2014-05-041-5/+0
| | | | | | | Also remove MSGL_SMODE and friends. Note: The indent in options.rst was added to work around a bug in ReportLab that causes the PDF manual build to fail.
* demux_mkv: enable parsing for VP9wm42014-04-261-2/+4
| | | | | | | | | | | | VP9 packets can contain 2 frames in some video packets (from which 1 frame is invisible). Due to a design mismatch between libvpx and the libavcodec vp9 decoder, libvpx can take the "full" packets, but lavc vp9 can not. The consequence is that we have to split the packets if we want to feed them to the lavc codec. This is not entirely correct yet: timestamp handling is missing. --demuxer=lavf and ffmpeg native utilities have the same problem. We can fix this only once the ffmpeg VP9 parser is fixed.
* demux_mkv: enable parsing for mp3wm42014-04-251-1/+1
| | | | | | | | | | | | | | | | | | | | | | For some reason, some files appear to have broken mp3 packets, or at least in a form that libavcodec can't deal with. The audio in the sample file in question could not be decoded using libavcodec. The problematic file had variable packet sizes, and the libavcodec decoder kept printing "mp3: Header missing" for each packet it was fed. Remuxing with mkvmerge fixes the problem. The mp3 data is probably not VBR, and remuxing resulted in fixed-size mp3 frames. So I don't know why the sample file was muxed this way - it might just be incorrect. The sample file had "libmkv 0.6.4" as MuxingApp (although I could not get mkvinfo to print this element, maybe the file uses an incorrect element ID), and "HandBrake 0.9.4" as WritingApp. Note that the libmpg123 decoder does not have any issues with it. It's probably more robust, because libmpg123 was made to decode whole mp3 files, not just single frames. Fixes issue #742.
* build: glob() is always availablewm42014-04-221-6/+0
| | | | | | | | | glob() is mandated by POSIX. For the only non-POSIX platform we support, Windows, we have our own replacement. So the ifdeffery is not needed. Still leave the checks in the configure scripts, because they have to decide whether to compile the replacement or not. (Although this could be special cased to mingw-only, the wscript seems to make this hard.)
* glob-win: support UnicodeJames Ross-Gowan2014-04-211-9/+1
| | | | | | | | | | | | | | | | glob-win.c wasn't big, so it was easier to rewrite it. The new version supports Unicode, handles directories properly, sorts the output and puts all its allocations in the same talloc context to simplify the implementation of globfree.