summaryrefslogtreecommitdiffstats
path: root/demux
Commit message (Collapse)AuthorAgeFilesLines
* demux_mkv: fix segfault issue playing back VC1 in a mkvBin Jin2013-04-271-1/+1
| | | | This bug was introduced in commit 06eee1b.
* demux_mkv: cosmeticswm42013-04-241-4/+3
|
* demux_mkv: fix out of range comparisonwm42013-04-241-1/+1
| | | | | | | | | | | This check was always false: if (num == EBML_UINT_INVALID) Fix it by using the proper type for the num variable. This case actually doesn't really matter, and this is just for hiding the warning and for being 100% correct.
* demux_lavf: fix subtitle seeking before start of the filewm42013-04-211-2/+7
| | | | | | | | | | | | | | | | | | When trying to seek before the start of the file, which usually happens when using the arrow keys to seek to the start of the file, external libavformat demuxed subtitles will be invisible. This is because seeking in the external subtitle file fails, so the subtitle demuxer is left in a random state. This is actually similar to the normal seeking path, which has some fallback code to handle this situation. Add such code to the subtitle seeking path too. (Normally, all demuxer support av_seek_frame(), except subtitles, which support avformat_seek_file() only. The latter was meant to be the "new" seeking API, but this never really took off, and using it normally seems to cause worse seeking behavior. Or maybe we just use it incorrectly, nobody really knows.)
* demux_mkv: always set track->codec_id to a stringwm42013-04-201-1/+3
| | | | | Otherwise audio/video/sub track handling code would dereference the NULL pointer.
* demux_mkv: always add subtitle trackswm42013-04-201-26/+26
| | | | Even if the codec is unknown.
* demux: remove some unused sh_video_t fieldswm42013-04-203-10/+1
| | | | Completely mysterious, and its values were never actually used.
* demux: get rid of sh_common_twm42013-04-202-21/+14
| | | | | | The only reason this existed was the parsing code. Even though it could have been used for video, it's audio-only, so just move this to sh_audio_t.
* sub, demux: identify subtitle types with the codec namewm42013-04-206-59/+25
| | | | | | | | | Get rid of the 1-char subtitle type field. Use sh_stream->codec instead just like audio and video do. Use codec names as defined by libavcodec for simplicity, even if they're somewhat verbose and annoying. Note that ffmpeg might switch to "ass" as codec name for ASS, so we don't bother with the current silly "ssa" name.
* demux: remove useless vid/aid/sid fieldswm42013-04-203-7/+1
| | | | | Only demux_ts.c used sid in one case, replace that by reading the same value from another location.
* demux: fix clearing of input paddingwm42013-04-201-2/+2
| | | | | | MP_INPUT_BUFFER_PADDING_SIZE and FF_INPUT_BUFFER_PADDING_SIZE are both 16. The doxygen for FF_INPUT_BUFFER_PADDING_SIZE says only the first 23 bits must to be 0, but this is probably a lie.
* demux_mkv: introduce new_demux_packet_from() and use itwm42013-04-203-10/+15
|
* demux: remove some unused thingswm42013-04-203-47/+4
|
* demux_lavf: simplifywm42013-04-201-147/+74
| | | | | | | | | | | | | | This removes the stream handling mess by using a single list for all stream types. One consequence is that new streams are always set to AVDISCARD_ALL, which could be an issue if packets are read before initializing other streams. However, this doesn't seem to an issue for various reasons, so we don't do anything about it. The new code strictly assumes that libavformat never removes or reorders streams once added to AVFormatContext->streams. Undefined behavior will result if it does.
* demux_mkv: simplify use of demuxer APIwm42013-04-201-106/+62
| | | | | | | mkv_track_t now references sh_stream directly, instead of using an ID. Also remove all accesses to demux_stream (demuxer->video etc.). Remove some slave-mode things on the way, like "ID_SID_..." messages.
* demux: add functions to simplify demuxerswm42013-04-203-7/+47
| | | | | | | | | | | | | | Some preparations to simplify demux_mkv and demux_lavf. struct demux_stream manages state for each stream type that is being demuxed (audio/video/sub). demux_stream is rather annoying, especially the id and sh members, which are often used by the demuxers to determine current stream and so on. Demuxers don't really have to access this, except for testing whether a stream is selected and to add packets. Add a new_sh_stream(), which allows creating streams without having the caller specify any kind of stream ID. Demuxers should just use sh_stream pointers, instead of multiple kinds of IDs and indexes.
* demux_mkv: code cleanupeng2013-04-201-20/+23
| | | | | | Cleanup based on results from cppcheck-1.59 Reduce the scope of several variables Replace 2 calloc/realloc calls with a single malloc
* demux_mkv: use new way of track switchingwm42013-04-201-45/+0
| | | | | | Since demux_mkv queries the demuxer state when reading packets, track switching is completely passive. Cycling etc. is done by the frontend. As result, all track switching code can be removed.
* demux: simpler way to notify demuxers about track switcheswm42013-04-202-2/+11
| | | | This interfaces assumes track switching is always successful.
* demux_mkv: remove pointless video track selectionwm42013-04-201-37/+0
| | | | Possibly once needed, now it's just redundant code.
* matroska: update dead linkwm42013-04-201-1/+1
|
* demux_mkv: support vp9wm42013-04-203-0/+3
| | | | Note that ffmpeg doesn't provide a decoder by default yet.
* core: matroska: support concatenated segmentswm42013-04-202-10/+53
| | | | | | | | | | | | | | | | | | | | | Matroska files can contain multiple segments, which are literally further Matroska files appended to the main file. They can be referenced by segment linking. While this is an extraordinarily useless and dumb feature, we support it for the hell of it. This is implemented by adding a further demuxer parameter for skipping segments. When scanning for linked segments, each file is opened multiple times, until there are no further segments found. Each segment will have a separate demuxer instance (with a separate file handle etc.). It appears the Matroska spec. has an even worse feature for segments: live streaming can completely reconfigure the stream by starting a new segment. We won't add support for it, because there are 0 people on this earth who think Matroska life streaming is a good idea. (As opposed to serving Matroska/WebM files via HTTP.)
* demux_mkv: don't terminate if there are no clusterswm42013-04-201-2/+3
| | | | | | Matroska segment linking allows abusing Matroska files as playlists without any actual video/audio/sub data, making files without any clusters still useful for the frontend.
* demux_mkv: simplify handle_block() logic a bitwm42013-04-201-11/+8
|
* demux_mkv: verify laces separately, and in all caseswm42013-04-201-4/+10
|
* demux_mkv: get rid of the duplicated lace case labelswm42013-04-201-9/+4
| | | | | Also change the extracting of the lace type bitfield from flags to make it more apparent that the value range is 0-3.
* demux_mkv: there can be 256 laceswm42013-04-201-6/+5
| | | | | The lace number is stored with an offset of 1, so the maximum number of laces is 255+1=256.
* demux_mkv: check block malloc() resultwm42013-04-201-0/+2
|
* demux_mkv: use a bounded buffer for block datawm42013-04-203-120/+122
| | | | Should help avoiding out-of-bounds reads.
* demux_mkv: static allocation for lace sizes bufferwm42013-04-201-12/+8
| | | | | | | | Avoid messy memory management and error handling. remove tmp_lace_buffer non-sense Not sure how my mind got 8k, or how this made sense at all.
* demux_mkv: remove redundant checkwm42013-04-201-39/+37
|
* demux_mkv: fix seeking with index generationwm42013-04-201-45/+68
| | | | | | | | | | | | | | | | | | | | | | | | | | | Relative seeks backwards didn't work too well with incomplete files, or other files that are missing the seek index. The problem was that the on-the-fly seek index generation simply added cluster positions as seek entries. While this is perfectly fine, the seek code had no information about the location of video key frames. For example, a 5 second long cluster can have only 1 video key frame, which is located 4 seconds into the cluster. Seeking backwards by one second while still located in the same cluster would select this cluster as seek target again. Decoding would resume with the key frame, giving the impression that seeking is "stuck" at this frame. Make the generated index aware of key frame and track information, so that video can always be seeked in an idea way. This also uses the normal block parsing code for indexing the clusters, instead of the suspicious looking special code. (This code didn't parse the Matroska elements correctly, but was fine for files with normal structure. Files with corrupted clusters or clusters formatted for streaming were not handled properly.) Skipping is now quite a bit slower (takes about twice as long as before), but it removes the special cased skipping code, and it's still much faster (at least twice as fast) than libavformat. It needs to do more I/O (no more skipping entire clusters, all data is read), and has more CPU usage (more data needs to be parsed).
* demux_mkv: move Block header parsing codewm42013-04-201-34/+43
| | | | | | Move parts of the Block element parsing to read_block(). This way read_block() can return block time and track information in struct block_info.
* demux_mkv: split reading blocks and reading packetswm42013-04-201-37/+47
| | | | | | Move most code from demux_mkv_fill_buffer() to read_next_block(). The former is supposed to read raw blocks, while ..fill_buffer() reads blocks and turns them into packets.
* demux_mkv: move BlockGroup reading code to a separate functionwm42013-04-201-49/+61
| | | | | | | | | | Somehow this was setup such that a BlockGroup can be incrementally read (at least in theory). This makes no sense, as BlockGroup can contain only one Block (despite its name). There's no need to read this incrementally, and makes the code confusing for no gain. Read all the BlockGroup sub-elements with a single function call, without keeping global state for BlockGroup parsing.
* demux_mkv: factor block readingwm42013-04-201-55/+61
| | | | | | | | | | The code for reading block data was duplicated. Move it into a function. Instead of returning on error (possibly due to corrupt data) and signalling EOF, continue by trying to find the next block. This makes error handling slightly simpler too, because you don't have to care about freeing the current block. We could still signal EOF in this case, but trying to resync sounds better for dealing with corrupted files.
* demux_mkv: fix streaming clusterswm42013-04-201-1/+9
| | | | | | Matroska files prepared for streaming have clusters with unknown size. These files are pretty rare, see e.g. test4.mkv from the official Matroska test file collection.
* demux_mkv: simplify cluster reading codewm42013-04-201-32/+24
| | | | | | | | | | | | | The end positions of the current cluster and block were managed by tracking their size and how much of them were read, instead of just using the absolute end positions. I'm not sure about the reasons why this code was originally written this way. One obvious concern is reading from pipes and such, but the stream layers hides this. stream_tell(s) works even when reading from pipes. It's also a fast call, and doesn't involve the stream implementation or syscalls. Keeping track of the cluster/block end is simpler and there's no reason why this wouldn't work.
* demux_mkv: use normal index data structure even for incomplete fileswm42013-04-201-84/+63
| | | | | | | | | | | | Incomplete files don't have a valid index, because the index is usually located near the end of a file. In this case, an index is created on the fly during demuxing, or when seeks are done. This used a completely different code path, which leads to unnecessary complications and code duplication. Use the normal index data structure instead. The seeking code at the end of seek_creating_index() (in this commit renamed to create_index_until()) is removed. The normal seek code does the same thing instead.
* demux: simplify chapter appending codewm42013-04-121-14/+8
| | | | | This pre-allocation looked tricky and awkward. Use MP_TARRAY_APPEND(), which makes the code simpler. This even keeps the pre-allocation.
* demux: always sort chapterswm42013-04-122-8/+7
| | | | | | | | | | | The condition that checked whether the chapters are out of order and should be sorted was inverted. This likely wasn't noticed in testing, because even if the chapters are unsorted, if the last two chapters were sorted, the rest got sorted too. Instead of doing this silly check, always sort the chapters after demuxer initialization. Also make sure the sort order is stable in case chapter start times are the same (original_index check).
* demux: fix a specific gcc 4.8 warning that may hint to mis-optimized codeRudolf Polzer2013-04-091-0/+3
| | | | | | | | CC demux/demux.o demux/demux.c: In function 'demuxer_switch_track': demux/demux.c:1241:29: warning: array subscript is above array bounds [-Warray-bounds] int new_id = demuxer->ds[type]->id; ^
* demux_mkv: move preroll subtitle check to the right placewm42013-04-041-2/+2
| | | | | | | | No subtitle selected was supposed to disable the preroll logic completely. However, the packet skipping logic was not properly enabled, so the demuxer would still return subtitle packets from before the seek target timecode. This shouldn't matter at all in practice, but fixing this makes the code clearer.
* demux_mkv: try to show current subtitle when seekingwm42013-04-042-9/+32
| | | | | | | | | | | | | | | | | Makes sure that seeking to a given time position shows the subtitle at that position. This can fail if the subtitle packet is not close enough to the seek target. Always enabled for hr-seeks, and can be manually enabled for normal seeks with --mkv-subtitle-preroll. This helps displaying subtitles correctly with ordered chapters. When switching ordered chapter segments, a seek is performed. If the subtitle is timed slightly before the start of the segment, it normally won't be demuxed. This is a problem with all seeks, but in this case normal playback is affected. Since switching segments always uses hr-seeks, the code added by this commit is always active in this situation. If no subtitles are selected or the subtitles come from an external file, the demuxer should behave exactly as before this commit.
* demux_mkv: fix handling of 0 DisplayWidth/Heightwm42013-04-041-2/+5
| | | | | | | | | Commit 546ae23 fixed aspect ratio if the DisplayWidth or DisplayHeight elements were missing. However, some bogus files [1] can have these elements present in the file, but set to 0. Use 1:1 pixel aspect for such files. [1] https://ffmpeg.org/trac/ffmpeg/ticket/2424
* demux_mkv: don't print non-sense warning on normal EOFwm42013-03-301-1/+1
| | | | | | | | | | | | | | | Commit ac1c5e6 (demux_mkv: improve robustness against broken files) added code to skip to the next cluster on error conditions. However, reaching normal EOF triggers this code as well, so explicitly check for EOF before this happens. Note that the EOF flag is only set _after_ reading the last byte, so EOF needs to be checked after the fact. (Or in other words, we must check for EOF after the ebml_read_id() call.) (To answer the question why reading packets actually reaches EOF, even if there's the seek index between the last packet and the end of the file: the cluster reading code skips the seeking related EBML elements as normal part of operation, so it hits EOF gracefully when trying to find the next cluster.)
* demux_mkv: improve robustness against broken fileswm42013-03-283-8/+73
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixes test7.mkv from the Matroska test file collection, as well as some real broken files I've found in the wild. (Unfortunately, true recovery requires resetting the decoders and playback state with a manual seek, but it's still better than just exiting.) If there are broken EBML elements, try harder to skip them correctly. Do this by searching for the next cluster element. The cluster element intentionally has a long ID, so it's a suitable element for resynchronizing (mkvmerge does something similar). We know that data is corrupt if the ID or length fields of an element are malformed. Additionally, if skipping an unknown element goes past the end of the file, we assume it's corrupt and undo the seek. Do this because it often happens that corrupt data is interpreted as correct EBML elements. Since these elements will have a ridiculous values in their length fields due to the large value range that is possible (0-2^56-2), they will go past the end of the file. So instead of skipping them (which would result in playback termination), try to find the next cluster instead. (We still skip unknown elements that are within the file, as this is needed for correct operation. Also, we first execute the seek, because we don't really know where the file ends. Doing it this way is better for unseekable streams too, because it will still work in the non-error case.) This is done as special case in the packet reading function only. On the other hand, that's the only part of the file that's read after initialization is done.
* demux_mkv: fix skipping broken header elementswm42013-03-281-1/+1
| | | | | | | | | | | | | | | | | | | | | | Fixes test4.mkv from the Matroska test file collection. demux_mkv_open() contains a loop that reads header elements. It starts by reading the EBML element ID with ebml_read_id(). If there is broken data in the header, ebml_read_id() might return EBML_ID_INVALID. However, that is not handled specially, and the code for handling unknown tags is invoked. This reads the EBML element length in order to skip data, which, if the EBML ID is broken, is entirely random. This caused a seek beyond the end of the file, making the demuxer fail. So don't skip any data if the EBML ID was invalid, and simply try to read the next element. ebml_read_id() reads at least one byte, so the parsing loop won't get stuck. All in all this is rather questionable, but since this affects error situations only, makes behavior a bit more robust (no random seeks), and actually fixes at least one sample, it's ok. libavformat's demuxer handled this.
* demux_mkv: set correct aspect ratio even if DisplayHeight is unsetwm42013-03-281-2/+4
| | | | | | | Fixes the file test2.mkv from the official Matroska test file collection. libavformat does the same thing.
* demux: fix regressions by restricting cover art hack furtherwm42013-03-191-3/+3
| | | | | | | | | | | | | | | | | | | | The code modified by this commit is supposed to prevent demuxing the whole file when cover art is present. (The problem with cover art is that the ffmpeg libavformat API doesn't signal video EOF correctly - so we try to read more packets to find the next video frame, which results in demuxing and queuing the whole audio stream.) This caused regressions for files with extremely high audio offset (see github issue #46). MY conclusion is that this cover art crap doesn't work, and this is just another case of completely insane ffmpeg/libav API. Disable the hack in all cases, unless a cover art video track is selected. Maybe I'll handle cover art directly in the frontend later, so that we don't have to rely on whatever libavformat does. Unfortunately, this also makes behavior with equally insane mp4 files with sparse video tracks worse, but this issue takes priority.
* demux_mf: fix crashes when '*' matches directorieswm42013-03-192-7/+10
| | | | | | | Doing 'mpv mf://*' in a file with directories would crash, because even though directories are skipped, the corresponding file entry is just left at NULL, leading to a segfault on access. So explicitly skip NULL entries.
* demux_mkv: support ALACwm42013-03-153-0/+13
| | | | | Test sample was produced with ffmpeg. Extradata handling closely follows libavformat/matroskadec.c.
* demux_mkv: Support playing Opus streams in MatroskaStephen Hutchinson2013-03-143-0/+8
| | | | | | | | | | | | FFmpeg recently changed how it writes Opus-in-Matroska to match the A_OPUS/EXPERIMENTAL name that mkvmerge uses, with the caveat that things will change and compatibility with old files can get worked out when the spec is finalized. This adds both A_OPUS and A_OPUS/EXPERIMENTAL so that *hopefully* it can play both the newer files that use A_OPUS/EXPERIMENTAL, and older ones muxed by FFmpeg that were simply A_OPUS, since this is also what FFmpeg seems to be doing to handle the situation.
* demux_lavf: use avg_frame_rate instead of r_frame_ratewm42013-03-131-2/+2
| | | | | | | | | | | r_frame_rate was deprecated and was finally removed from Libav and FFmpeg git. Not sure what's the correct replacement. avg_frame_rate may or may not be worse than the fallback of using the time_base as guess. The framerate is mostly unused, but needed for frame-based subtitles and for encoding. (It appears encoding guesses a timebase based on the FPS, and I'm not sure why we don't just use the source timebase.)
* Prefix CODEC_ID_ with AV_wm42013-03-133-20/+20
| | | | | | | | | The old names have been deprecated a while ago, but were needed for supporting older ffmpeg/libav versions. The deprecated identifiers have been removed from recent Libav and FFmpeg git. This change breaks compatibility with Libav 0.8.x and equivalent FFmpeg releases.
* fix clang compiler warningsStefano Pigozzi2013-03-031-1/+1
|
* core: fix SEEK_FACTORwm42013-03-014-4/+27
| | | | | | | | | | | | | | | | | | | | | | | | | Emulate percentage-seeks (SEEK_FACTOR) as normal