summaryrefslogtreecommitdiffstats
path: root/demux
Commit message (Collapse)AuthorAgeFilesLines
* demux: keep title chapter tag in uppercasewm42013-09-082-2/+2
| | | | | | | This is generally more uniform. Do the same for the file global title in demux_mkv.c, although that is not strictly related to chapters.
* demux_mkv: support V_PRORESwm42013-09-083-0/+11
| | | | | | | Why not... Code for demangling Matroska-style prores video packets inspired by libavformat's Matroska demuxer.
* demux: retrieve per-chapter metadatawm42013-09-084-8/+43
| | | | | | | | | | Retrieve per-chapter metadata, but don't do much with it. We just make the metadata of the _current_ chapter available as chapter-metadata property. Returning the full chapter list with metadata would be no problem, except that the property interface isn't really good with structured data, so it's not available for now. Not sure if it's worth it, but it was requested via github issue #201.
* demux: refactor tag handlingwm42013-09-082-37/+63
| | | | | Make the code somewhat reuseable, instead of bound to a single demuxer instance. The plan is to add support for per-chapter tags later.
* demux_mkv: don't overflow packet queue when doing sub-prerollwm42013-09-081-4/+13
| | | | | | | | | | | | | | Consider the cluster used for prerolling contains an insane amount of subtitle packets. Then the demuxer packet queue would be full of subtitle packets, and demux.c would refuse to read any further packets - including video and audio packets, resulting in EOF. Since everything involving Matroska and subtitles is 100% insane, this can actually happen. Fix this by putting a limit on the number of subtitle packets read by preroll, and throw away any further packets if the limit is exceeded. If this happens, the preroll mechanism will stop working, but the player's operation is unaffected otherwise.
* demux_lavf: workaround for broken libavformat subtitle seekingwm42013-09-071-4/+23
| | | | | | | | | | | | | | The really funny thing about this commit is that this code is added on top of another work around. Basically, subtitle seeking in libavformat is completely broken. To make it useful, we have to add yet another workaround. The basic problem is that libavformat's subtitle seeking code always uses the stream time base, instead of AV_TIME_BASE if stream index -1 is passed to the avformat_seek_file() function. Fixes github issue #216. Hopefully this will be fixed in ffmpeg too at some point.
* demux_playlist: port ini reference playlist parserwm42013-08-281-1/+18
| | | | | | | | | | Port it from playlist_parser.c to demux_playlist.c. Also, change the m3u parser to drop whitespace from the trailing part of the line (will make it work properly with windows line endings). (I hoped that this would make MMS URIs with http instead of mmsh prefixes work, but it doesn't. Instead, it leads to a playlist loop. So solving this issue would require a change in ffmpeg, probably.)
* stream: add uncompressed rar supportwm42013-08-261-0/+4
| | | | | | | | | | | | | | | | | Apparently, it is popular to store large files in uncompressed rar archives. Extracting files is not practical, and some media players suport playing directly from uncompressed rar (at least VLC and some DirectShow components). Storing or accessing files this way is completely idiotic, but it is a common practice, and the ones subjected to this practice can't do much to change this (at least that's what I assume/hope). Also, it's a feature request, so we say yes. This code is mostly taken from VLC (commit f6e7240 from their git tree). We also copy the way this is done: opening a rar file by itself yields a playlist, which contains URLs to the actual entries in the rar file. Compressed entries are simply skipped.
* core: add a playlist demuxerwm42013-08-263-0/+143
| | | | | | | | | Modeled after the old playlist_parser.c, but actually new code, and it works a bit differently. Demuxers (and sometimes streams) are the component that should be used to open files and to determine the file format. This was already done for subtitles, but playlists still use a separate code path.
* sub: add webvtt-in-webm supportwm42013-08-242-0/+4
| | | | | | | | | | | | | | The way this was added to FFmpeg is less than ideal, because it requires text parsing in the Matroska demuxer. But in order to use the FFmpeg webvtt-to-ass converter, we still have to mimic this in some way. We do this by putting the parsing into sd_lavc_conv.c, before the subtitle packet is passed to libavcodec. At least this keeps the ugliness out of unrelated code. There is some change that FFmpeg will fix their design eventually. Instead of rewriting the parsing code, we simply borrow it from FFmpeg's Matroska demuxer.
* demux: remove unused audio_delay parameter from demux_seek()wm42013-08-228-20/+13
| | | | Used to be needed by demux_avi.
* demux: check whether stream is selected in demux_get_next_pts()wm42013-08-221-1/+1
| | | | | | | | Otherwise, this would just try to demux a good chunk of the file, even though the operation can't succeed anyway. This caused some pretty strange issues, where perfectly valid use cases would print a "Too many packets in the demuxer packet queue..." message.
* demux_raw: read multiple frames per packetwm42013-08-221-1/+4
| | | | | | | | | | The rawaudio demuxer read one frame per packet, basically a few bytes, which caused insane overhead. (I found this when I couldn't play raw audio without dropouts when using -v, which printed a line per packet read.) Fix this and read 1 second of audio per packet. This is a regression since cfa5712 (merging of demux_rawaudio and demux_rawvideo).
* options: replace --edition=-1 with --edition=autowm42013-08-211-2/+3
| | | | | | Originally, the objective of this commit was changing --edition to be 1-based, but this was cancelled. I'm still leaving the change to demux_mkv.c though, which is now only of cosmetic nature.
* demux: move demux_mf before demux_subreaderwm42013-08-121-3/+3
| | | | | demux_subreader is quite aggressive, and sometimes detects random strings in EXIF as subtitle text.
* demux_subreader: report what subtitle format has been foundwm42013-08-121-0/+2
|
* demux_lavf: blacklist "tty" libavformat demuxerv0.1.0wm42013-08-071-1/+16
| | | | | | | | | | This is completely useless, and in this particular case, it broke the fallback for MLP2 subtitles (stored as .txt files) to demux_subreader. (Yes, libavformat should be fixed to handle this, but for now this will _always_ break playback of subtitle files stored in .txt.) You can still force this demuxer, but by default we will just pretend that the "tty" demuxer does not exist.
* core: move contents to mpvcore (2/2)Stefano Pigozzi2013-08-0614-29/+29
| | | | Followup commit. Fixes all the files references.
* demux_lavf: make avio buffer configurablewm42013-08-041-6/+8
| | | | | | Perhaps not very useful, but reserved for situations when a user reports awful latency and experimentation/debugging might be required to find out why or to fix it (happens often).
* demux_lavf: fix API usagewm42013-08-041-2/+10
| | | | | | | | | avio_alloc_context() is documented to require an av_malloc'ed buffer. It appears libavformat can even reallocate the buffer while it is probing, so passing a static buffer can in theory lead to crashes. I couldn't reproduce such a crash, but apparently it happened to mplayer-svn. This commit follows the mplayer fix in svn commit r36397.
* vdpau: split off decoder parts, use "new" libavcodec vdpau hwaccel APIwm42013-07-281-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Move the decoder parts from vo_vdpau.c to a new file vdpau_old.c. This file is named so because because it's written against the "old" libavcodec vdpau pseudo-decoder (e.g. "h264_vdpau"). Add support for the "new" libavcodec vdpau support. This was recently added and replaces the "old" vdpau parts. (In fact, Libav is about to deprecate and remove the "old" API without deprecation grace period, so we have to support it now. Moreover, there will probably be no Libav release which supports both, so the transition is even less smooth than we could hope, and we have to support both the old and new API.) Whether the old or new API is used is checked by a configure test: if the new API is found, it is used, otherwise the old API is assumed. Some details might be handled differently. Especially display preemption is a bit problematic with the "new" libavcodec vdpau support: it wants to keep a pointer to a specific vdpau API function (which can be driver specific, because preemption might switch drivers). Also, surface IDs are now directly stored in AVFrames (and mp_images), so they can't be forced to VDP_INVALID_HANDLE on preemption. (This changes even with older libavcodec versions, because mp_image always uses the newer representation to make vo_vdpau.c simpler.) Decoder initialization in the new code tries to deal with codec profiles, while the old code always uses the highest profile per codec. Surface allocation changes. Since the decoder won't call config() in vo_vdpau.c on video size change anymore, we allow allocating surfaces of arbitrary size instead of locking it to what the VO was configured. The non-hwdec code also has slightly different allocation behavior now. Enabling the old vdpau special decoders via e.g. --vd=lavc:h264_vdpau doesn't work anymore (a warning suggesting the --hwdec option is printed instead).
* options: simplify --correct-pts handlingwm42013-07-262-2/+1
| | | | | | Remove the (now unused) code for determining correct-pts mode based on the demuxer in use. Change its description in the manpage to reflect what this option does now.
* demux_libass: actually set priv contextwm42013-07-241-0/+1
| | | | This was a memory leak: the ASS_Track was never deallocated.
* demux_lavf: set keyframe flag on attached pictureswm42013-07-241-0/+1
| | | | | | | | | Gives really funky results with PNG attachments otherwise. The main problem is that avcodec_flush_buffers() does not fully reset the decoder, so passing multiple PNG packets without keyframe flags will attempt to combine the new picture with the previously decoded contents. (Makes no sense with proper PNG - maybe this codepath is intended for MNG or APNG.)
* Fix some -Wshadow warningswm42013-07-233-17/+15
| | | | | | In general, this warning can hint to actual bugs. We don't enable it yet, because it would conflict with some unmerged code, and we should check with clang too (this commit was done by testing with gcc).
* core: make --demuxer not affect external subtitleswm42013-07-221-2/+0
| | | | | | This also affects --audiofile. The previous behavior wasn't really useful. There are even separate switches for that: --audio-demuxer and --sub-demuxer.
* demux_mkv: fix realaudio timestampswm42013-07-201-2/+2
| | | | | | | This fixes the sample RA_missing_timestamps.mkv. Pretty funny how this code got it almost right, but not quite, so it was broken all these years. And then, after everyone stopped caring, someone comes and fixes it. (By the way, I know absolutely nothing about realaudio.)
* demux_mkv: ignore DefaultDuration in some caseswm42013-07-161-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes playback of the sample linked by FFmpeg ticket 2508. The fix follows ffmpeg commit 6158a3b (although it's not exactly the same). The problem here is that the file contains an apparently non-sense DefaultDuration value. DefaultDuration for audio tracks is used to derive PTS values for packets with no timestamps, like they can happen with frames inside a laced block. So the first packet of a SimpleBlock will have a correct PTS, while the PTS values of the following packets are calculated using DefaultDuration, and thus are broken. This leads to seemingly ok playback, but broken A/V sync. Not using the DefaultDuration value will leave the PTS values of these packets unset, and the audio decoder can derive them from the output instead. The fix more or less uses a heuristic to detect the broken case: if the sample rate is 8 KHz (Matroska default, can assume unset), and the codec is AC3 (as the broken file did), don't use it. I'm not sure why this should be done only for AC3, maybe the muxing application (mkvmerge v4.9.1) has known issues with AC3. AC3 also doesn't support 8 KHz as sample rate natively. (By the way, I'm not sure why we should honor the DefaultDuration at all for audio. It doesn't seem to be needed. You can't seek to these frames, and decoders should always be able to produce perfect PTS values by adding the duration of the decoded audio to the first PTS.)
* demux_mkv: never force output sample ratewm42013-07-162-18/+10
| | | | | | | | | | | | | | Matroska has an output sample rate (OutputSamplingFrequency), which in theory should be forced instead of whatever the decoder outputs. But it appears no software (other than mplayer2 and mpv until now) actually respects this. Even worse, there were broken files around, which played correctly with (in theory) broken software, but not mplayer2/mpv. Hacks were added to our code to play these files correctly, but they didn't catch all cases. Simplify this by doing what everyone else does, and always use the decoder's sample rate instead. In particular, we try to handle all sample rate issues like libavformat's Matroska demuxer does.
* demux_subreader: make clang happy to fix warningwm42013-07-151-1/+1
| | | | | Clang warns here, probably because it's easy to confuse with the usual ((a=b)) pattern.
* video: unify colorspace setupwm42013-07-151-3/+2
| | | | | | | | | | Guess the colorspace directly in mpcodecs_reconfig_vo(), instead of in set_video_colorspace(). The difference is that the latter function just makes the video filter chain (and VOs) force the detected colorspace, and then throws it away, while the former is a bit more general and central. Not really a big difference and it doesn't matter much in practice, but it guarantees that there is no internal disagreement about the colorspace.
* demux_lavf: add terrible hack to make DVD playback just workwm42013-07-141-8/+85
| | | | | | | | | | | | | | | | | | DVD playback had some trouble with PTS resets: libavformat's genpts feature would try reading until EOF (worst case) to find a new usable PTS in case a packet's PTS is not set correctly. Especially with slow DVD access, this would make the player to appear frozen. Reimplement it partially in demux_lavf.c, and use that code in the DVD case. This is heavily "inspired" by the code in av_read_frame from libavformat/utils.c. The difference is that we stop reading if no PTS has been found after 50 packets (consider this a heuristic). Also, we don't bother with the PTS wrapping and last-frame-before-EOF handling. Even with normal PTS wraps, the player frontend will go to hell for the duration of a frame anyway, and should recover quickly after that. The terribleness of this commit is mostly that we duplicate libavformat functionality, and that we suddenly need a packet queue.
* demux_raw: uncrustifywm42013-07-141-160/+162
| | | | Should have been done before doing all the changes...
* demux_mkv: remove weird i_bps calculation codewm42013-07-121-20/+0
| | | | Useless, as i_bps isn't really used for anything anymore.
* demux_raw: calculate durationwm42013-07-121-0/+23
|
* demux_rawvideo/demux_rawaudio: move both demuxers to demux_raw.cwm42013-07-122-149/+98
| | | | | This allows them to share some trivial code. Both demuxers are still separate from user perspective.
* demux: make claiming accurate seek the defaultwm42013-07-124-4/+4
| | | | Enables hr-seek for raw audio/video demuxers.
* demux_rawvideo: fix timestamps in correct-pts modewm42013-07-121-1/+1
|
* demux: assume correct-pts mode by defaultwm42013-07-125-10/+1
| | | | | | | | All demuxers make a reasonable effort to set packet timestamps, and thus support correct-pts mode. This commit also implicitly switches demux_rawvideo to correct-pts mode. We still allow demuxers to disable correct-pts mode in theory.
* demux: remove useless author/comment fieldswm42013-07-1212-56/+20
| | | | Same deal as with previous commit.
* demux: rewrite probing and demuxer initializationwm42013-07-1213-420/+212
| | | | | | | | | | | | | | Get rid of the strange and messy reliance on DEMUXER_TYPE_ constants. Instead of having two open functions for the demuxer callbacks (which somehow are both optional, but you can also decide to implement both...), just have one function. This function takes a parameter that tells the demuxer how strictly it should check for the file headers. This is a nice simplification and allows more flexibility. Remove the file extension code. This literally did nothing (anymore). Change demux_lavf so that we check our other builtin demuxers first before libavformat tries to guess by file extension.
* core: change open_stream and demux_open signaturewm42013-07-123-32/+19
| | | | | | | | | | | This removes the dependency on DEMUXER_TYPE_* and the file_format parameter from the stream open functions. Remove some of the playlist handling code. It looks like this was needed only for loading linked mov files with demux_mov (which was removed long ago). Delete a minor bit of dead network-related code from stream.c as well.
* demux: change signature of open functions, cleanupswm42013-07-1112-158/+137
| | | | Preparation for redoing the open functions.
* demux: allow passing NULL as packet to demuxer_add_packet()wm42013-07-111-1/+1
| | | | demux_subreader relied on this.
* stheader: minor cleanupwm42013-07-113-6/+3
| | | | | | | Move codec_tags.h include to demux_mkv.c, because this is the only file which still uses it. Move new_sh_stream() to demux.h, because this is more proper.
* core: completely change handling of attached picture pseudo videowm42013-07-113-34/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Before this commit, we tried to play along with libavformat and tried to pretend that attached pictures are video streams with a single frame, and that the frame magically appeared at the seek position when seeking. The playback core would then switch to a mode where the video has ended, and the "remaining" audio is played. This didn't work very well: - we needed a hack in demux.c, because we tried to read more packets in order to find the "next" video frame (libavformat doesn't tell us if a stream has ended) - switching the video stream didn't work, because we can't tell libavformat to send the packet again - seeking and resuming after was hacky (for some reason libavformat sets the returned packet's PTS to that of the previously returned audio packet in generic code not related to attached pictures, and this happened to work) - if the user did something stupid and e.g. inserted a deinterlacer by default, a picture was never displayed, only an inactive VO window) - same when using a command that reconfigured the VO (like switching aspect or video filters) - hr-seek didn't work For this reason, handle attached pictures as separate case with a separate video decoding function, which doesn't read packets. Also, do not synchronize audio to video start in this case.
* demux_lavf: do stream selection centrallywm42013-07-111-12/+13
| | | | Removes very minor code duplication for setting the st->discard flag.
* demux: improve DVD sub auto-selection hackwm42013-07-113-24/+29
| | | | | | | | | | | | | | | | | | | | | | | The code touched by this commit makes sure that DVD subtitle tracks known by libdvdread but not known by demux_lavf can be selected and displayed properly. These subtitle tracks have the first packet some time late in the packet stream, so that libavformat won't immediately recognize them, and will add the track as soon as the first packet is seen during normal demuxing. demux_mpg used to handle this elegantly: you just set the MPEG ID of the stream you wanted. demux_lavf couldn't do this, so it was emulated with a DEMUXER_CTRL. This commit changes it so that new streams are selected by default (if autoselect is enabled), and the playloop simply can take appropriate action before the lower layer throws away the first packet. This also changes the demux_lavf behavior that subtitle packets are always demuxed, even if not needed. (They were immediately thrown away, so there was no advantage to this.) Further, this adds the ability to demux.c to deal with demuxing more than one stream of a kind at once. (Though currently it's not useful.)
* demux_lavf: use AVDISCARD_DEFAULT instead of AVDISCARD_NONEwm42013-07-111-1/+1
| | | | | | AVDISCARD_DEFAULT is probably a bit better for normal decoding. AVDISCARD_NONE would (as by documentation) include "useless" packets too, while DEFAULT filters these.
* video: eliminate frametime variablewm42013-07-116-6/+0
|
* demux: refactorwm42013-07-113-145/+126
|
* core: don't access demux_stream outside of demux.c, make it privatewm42013-07-1110-101/+75
| | | | | | | | | | | | | | | | | | | Generally remove all accesses to demux_stream from all the code, except inside of demux.c. Make it completely private to demux.c. This simplifies the code because it removes an extra concept. In demux.c it is reduced to a simple packet queue. There were other uses of demux_stream, but they were removed or are removed with this commit. Remove the extra "ds" argument to demux fill_buffer callback. It was used by demux_avi and the TV pseudo-demuxer only. Remove usage of d_video->last_pts from the no-correct-pts code. This field contains the last PTS retrieved after a packet that is not NOPTS. We can easily get this value manually because we read the packets ourselves. Reuse sh_video->last_pts to store the packet PTS values. It was used only by the correct-pts code before, and like d_video->last_pts, it is reset on seek. The behavior should be exactly the same.
* tv: add hack in preparation of demux_stream removalwm42013-07-112-0/+8
| | | | | | | | | | Currently, all demuxer fill_buffer functions have a demux_stream parameter. We want to remove that, but the TV code still depends on it. Add a hack to remove that dependency. The problem with the TV code is that reading video and audio frames blocks, so in order to avoid a deadlock, you should read either of them only if the decoder actually requests new data.
* demux_lavf: different hack for DVD sub autoselection hackwm42013-07-111-3/+2
| | | | | | | | | | | For now, we want to get rid of the demux->sub access, because this field will become private to demux.c in a later commit. So replace the current hack with another hack. The need for the hack will be removed sooner or later. (Instead of autoselecting a specific stream, all new streams will be enabled by default, so that no packets can get lost. The frontend will then be responsible to deselect unwanted streams.)
* mplayer: fix incorrect audio sync after format changeswm42013-07-111-1/+0
| | | | | | | |