summaryrefslogtreecommitdiffstats
path: root/demux
Commit message (Collapse)AuthorAgeFilesLines
* 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
| | | | | | | | | | gcc and clang happen to allow {} to default-initialize a struct, but strictly speaking, C99 requires at least {0}. In one case, we use {{0}}, but that's only because gcc as well as clang are too damn stupid not to warn about {0}, which is a perfectly valid construct in this case. (Sure is funny, don't warn about the non-standard case, but warn about another standard conform case.)
* demux_mkv: cosmetics: add redundant braces for consistent stylewm42013-10-191-27/+46
| | | | | | | | | | | | | | Leaving these braces away just because the syntax allows them is really obnoxious. It removes the visual cues which help understanding the code at the first look. For the record, if (cond) something(); is ok, as long as there's no else branch, and the if body is one physical line. But everything else should have braces.
* demux_mkv: fill ordered chapters info only if it's presentwm42013-10-191-14/+16
| | | | | | This was probably not a real problem. But it's not entirely clear whether this could actually happen or not, so it's better to be defensive. The code is now also somewhat easier to understand.
* Merge Matroska ordered chapter changeswm42013-10-172-18/+54
|\ | | | | | | | | | | | | This adds support for ChapterSegmentEditionUID (pull request #258), and also fixes issue #278 (pull request #292). In fact, this is a straight merge of pr/292, which also contains pr/258.
| * matroska: select the edition using the requested edition uidBen Boeckel2013-10-071-2/+21
| |
| * matroska: set the edition uid when reading a chapter referenceBen Boeckel2013-10-071-1/+3
| |
| * matroska: parse the requested edition for the segment referenceBen Boeckel2013-10-071-5/+5
| |
| * matroska: store segment/edition uids in a single structureBen Boeckel2013-10-072-11/+26
| | | | | | | | | | | | To support edition references in matroska chapters, editions need to be remembered for each chapter and source. To facilitate easier management of these now-paired uids, a single structure is used.
* | demux_mkv: add support for HEVCwm42013-10-163-0/+4
| | | | | | | | | | | | | | | | Note that you still need --vd-lavc-o='strict=-2' to enable the decoder. Also, there's no guarantee that all required features for HEVC demuxing are actually implemented, nor that the current muxing schema is the final one.
* | talloc: change talloc destructor signaturewm42013-10-132-6/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | Change talloc destructor so that they can never signal failure, and don't return a status code. This makes our talloc copy even more incompatible to upstream talloc, but on the other hand this is preparation for getting rid of talloc entirely. (The talloc replacement in the next commit won't allow the talloc_free equivalent to fail, and the destructor return value would be useless. But I don't want to change any mpv code either; the idea is that the talloc replacement commit can be reverted for some time in order to test whether the talloc replacement introduced a regression.)
* | demux_raw: set a default video sizewm42013-10-071-2/+2
|/
* cosmetics: replace "CTRL" defines by enumswm42013-10-021-8/+10
| | | | Because why not.
* matroska: prevent uids from being dereferenced when NULLBen Boeckel2013-09-271-5/+5
| | | | | | The old code prevented it since uids being NULL makes a 0 talloc length. Now that we're iterating over a specific length, NULL can be dereferenced.
* matroska: fix uninitialized memory accesses with ordered chaptersBen Boeckel2013-09-262-1/+2
| | | | | | | There is uninitialized memory access if the actual size isn't passed along. In the worst case, this can cause a source to be loaded against the uninitialized memory, causing a false count of found versus required sources, preventing the "Failed to find ordered chapter part" message.
* demux: don't print "Clip info:" line if there are no tagswm42013-09-231-1/+1
|
* network: fix rtsp playbackwm42013-09-221-1/+22
| | | | | | | | | | | | | | By default, libavformat uses UDP for rtsp playback. This doesn't work very well. Apparently the reason is that the buffer sizes libavformat chooses for UDP are way too small, and switching to TCP gets rid of this issue entirely (thanks go to Reimar Döffinger for figuring this out). In theory, you can set buffer sizes as libavformat options, but that doesn't seem to help. Add an option to select the rtsp transport, and make TCP the default. Also remove an outdated comment from stream.c.
* demux_mkv: don't add too many subtitle packets during seekingwm42013-09-161-14/+19
| | | | | | | | | | | | | | | | | | | | | In insane files with a very huge number of subtitle events, and if the --demuxer-mkv-subtitle-preroll option is given, seeking can still overflow the packet queue. Normally, the subtitle_preroll variable specifies the maximum number of packets that can be added. But once this number is reached, the normal seeking behavior is enabled, which will add all subtitle packets with the right timestamps to the packet queue. At this point the next video keyframe can still be quite far away, with enough subtitle packets on the way to overflow the packet queue. Fix this by always setting an upper limit of subtitle packets read during seeking. This should provide additional robustness even if the preroll option is not used. This means that even with normal seeking, at most 500 subtitle packets are demuxed. Packets after that are discarded. One slightly questionable aspect of this commit is that subtitle_preroll is never reset in audio-only mode, but that is probably ok.
* demux_playlist: add mov RTSPtext tag parserBenjamin Franzke2013-09-141-0/+18
| | | | | | | | | | | | | | | | | The quicktime html scripting guide suggests to wrap urls not necesarly associated with quicktime in a .mov file. (so that when <embed>ing videos quicktime would be forced.) These mov files may contain several "Text Hacks". One of these is RTSPtext. The suggested/allowed format (as regex) is like: RTSPtext[ \r]RTSP://url See also p.51 of: https://developer.apple.com/library/mac/documentation/QuickTime/Conceptual/QTScripting_HTML/QTScripting_HTML.pdf In reality there are also files like (e.g. zdfmediathek.de): RTSPtext\nrtsp://url\n\n Lets handle these files as a playlist with one element.
* core: add --deinterlace option, restore it with resume functionalitywm42013-09-131-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | The --deinterlace option does on playback start what the "deinterlace" property normally does at runtime. You could do this before by using the --vf option or by messing with the vo_vdpau default options, but this new option is supposed to be a "foolproof" way. The main motivation for adding this is so that the deinterlace property can be restored when using the video resume functionality (quit_watch_later command). Implementation-wise, this is a bit messy. The video chain is rebuilt in mpcodecs_reconfig_vo(), where we don't have access to MPContext, so the usual mechanism for enabling deinterlacing can't be used. Further, mpcodecs_reconfig_vo() is called by the video decoder, which doesn't have access to MPContext either. Moving this call to mplayer.c isn't currently possible either (see below). So we just do this before frames are filtered, which potentially means setting the deinterlacing every frame. Fortunately, setting deinterlacing is stable and idempotent, so this