summaryrefslogtreecommitdiffstats
path: root/demux
Commit message (Collapse)AuthorAgeFilesLines
* demux: remove audio parserwm42013-07-084-78/+0
| | | | | | | | | | | The audio parser was needed only by the "old" demuxers, and demux_rawaudio. All other demuxers output already parsed packets. demux_rawaudio is usually for raw audio, so using a parser with it doesn't usually make sense. But you can also force it to read compressed formats with fixed packet sizes, in which case the parser would have been used. This use case is probably broken now, but you will be able to do the same thing with libavformat demuxers.
* Remove old demuxerswm42013-07-0727-10562/+26
| | | | | | | | | | Delete demux_avi, demux_asf, demux_mpg, demux_ts. libavformat does better than them (except in rare corner cases), and the demuxers have a bad influence on the rest of the code. Often they don't output proper packets, and require additional audio and video parsing. Most work only in --no-correct-pts mode. Remove them to facilitate further cleanups.
* core: update metadata during playback, allow streams to export metadatawm42013-07-022-0/+16
| | | | | | | STREAM_CTRL_GET_METADATA will be used to poll for streamcast metadata. Also add DEMUXER_CTRL_UPDATE_INFO, which could in theory be used by demux_lavf.c. (Unfortunately, libavformat is too crappy to read metadata mid-stream for mp3 or ogg, so we don't implement it.)
* demux_mkv: pass extradata for opuswm42013-07-011-0/+1
| | | | Fixes playing 5.1 opus audio tracks.
* video: add a new method to configure filters and VOswm42013-06-281-2/+0
| | | | | | | | | | | | | | | | | | The filter chain and the video ouputs have config() functions. They are strictly limited to transfering the video size and format. Other parameters (like color levels) have to be transferred separately. Improve upon this by introducing a separate set of reconfig() functions, which use mp_image_params to carry format parameters. This struct contains all image format related parameters from config(), plus additional parameters such as colorspace. Change vf_rotate to use it, as well as vo_opengl. vf_rotate is just an example/test case, but vo_opengl will need it later. The intention is also to get rid of VOCTRL_SET_YUV_COLORSPACE. This information is now handed to the VOs via reconfig(). The getter, VOCTRL_GET_YUV_COLORSPACE, will still be needed though.
* demux_lavf: add one more AAC mimetypewm42013-06-251-0/+1
|
* demux_libass: do charset conversion by -subcpwm42013-06-251-3/+16
| | | | | | | | | | | | Old code used to use libass' recoding feature, which is a copy of the old MPlayer code. We dropped that a few commits ago. Unfortunately, this made it impossible to load some subtitle files, like UTF-16 files. Make .ass loading respect -subcp again. We do this by recoding the probe buffer to UTF-8, and then trying to load it normally. (Yep.) Since UTF-16 in particular will effectively half the probe buffer size, double the probe size.
* sub: prevent subtitle conversion if subs are known UTF-8wm42013-06-252-0/+2
| | | | | Currently this happens only in an obscure case (reading UTF-16 files with the old subreader).
* demux_subreader: remove iconv/enca codewm42013-06-251-154/+1
| | | | Not needed anymore, done by dec_sub.c instead.
* sub: attempt to use video FPS for frame based subtitle formatswm42013-06-252-0/+2
| | | | | This only affects demux_subreader.c for now. Maybe there is some hope this can be used for libavformat demuxers too, but I'm not sure yet.
* sub: add demux_libass wrapper, drop old hackswm42013-06-254-57/+112
| | | | | | | | | | | | demux_libass.c allows us to make subtitle format detection part of the normal file loading process. libass has no probe function, but trying to load the start of a file (the first 4 KB) is good enough. Hope that libass can even handle random binary input gracefully without printing stupid log messages, and that the libass parser doesn't accept too many non-ASS files as input. This doesn't handle the -subcp option correctly yet. This will be fixed later.
* core: don't set correct-pts mode randomlywm42013-06-251-5/+0
| | | | | | The default correct-pts mode depended on which demuxer was opened last. Often this is the subtitle demuxer. The correct-pts mode should be decided on the demuxer for video instead.
* subreader: turn into actual demuxerwm42013-06-255-129/+227
| | | | | | | | | | | | | | | | subreader.c (before this commit renamed to demux_subreader.c) was special cased to the -sub option. The plan is using the normal demuxer codepath for all subtitle formats (so we can prefer libavformat demuxers for most formats). There are some subtle changes. The probe size is restricted to 32 KB (instead of unlimitted + giving up after 100 lines of input). For formats like MicroDVD, the video FPS isn't used anymore, because it's not available on the subtitle demuxer level. Instead, hardcode it to 23.976 FPS (libavformat seems to do the same). The user can probably still use -sub-fps to fix the timing. Checking the file extension for ".utf"/".utf8"/".utf-8" is simply removed (seems worthless, was in the way, and I've never seen this anywhere).
* demux: add utility functions for preloading demuxerswm42013-06-252-5/+81
| | | | | These will be needed by subtitle demuxers, which read all data on initialization.
* demux_lavf: use stream_peek() instead of read/unreadwm42013-06-251-6/+4
| | | | | | | Simpler, reduces the amount of copying. We still have to malloc+memcpy the probe buffer though, because padding with FF_INPUT_BUFFER_PADDING_SIZE is required by libavformat.
* Move/rename subreader.cwm42013-06-252-0/+1457
|
* sub: preload external text subtitleswm42013-06-232-1/+38
| | | | | | | | If a subtitle is external, read it completely and add all subtitle events in advance when the subtitle track is selected. This is done for text subtitles only. (Note that subreader.c and subtitles loaded with libass are different and don't have anything to do with this commit.)
* stream: remove padding parameter from stream_read_complete()wm42013-06-233-3/+3
| | | | | | | | Seems like a completely unnecessary complication. Instead, always add a 1 byte padding (could be extended if a caller needs it), and clear it. Also add some documentation. There was some, but it was outdated and incomplete.
* demux: don't require fill_buffer callbackwm42013-06-233-13/+1
|
* 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 retu