summaryrefslogtreecommitdiffstats
path: root/demux
Commit message (Collapse)AuthorAgeFilesLines
* Split mpvcore/ into common/, misc/, bstr/wm42013-12-1714-24/+24
|
* Merge mp_talloc.h into ta/ta_talloc.hwm42013-12-172-2/+0
|
* Move options/config related files from mpvcore/ to options/wm42013-12-178-10/+10
| | | | | | | | | Since m_option.h and options.h are extremely often included, a lot of files have to be changed. Moving path.c/h to options/ is a bit questionable, but since this is mainly about access to config files (which are also handled in options/), it's probably ok.
* Replace mp_tmsg, mp_dbg -> mp_msg, remove mp_gtext(), remove set_osd_tmsgwm42013-12-163-24/+24
| | | | | | | | | The tmsg stuff was for the internal gettext() based translation system, which nobody ever attempted to use and thus was removed. mp_gtext() and set_osd_tmsg() were also for this. mp_dbg was once enabled in debug mode only, but since we have log level for enabling debug messages, it seems utterly useless.
* demux_mkv: don't seek outside of the file when finding segmentswm42013-12-141-1/+4
| | | | | | | | The end of the current segment will be the end of the file if there is no next segment. Normally, this didn't matter much, since UNIX files allow seeking past the end of the file. But when opening files from HTTP, this would print confusing error messages. So explicitly check for EOF before trying to read a segment.
* stream: add function for dropping the bufferwm42013-12-141-0/+1
| | | | | And use it in demux_lavf.c. It looks like otherwise, some data might be left over, depending on how the hell av_seek_frame() behaves.
* demux_lavf: fix timebase confusionwm42013-12-121-7/+7
| | | | | This set last_pts to bogus values, which is used for relative seeks. The player usually uses absolute seeks, so this didn't matter much.
* demux: revert accidentally included change from previous commitwm42013-12-121-1/+1
| | | | Oops.
* Add prelimimary (basic, possibly broken) dvdnav supportwm42013-12-121-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | This readds a more or less completely new dvdnav implementation, though it's based on the code from before commit 41fbcee. Note that this is rather basic, and might be broken or not quite usable in many cases. Most importantly, navigation highlights are not correctly implemented. This would require changes in the FFmpeg dvdsub decoder (to apply a different internal CLUT), so supporting it is not really possible right now. And in fact, I don't think I ever want to support it, because it's a very small gain for a lot of work. Instead, mpv will display fake highlights, which are an approximate bounding box around the real highlights. Some things like mouse input or switching audio/subtitles stream using the dvdnav VM are not supported. Might be quite fragile on transitions: if dvdnav initiates a transition, and doesn't give us enough mpeg data to initialize video playback, the player will just quit. This is added only because some users seem to want it. I don't intend to make mpv a good DVD player, so the very basic minimum will have to do. How about you just convert your DVD to proper video files?
* demux_lavf: remove unnecessary seek on initializationwm42013-12-121-2/+0
| | | | This is not needed, and actually completely incorrect.
* demux: set fps for mf:// to 1wm42013-12-101-1/+1
|
* options: allow hwaccel formats in -vf format/noformatwm42013-12-071-1/+1
| | | | | | | There are 3 users of the image format option type: demux_raw, vf_format, vf_noformat. Allow the hwaccel formats (like vdpau etc.) in general, so that the filters can use it. This won't work for demux_raw, so explicitly reject these formats there.
* video: add insane hack to work around FFmpeg/Libav insanitywm42013-11-283-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | So, FFmpeg/Libav requires us to figure out video timestamps ourselves (see last 10 commits or so), but the methods it provides for this aren't even sufficient. In particular, everything that uses AVI-style DTS (avi, vfw-muxed mkv, possibly mpeg4-in-ogm) with a codec that has an internal frame delay is broken. In this case, libavcodec will shift the packet- to-image correspondence by the codec delay, meaning that with a delay=1, the first AVFrame.pkt_dts is not 0, but that of the second packet. All timestamps will appear shifted. The start time (e.g. the time displayed when doing "mpv file.avi --pause") will not be exactly 0. (According to Libav developers, this is how it's supposed to work; just that the first DTS values are normally negative with formats that use DTS "properly". Who cares if it doesn't work at all with very common video formats? There's no indication that they'll fix this soon, either. An elegant workaround is missing too.) Add a hack to re-enable the old PTS code for AVI and vfw-muxed MKV. Since these timestamps are not reorderd, we wouldn't need to sort them, but it's less code this way (and possibly more robust, should a demuxer unexpectedly output PTS). The original intention of all the timestamp changes recently was actually to get rid of demuxer-specific hacks and the old timestamp sorting code, but it looks like this didn't work out. Yet another case where trying to replace native MPlayer functionality with FFmpeg/Libav led to disadvantages and bugs. (Note that the old PTS sorting code doesn't and can't handle frame dropping correctly, though.) Bug reports: https://trac.ffmpeg.org/ticket/3178 https://bugzilla.libav.org/show_bug.cgi?id=600
* demux_mkv: fix realvideo timestamp handlingwm42013-11-261-47/+40
| | | | | | | | | | | | | | | | | | | This was broken by the recent commits. Apparently realvideo timestamps are severely mangled, and Matroska _of course_ doesn't have the sane, umangled timestamps, but something unusable. The existing unmangling code in demux_mkv.c didn't output proper timestamps either. Instead, it was something weird that triggered sorting. Without sorting (it was disabled by default recently), you'd get decreasing PTS warnings In order to fix this, steal some code from libavcodec. Basically copy the contents of rv34_parser.c (with some changes), which makes everything magically work. (Maybe it would be better to use the libavcodec parser API, but I don't want to do that just for this. An alternative idea would be refusing to read files that have realvideo tracks, and delegate this to demux_lavf.c, but maybe that's too redical too.) I wish I hadn't notice this...
* player: move code for skipping 0-sized video packets to demuxerwm42013-11-261-0/+8
| | | | | | | | | | These packets have to be explicitly dropped, because usually libavcodec uses 0-sized packets to flush delayed frames, meaning just passing through these packets would have bad consequences. Normally, libavformat doesn't output 0-sized packets anyway. But I don't want to take any chances, so don't delete it, and just move it out of the way to demux.c.
* video: disable PTS sorting fallback by defaultwm42013-11-251-0/+2
| | | | | | | | | | | | | | | | It appears PTS sorting was useful only for avi files (and VfW-muxed mkv). Maybe it was historically also important for decoders with broken or non-existent PTS reordering (win32 codecs?). But now that we handle demuxers which outputs DTS only correctly, it just seems dead weight. Disable it by default. The --pts-association-mode option is now forced to always use the decoder's PTS value. You can still enable the old default (auto) or force sorting. But we will probably remove this option entirely at some point. Make demux_mkv export timestamps at DTS when it's in VfW mode. This is needed to get correct timestamps with the new default mode. demux_lavf already does that.
* demux_lavf: disable genpts by default, remove the builtin genpts hackwm42013-11-251-86/+9
| | | | | | | | | This was needed to determine PTS from DTS, but the previous commits make it unnecessary. The builtin genpts hack was used for DVD, because libavformat's genpts essentially went amok on DVD timestamp resets. See commit 65d87091 for details.
* demux: export dts from demux_lavf, use it for aviwm42013-11-254-17/+19
| | | | | | | | | Having the DTS directly can be useful for restoring PTS values. The avi file format doesn't actually store PTS values, just DTS. An older hack explicitly exported the DTS as PTS (ignoring the [I assume] genpts generated non-sense PTS), which is not necessary anymore due to this change.
* Reduce stheader.h includes, move stream types to mp_common.hwm42013-11-231-7/+1
|
* demux: remove gsh field from sh_audio/sh_video/sh_subwm42013-11-238-60/+54
| | | | | | | | | This used to be needed to access the generic stream header from the specific headers, which in turn was needed because the decoders had access only to the specific headers. This is not the case anymore, so this can finally be removed again. Also move the "format" field from the specific headers to sh_stream.
* video: move decoder context from sh_video into new structwm42013-11-232-47/+8
| | | | | | | | | | This is similar to the sh_audio commit. This is mostly cosmetic in nature, except that it also adds automatical freeing of the decoder driver's state struct (which was in sh_video->context, now in dec_video->priv). Also remove all the stheader.h fields that are not needed anymore.
* audio: don't write decoded audio format to sh_audiowm42013-11-231-2/+0
| | | | | | | | sh_audio is supposed to contain file headers, not whatever was decoded. Fix this, and write the decoded format to separate fields in the decoder context, the dec_audio.decoded field. (Note that this field is really only needed to communicate the audio format from decoder driver to the generic code, so no other code accesses it.)
* audio: move decoder context from sh_audio into new structwm42013-11-231-5/+0
| | | | | | | | | Move all state that basically changes during decoding or is needed in order to manage decoding itself into a new struct (dec_audio). sh_audio (defined in stheader.h) is supposed to be the audio stream header. This should reflect the file headers for the stream. Putting the decoder context there is strange design, to say the least.
* timeline: reject mplayer2 EDL files, change EDL headerwm42013-11-211-7/+4
| | | | | | | | | | | This was forgotten when the parser for mplayer2 EDL files was removed. Change the header of the mpv EDL format to include a '#', so a naive parser could skip the header as comment. (Maybe this is questionable; on the other hand, if it can be simpler, why not.) Also, strip the header in demux_edl.c before passing on the data, so the header check doesn't need to be duplicated in tl_mpv_edl.c.
* timeline: add edl:// URIswm42013-11-191-0/+4
| | | | | Questionable change from user perspective, but internally needed to implement the next commit. Also useful for testing timeline stuff.
* timeline: add new EDL formatwm42013-11-191-8/+9
| | | | | | | | | | Edit Decision Lists (EDL) allow combining parts from multiple source files into one virtual file. MPlayer had an EDL format (which sucked), which mplayer2 tried to improve with its own format (which sucked). As logic demands, mpv introduces its very own format (which sucks). The new format should actually be much simpler and easier to use, and its implementation is simpler and smaller too.
* demux: rename demux_packet.h to packet.hwm42013-11-182-2/+2
| | | | This always bothered me.
* demux_packet: add source stream indexwm42013-11-162-0/+5
| | | | Might be helpful later.
* demux: update a commentwm42013-11-161-3/+3
|
* demux: remove unused commandswm42013-11-161-2/+0
| | | | These were replaced with DEMUXER_CTRL_SWITCHED_TRACKS a while ago.
* demux: simplify handling of filepos fieldwm42013-11-164-9/+12
| | | | | | | | | | | | demuxer->filepos contains the byte offset of the last read packet. This is so that the player can estimate the current playback position, if no proper timestamps are available. Simplify it to use demux_packet->pos in the generic demuxer code, instead of bothering every demuxer implementation about it. (Note that this is still a bit incorrect: it relfects the position of the last packet read by the demuxer, not that returned to the user. But that was already broken, and is not that trivial to fix.)
* demux_lavf: remove broken and commented byte based seekswm42013-11-161-40/+0
| | | | | | | | | | | | | This was originally added for better seeking where libavformat's seek function won't work well: files with timestamp resets. In these cases, the code tried to calculate an average bitrate, and then do byte based seeks by multiplying the seek target time with the bitrate. Apparently this was unreliable enough that the code was just commented (and other parts became inactive). Get rid of it. Note that the player still does byte based seeks in these cases when doing percent-seeks.
* demux: reset EOF flag differentlywm42013-11-161-10/+9
| | | | | This should be almost equivalent, but is slightly better because the EOF flag is reset earlier.
* audio: drop "_NE"/"ne" suffix from audio formatswm42013-11-151-1/+1
| | | | | | You get the native format by not appending any suffix to the format. This change includes user-facing names, e.g. for the --format option.
* demux: use talloc for certain stream headerswm42013-11-143-48/+20
| | | | | | | Slightly simplifies memory management. This might make adding a demuxer cache wrapper easier at a later point, because you can just copy the complete stream header, without worrying that the wrapper will free the individual stream header fields.
* mf: silence compilation warningwm42013-11-132-3/+3
|
* Merge branch 'planar_audio'wm42013-11-122-7/+3
|\ | | | | | | | | Conflicts: audio/out/ao_lavc.c
| * audio: add support for using non-interleaved audio from decoders directlywm42013-11-122-7/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Most libavcodec decoders output non-interleaved audio. Add direct support for this, and remove the hack that repacked non-interleaved audio back to packed audio. Remove the minlen argument from the decoder callback. Instead of forcing every decoder to have its own decode loop to fill the buffer until minlen is reached, leave this to the caller. So if a decoder doesn't return enough data, it's simply called again. (In future, I even want to change it so that decoders don't read packets directly, but instead the caller has to pass packets to the decoders. This fits well with this change, because now the decoder callback typically decodes at most one packet.) ad_mpg123.c receives some heavy refactoring. The main problem is that it wanted to handle format changes when there was no data in the decode output buffer yet. This sounds reasonable, but actually it would write data into a buffer prepared for old data, since the caller doesn't know about the format change yet. (I.e. the best place for a format change would be _after_ writing the last sample to the output buffer.) It's possible that this code was not perfectly sane before this commit, and perhaps lost one frame of data after a format change, but I didn't confirm this. Trying to fix this, I ended up rewriting the decoding and also the probing.
* | demux: kill libmng supportwm42013-11-112-576/+0
| | | | | | | | It's a dead format that was never used anywhere.
* | demux_mf: use tallocwm42013-11-113-55/+30
| |
* | demux_mf: uncrustifywm42013-11-113-215/+213
| |
* | demux_mkv: support some raw PCM variantswm42013-11-113-3/+4
|/ | | | | | | | | | This affects 64 bit floats and big endian integer PCM variants (basically crap nobody uses). Possibly not all MS-muxed files work, but I couldn't get or produce any samples. Remove a bunch of format tags that are not needed anymore. Most of these were used by demux_mov, which is long gone. Repurpose/abuse 'twos' as mpv-internal tag for dealing with the PCM variants mentioned above.
* Remove sh_audio->samplesizewm42013-11-092-2/+0
| | | | | | | | | This member was redundant. sh_audio->sample_format indicates the sample size already. The TV code is a bit strange: the redundant sample size was part of the internal TV interface. Assume it's really redundant and not something else. The PCM decoder ignores the sample size anyway.
* playlist: rewrite PLS parserwm42013-11-041-0/+22
| | | | | | | | | | | | Somehow the new parser ends up much smaller. Much of it is because we don't parse some additional information. We just skip it, instead of parsing it and then throwing it away. More importantly, we use the physical order of entries, instead of trying to sort them by entry number. Each "File" entry is followed by a number that is supposed to be the entry number, and "File1" is first. (Should it turn out that this is really needed, an additional field should be added to playlist_entry, and then qsort().)
* demux_mkv: fix compiler warningswm42013-11-041-2/+2
| | | | | | | | | | | | | | | | Make TOOLS/matroska.pl output structs with fields sorted by name in ebml_types.h to make the order of fields deterministic. Fix warnings in demux_mkv.c caused by the first struct fields switching between scalar and struct types due to non-deterministic ebml_types.h field order. Since it's deterministic now, this shouldn't change anymore. The warnings produced by the compilers are bogus, but we want to silence them anyway, since this could make developers overlook legitimate warnings. What commits 7b52ba8, 6dd97cc, 4aae1ff were supposed to fix. An earlier attempt sorted fields in the generated C source file, not the header file. Hopefully this is the last commit concerning this issue...
* Merge branch 'master' into have_configurewm42013-11-048-39/+30
|\ | | | | | | | | Conflicts: configure
| * demux: make determining seek capability genericwm42013-11-036-13/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Instead of having each demuxer do it (only demux_mkv actually did...), let generic code determine whether the file is seekable. This requires adding exceptions to demuxers where the stream is not seekable, but the demuxer is. Sort-of try to improve handling of unseekable files in the player. Exit early if the file is determined to be unseekable, instead of resetting all decoders and then performing a pointless seek. Add an exception to allow seeking if the file is not seekable, but the stream cache is enabled. Print a warning in this case, because seeking outside the cache (which we can't prevent since the demuxer is not aware of this problem) still messes everything up.
| * demux: remove movi_start/movi_end fieldswm42013-11-036-26/+10
| | | | | | | | | | | | | | Pointless, using stream->start_pos/end_pos instead. demux_mf was the only place where this was used specially, but we can rely on timestamps instead for this case.
* | configure: uniform the defines to #define HAVE_xxx (0|1)Stefano Pigozzi2013-11-033-7/+7
|/ | | | | | | | | | | | | | | | | | | | | The configure followed 5 different convetions of defines because the next guy always wanted to introduce a new better way to uniform it[1]. For an hypothetic feature 'hurr' you could have had: * #define HAVE_HURR 1 / #undef HAVE_DURR * #define HAVE_HURR / #undef HAVE_DURR * #define CONFIG_HURR 1 / #undef CONFIG_DURR * #define HAVE_HURR 1 / #define HAVE_DURR 0 * #define CONFIG_HURR 1 / #define CONFIG_DURR 0 All is now uniform and uses: * #define HAVE_HURR 1 * #define HAVE_DURR 0 We like definining to 0 as opposed to `undef` bcause it can help spot typos and is very helpful when doing big reorganizations in the code. [1]: http://xkcd.com/927/ related
* demux: rename Windows symbolswm42013-11-024-123/+99
| | | | | | | | | | | | | | | | | | | | There are some Microsoft Windows symbols which are traditionally used by the mplayer core, because it used to be convenient (avi was the big format, using binary windows decoders made sense...). So these symbols have the exact same definition as the Windows one, and if mplayer is compiled on Windows, the symbols from windows.h are used. This broke recently just because some files were shuffled around, and the symbols defined in ms_hdr.h collided with windows.h ones. Since we don't have windows binary decoders anymore, there's not the slightest reason our symbols should have the same names. Rename them to reduce the risk for collision, and to fix the recent regression. Drop WAVEFORMATEXTENSIBLE, because it's mostly unused. ao_dsound defines its own version if the windows headers don't define it, and ao_wasapi is not available on systems where this symbol is missing. Also reindent ms_hdr.h.
* demux_mkv: fix warningwm42013-11-021-1/+1
| | | | | | | | Now that matroska.pl generates struct fields in deterministic order, this should be the last time I change this. (gcc and clang shouldn't warn about this line of code, but since they do, we want to workaround and silence the warning anyway.)
* demux_mkv: use a more universal zero initializerwm42013-11-011-1/+1
| | | | | | | | | | | | Unfortunately, we can't avoid this warning 100%, because ebml_info is written by a Perl script. I think the script writes the struct fields in random order (thanks Perl), so there's no way to know whether the first struct field is a scalar or a struct. At least {0} is always valid here, even if it shows a warning. (The compilers are wrong, see e.g. [1].) [1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53119
* Enable -Wshadowwm42013-11-011-1/+1
| | | | | | | | | This one really did bite me hard (see previous commit), so enable it by default. Fix some cases of shadowing throughout the codebase. None of these change behavior, and all of these were correct code, and just tripped up the warning.
* demux_mkv: use standard C default initialization syntaxwm42013-10-191-17/+17
|