summaryrefslogtreecommitdiffstats
path: root/demux
Commit message (Collapse)AuthorAgeFilesLines
* Merge branch 'cache_new'wm42013-06-166-45/+35
|\
| * stream: fix some aspects of EOF handlingwm42013-06-161-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | The stream EOF flag should only be set when trying to read past the end of the file (relatively similar to unix files). Always clear the EOF flag on seeking. Trying to set it "properly" (depending whether data is available at seek destination or not) might be an ok idea, but would require attention to too many special cases. I suspect before this commit (and in MPlayer etc. too), the EOF flag wasn't handled consistently when the stream position was at the end of the file. Fix one special case in ebml.c and stream_skip(): this function couldn't distinguish between at-EOF and past-EOF either.
| * stream: remove stream_reset()wm42013-06-165-11/+0
| | | | | | | | | | | | | | | | | | This function was called in various places. Most time, it was used before a seek. In other cases, the purpose was apparently resetting the EOF flag. As far as I can see, this makes no sense anymore. At least the stream_reset() calls paired with stream_seek() are completely pointless. A seek will either seek inside the buffer (and reset the EOF flag), or do an actual seek and reset all state.
| * demux_lavf: change probing, use stream_unread_buffer()wm42013-06-161-31/+33
| | | | | | | | | | This fixes a longstanding issue with demux_lavf probing. See previous commit.
* | demux_lavf: show metadata for OGG audio fileswm42013-06-151-5/+18
|/ | | | Whether this is a hack or not, I don't even know anymore.
* Merge branch 'sub_mess'wm42013-06-046-23/+75
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | This branch heavily refactors the subtitle code (both loading and rendering), and adds support for a few new formats through FFmpeg. We don't remove any of the old code yet. There are still some subtleties related to subreader.c to be resolved: code page detection & conversion, timing post-processing, UTF-16 subtitle support, support for the -subfps option. Also, SRT reading and loading ASS via libass should be turned into proper demuxers. (SRT is needed because Libav's is gravely broken, and we want ASS loading via libass to cover full libass format support. Both should be demuxers which are probed _before_ libavformat, so that all subtitles can be loaded through the demuxer infrastructure, and libavformat subtitles don't need to be treated in a special way.)
| * sub: pass subtitle packets directlywm42013-06-032-10/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | Before this, subtitle packets were returned as data ptr/len pairs, and mplayer.c got the rest (pts and duration) directly from the demuxer data structures. Then mplayer.c reassembled the packet data structure again. Pass packets directly instead. The mplayer.c side stays a bit awkward, because the (now by default unused) DVD path keeps getting in the way. In demux.c there's lots of weird stuff (3 functions that read packets, really?), but we want to keep the code equivalent for now to avoid hitting weird issues and corner cases.
| * demux_lavf: always set packet durationwm42013-06-031-5/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Makes WebVTT actually work. Also simplify the logic for setting duration. Only the subtitle path uses the packet duration, so the checks for STREAM_SUB as well as the keyframe flag are redundant. Apparently duration and convergence_duration are the same thing, but convergence_duration was added as Matroska-specific hack to get a higher value range (int vs. int64_t) with high resolution Matroska timebases. For us it doesn't matter, because double floats are used for timestamps and durations.
| * sub: turn subassconvert_ functions into sub converterswm42013-06-031-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This means subassconvert.c is split in sd_srt.c and sd_microdvd.c. Now this code is involved in the sub conversion chain like sd_movtext is. The invocation of the converter in sd_ass.c is removed. This requires some other changes to make the new sub converter code work with loading external subtitles. Until now, subtitles loaded via subreader.c was assumed to be in plaintext, or for some formats, in ASS (except in -no-ass mode). Then these were added to an ASS_Track. Change this so that subtitles are always in their original format (as far as decoders/converters for them are available), and turn every sub event read by subreader.c as packet to the dec_sub.c subtitle chain. This removes differences between external/demuxed and -ass/-no-ass code paths further.
| * sub: refactorwm42013-06-011-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Make the sub decoder stuff independent from sh_sub (except for initialization of course). Sub decoders now access a struct sd only, instead of getting access to sh_sub. The glue code in dec_sub.c is similarily independent from osd. Some simplifications are made. For example, the switch_id stuff is unneeded: the frontend code just has to make sure to call osd_changed() any time subtitles are switched. This is also preparation for introducing subtitle converters. It's much cleaner to completely separate demuxer header/renderer glue/decoders for this purpose, especially since sub converters might completely change how demuxer headers have to be interpreted. Also pass data as demux_packets. Currently, this doesn't help much, but libavcodec converters might need scary stuff like packet side data, so it's perhaps better to go with passing packets.
| * core: add demux_sub pseudo demuxerwm42013-06-014-5/+60
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Subtitle files are opened in mplayer.c, not using the demuxer infrastructure in general. Pretend that this is not the case (outside of the loading code) by opening a pseudo demuxer that does nothing. One advantage is that the initialization code is now the same, and there's no confusion about what the difference between track->stream, track->sh_sub and mpctx->sh_sub is supposed to be. This is a bit stupid, and it would be much better if there were proper subtitle demuxers (there are many in recent FFmpeg, but not Libav). So for now this is just a transition to a more proper architecture. Look at demux_sub like an artifical limb: it's ugly, but don't hate it - it helps you to get on with your life.
| * sub: add sd_spu.c to wrap spudec, cleanup mplayer.cwm42013-05-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This unifies the subtitle rendering path. Now all subtitle rendering goes through sd_ass.c/sd_lavc.c/sd_spu.c. Before that commit, the spudec.h functions were used directly in mplayer.c, which introduced many special cases. Add sd_spu.c, which is just a small wrapper connecting the new subtitle render API with the dusty old vobsub decoder in spudec.c. One detail that changes is that we always pass the palette as extra data, instead of passing the libdvdread palette as pointer to spudec directly. This is a bit roundabout, but actually makes the code simpler and more elegant: the difference between DVD and non-DVD dvdsubs is reduced. Ideally, we would just delete spudec.c and use libavcodec's DVD sub decoder. However, DVD playback with demux_mpg produces packets incompatible to lavc. There are incompatibilities the other way around as well: packets from libavformat's vobsub demuxer are incompatible to spudec.c. So we define a new subtitle codec name for demux_mpg subs, "dvd_subtitle_mpg", which only sd_spu can decode. There is actually code in spudec.c to "assemble" fragments into complete packets, but using the whole spudec.c is easier than trying to move this code into demux_mpg to fix subtitle packets. As additional complication, Libav 9.x can't decode DVD subs correctly, so use sd_spu in that case as well.
* | demux: fix "-demuxer mpegps", don't force demuxer in stream_dvdwm42013-06-021-1/+1
| | | | | | | | | | | | | | | | | | | | Internally, stream_dvd.c returned DEMUXER_TYPE_MPEG_PS, and the same value was hardcoded to enforced usage of demux_lavf in demux.c. But "-demuxer mpegps" basically did the same, so that switch was broken for this format. Undo this and don't request a demuxer in stream_dvd.c. demux_lavf.c is (probably) good enough to probe correctly with DVD. Otherwise, we'd actually have to do something completely different to force the libavformat demuxer.
* | demux_mkv: clang: fix -Wunused-functionStefano Pigozzi2013-05-301-0/+2
|/ | | | This was introduced with c0db930d.
* demux_mkv: replace awkward goto by function callwm42013-05-301-39/+43
| | | | Requires reindenting a large code block to minimize random control flow.
* demux_mkv: make sure wavpacks works with older libavcodec versionswm42013-05-301-0/+15
| | | | | | | | The new wavpack packet format (see previous commit) doesn't work with older libavcodec versions, so disable the new code in this case. The version numbers are only approximate, since the libavcodec version wasn't bumped with the wavpack change, but it's close enough.
* demux_mkv: fix wavpack in mkvwm42013-05-301-0/+92
| | | | | | | | | | | | | | | Libav introduced a silent API breakage by changing what wavpack packets the libavcodec decoder accepts. Originally the libavcodec codec accepted Matroska-style wavpack packets. Libav commit 9b6f47c removed this capability from the libavcodec code, and added code to libavformat's Matroska demuxer to "rearrange" wavpack packets. Since demux_mkv still sent Matroska-style packets, playback failed. Fix this by "rearranging" packets in demux_mkv as well by copying libavformat's code. (The best kind of fix.) Tested with [CCCP]_Mega_Lossless_Audio_Test.mkv, as well as with a sample generated by mkvmerge.
* core: avoid deselecting and reselecting stream needlesslywm42013-05-291-0/+4
| | | | | | | | | The core deselected all streams on initialization, and then selected the streams it actually wanted. This was no problem for demux_mkv/demux_lavf, but old demuxers (like demux_asf) could lose some packets. The problem is that these demuxers can buffer some data on initialization, which then is flushed on track switching. Fix this by explicitly avoiding deselecting a wanted stream.
* demux_asf: fix after commit 5165e19wm42013-05-292-7/+4
| | | | | This demuxer reallocated packets on its own, instead of using the demux.c functions, which clashed with a recent change.
* demuxer_lavf: use audio/mpeg mime type for mp3wm42013-05-271-0/+1
| | | | | Basically, add exactly the same hacks for mp3 as we did for AAC. Should make starting mp3 streams much faster.
* demux_lavf: minimal probing and reduced analyzeduration for AAC over HTTPwm42013-05-271-14/+43
| | | | | | | | | | | | | | | | | | | | | | | When AAC is streamed over HTTP, using libavformat defaults is pathetically slow. One solution for that is skipping probing and using the mimetype to identify that it's AAC instead. This is what we did before this commit (and ffmpeg does it too, but their logic is too "inaccessible" for mpv). This is still pretty fragile though. Make it a bit more robust by requiring minimal probing. A probescore of 25 is reached after feeding 2 KB to libavformat (instead of > 500 KB for the normal probescore), so use that. This is done only when streaming AAC from HTTP to reduce the possibility of weird breakages for other formats. Also reduce analyzeduration. The default analyzeduration will make libavformat read lots of data, which makes playback start slow. So we set analyzeduration to a low value. On the other hand, doing that for other formats is risky, because there are unspecified effects with certain "strange" formats (like transport streams). So we do this only if we're streaming AAC from HTTP as well. tl;dr libavformat is shit for media players
* options: add allow-mimetype suboption for demux_lavfwm42013-05-271-1/+2
| | | | | | | This can control whether demux_lavf should use the HTTP mime type to determine the format, instead of probing the data with the libavformat API. Do this to allow easier debugging in case the mimetype is incorrect. (This is done only for AAC streams right now.)
* demux_lavf: print how many bytes are read by avformat_find_stream_info()wm42013-05-261-0/+6
| | | | | | Can be helpful for debugging slow stream startup. Also add a comment about BIO_BUFFER_SIZE.
* demux_mkv: defer reading of seek index until first seekwm42013-05-231-3/+42
| | | | | | | | | | | | | | | | | | | | | | Playing Youtube videos often requires an additional seek to the end of the file. This flushes the stream cache. The reason for the seek is reading the cues (seek index). This poses the question why Google is muxing its files in such a way, since nothing in Matroska mandates that cues are located at the end of the file, but we want to handle this situation better anyway. The seek index is not needed for normal playback, only for seeking. This commit changes header parsing such that the index is not read on initialization in order to avoid the additional stream-level seek. Instead, read the index on the first demuxer-level seek, when the seek index is actually needed. If the cues are at the beginning of the file, they are read immediately as part of the normal header reading process. This commit changes behavior only if cues are outside of the header (i.e. not in the area between EBML header and clusters), and linked by a SeekHead. Other level 1 elements linked by the SeekHead might still cause seeks to the end of the file, although that seems to be rare.
* demux_mkv: use a single flag to indicate whether cues have been readwm42013-05-231-1/+3
| | | | | | | | | | | | Before this commit, the demuxer would in theory accept multiple cues elements (and append its contents to the index in the order as encountered during reading). According to the Matroska specification, there can be only one cues element in the segment, so this seems like an overcomplication. Change it so that redundant elements are ignored, like with all other unique header elements. This makes implementing deferred reading of the cues element easier.
* demux_lavf: workaround minor ffmpeg memory leakwm42013-05-212-7/+1
| | | | | | | | | | | | The sequence of avcodec_alloc_context3() / avcodec_copy_context() / avcodec_close() / av_free() leaks some memory. So don't copy the context and use it directly. Originally avcodec_copy_context() was used to guarantee that libavformat can't update the fields of the context during demuxing in order to make things a little more robust, but it's not strictly needed, and ffmpeg/ffplay don't do this anyway. Still might make the situation worse should we move demuxing into a separate thread, though.
* demux: workaround for -demuxer mpegts -correct-ptswm42013-05-212-8/+16
| | | | | | | | | | | | | | | | | | | | | | Using -demuxer mpegts -correct-pts triggered the assertion in ds_get_packet2(). This is not surprising, because the correct-pts code was changed to accept _complete_ packets, while all the old demuxers (including the mpegts demuxer) require you to use "partial" packet reads, together with the video_read_frame(). (That function actually parses video frames, so fragments of the original "packets" can be fed to the decoder.) However, it returns out demux_ts packet's are mostly useable. demux_ts still adds an offset (i.e. ds->buffer_pos != 0) to the packets when calling internal parser functions, such as in parse_es.c. While this is unclean design due to mplayer's old video demuxing/decoding path, it can be easily be made work by modifying the packet as returned by ds_get_packet2(). We also have to change the packet freeing code, as demux_packet->buffer doesn't have to point to the start of the memory allocation anymore. MPlayer handles this "correctly" because it doesn't have a function that reads a complete packet.
* demux_mkv: support dirac in mkvwm42013-05-212-0/+2
| | | | | | | | | | | | | | Nobody uses this, and this is an absolute waste of time. Even the user who reported this turned out to have produced a sample manually. Sample produced with: wget http://diracvideo.org/download/test-streams/raw/vts/vts.LD-8Mb.drc mkvmerge -o dirac.mkv vts.LD-8Mb.drc mkvmerge writes a sort of broken aspect ratio. libavformat interprets it as 1:1 PAR, while demux_mkv thinks this is a 1:1 DAR. Maybe libavformat is more correct here.
* Silence some compiler warningswm42013-05-211-1/+1
| | | | None of these were actual issues.
* demux_mkv: export Matroska title element as metadatawm42013-05-151-0/+3
|
* Merge branch 'audio_changes'wm42013-05-124-12/+16
|\ | | | | | | | | Conflicts: audio/out/ao_lavc.c
| * core: use channel map on demuxer level toowm42013-05-124-12/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This helps passing the channel layout correctly from decoder to audio filter chain. (Because that part "reuses" the demuxer level codec parameters, which is very disgusting.) Note that ffmpeg stuff already passed the channel layout via mp_copy_lav_codec_headers(). So other than easier dealing with the demuxer/decoder parameters mess, there's no real advantage to doing this. Make the --channels option accept a channel map. Since simple numbers map to standard layouts with the given number of channels, this is downwards compatible. Likewise for demux_rawaudio.
* | demux: fix big endian PCM in mkv with demux_mkvwm42013-05-111-0/+1
| |
* | demux: restructure chapter seeking codewm42013-05-091-8/+8
| | | | | | | | | | | | Arrange the code such that commenting the first if will allow doing stream chapter seeks instead of time chapter seeks again, if both are possible.
* | demux: don't name unknown chapters "unknown"wm42013-05-061-2/+1
| | | | | | | | The frontend's fallback for missing chapter names is better.
* | stream: report chapter times, use time seeks for DVD chapterswm42013-05-061-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Allow the stream layer to report chapter times. Extend stream_dvd to do this. I'm not 100% sure whether the re-used code is bug-free (because it was used for slave-mode and/or debugging only). MAke the frontend do time-based seeks when switching DVD chapters. I'm not sure if there's a real reason STREAM_CTRL_SEEK_TO_CHAPTER exists (maybe/hopefully not), but we will see. Note that querying chapter times in demuxer_chapter_time() with the new STREAM_CTRL_GET_CHAPTER_TIME could be excessively slow, especially with the cache enabled. The frontend likes to query chapter times very often. Additionally, stream_dvd uses some sort of quadratic algorithm to list times for all chapters. For this reason, we try to query all chapters on start (after the demuxer is opened), and add the chapters to the demuxer chapter list. demuxer_chapter_time() will get the time from that list, instead of asking the stream layer over and over again. This assumes stream_dvd knows the list of chapters at the start, and also that the list of chapters never changes during playback. This seems to be true, and the only exception, switching DVD titles, is not supported at runtime (and doesn't need to be supported).
* | demux: remove retrieval of chapter end timewm42013-05-062-5/+3
| | | | | | | | | | | | | | The frontend doesn't use this. Also use double for returning the chapter times. Everything uses double for times, and there's no reason to use float here.
* | Fix some cppcheck / scan-build warningswm42013-05-062-5/+2
| | | | | | | | | | | | | | | | These were found by the cppcheck and scan-build static analyzers. Most of these aren't interesting (the 2 previous commits fix some interesting cases found by these analyzers), and they don't nearly fix all warnings. (Most of the unfixed warnings are spam, things MPlayer never cared about, or false positives.)
* | demux: use talloc for packetswm42013-05-051-15/+19
| | | | | | | | No functional change.
* | core: ignore backstep command if demuxer is not capablewm42013-05-051-0/+2
| | | | | | | | | | | | Also, mark demuxer as not capable if DVD playback is done. The problem with DVD is that playback time (stream_pts) is not reported frame-exact, and the time is a "guess" at best.
* | demux_lavf: use demuxer ID for transport streamswm42013-05-051-1/+4
| | | | | | | | | | Might help mapping tracks correctly to stream_bluray, fixing the issue with the track language not being reported.
* | demux: use demux_lavf instead of demux_mpg for DVD playbackwm42013-05-051-1/+1
| | | | | | | | | | | | | | | | | | | | With the commit "demux_lavf: fix DEMUXER_CTRL_RESYNC", DVD playback seems to work nicely with demux_lavf, and maybe works even better than with demux_mpg. The old demuxer can be forced with: --demuxer=mpegps If no regressions surface, demux_mpg.c will be deleted later.
* | demux_lavf: fix DEMUXER_CTRL_RESYNCwm42013-05-051-1/+1