summaryrefslogtreecommitdiffstats
path: root/demux
Commit message (Collapse)AuthorAgeFilesLines
* 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
| | | | | | | | | | | | | | | | | | This used the libavformat current position, instead of the mp stream (which reflects current DVD/Bluray read position). This was broken, because libavformat won't update its position by calling the user's stream callbacks, negating the whole point of DEMUXER_CTRL_RESYNC. Now DVD playback with libavformat seems to work relatively well.
* | demux_lavf: set stream_ptswm42013-05-051-0/+6
| | | | | | | | | | | | | | | | demux_mpg did the same, and doing this in demux_lavf fixes DVD playback when using this demuxer. Additionally this might make bluray work better in the future (but for now, bluray playback doesn't change as it doesn't report stream PTS yet).
* | demux: report stream time info instead of demuxer info if possiblewm42013-05-051-4/+7
| | | | | | | | | | Needed for bluray and dvd. demux_mpg (used for dvd playback) did this manually for the time length.
* | core: move demuxer time reporting to demuxerwm42013-05-052-0/+21
| |
* | core: don't report byte-based playback position with dvdwm42013-05-051-1/+5
| | | | | | | | | | | | | | | | | | | | DVD playback uses a demuxer that signals to the frontend that timestamp resets are possible. This made the frontend calculate the OSD playback position based on the byte position and the total size of the stream. This actually broke DVD playback position display. Since DVD reports a a linear playback position, we don't have to rely on the demuxer reported position, so disable this functionality in case of DVD playback. This reverts the OSD behavior with DVD to the old behavior.
* | demux: simplify stream ID business, fix issue with cover artwm42013-04-293-17/+9
| | | | | | | | | | | | | | | | | | | | | | The stream ID handling as it was changed in commit 654c34f was still a little bit insane, and caused a regression with the cover art hack (the stream set in demux->video->sh was incorrect for demux_lavf). Simplify by always using stream_index for demux_stream->id, and getting rid of that tid thing. It turns out that the id for subtitles isn't special either (maybe demux_ts.c was the only thing left that required this).
* | 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
| | | | | |