summaryrefslogtreecommitdiffstats
path: root/demux/demux_disc.c
Commit message (Collapse)AuthorAgeFilesLines
* stream, demux: redo origin policy thingwm42019-12-201-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | mpv has a very weak and very annoying policy that determines whether a playlist should be used or not. For example, if you play a remote playlist, you usually don't want it to be able to read local filesystem entries. (Although for a media player the impact is small I guess.) It's weak and annoying as in that it does not prevent certain cases which could be interpreted as bad in some cases, such as allowing playlists on the local filesystem to reference remote URLs. It probably barely makes sense, but we just want to exclude some other "definitely not a good idea" things, all while playlists generally just work, so whatever. The policy is: - from the command line anything is played - local playlists can reference anything except "unsafe" streams ("unsafe" means special stream inputs like libavfilter graphs) - remote playlists can reference only remote URLs - things like "memory://" and archives are "transparent" to this This commit does... something. It replaces the weird stream flags with a slightly clearer "origin" value, which is now consequently passed down and used everywhere. It fixes some deviations from the described policy. I wanted to force archives to reference only content within them, but this would probably have been more complicated (or required different abstractions), and I'm too lazy to figure it out, so archives are now "transparent" (playlists within archives behave the same outside). There may be a lot of bugs in this. This is unfortunately a very noisy commit because: - every stream open call now needs to pass the origin - so does every demuxer open call (=> params param. gets mandatory) - most stream were changed to provide the "origin" value - the origin value needed to be passed along in a lot of places - I was too lazy to split the commit Fixes: #7274
* stream: turn into a ring buffer, make size configurablewm42019-11-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In some corner cases (see #6802), it can be beneficial to use a larger stream buffer size. Use this as argument to rewrite everything for no reason. Turn stream.c itself into a ring buffer, with configurable size. The latter would have been easily achievable with minimal changes, and the ring buffer is the hard part. There is no reason to have a ring buffer at all, except possibly if ffmpeg don't fix their awful mp4 demuxer, and some subtle issues with demux_mkv.c wanting to seek back by small offsets (the latter was handled with small stream_peek() calls, which are unneeded now). In addition, this turns small forward seeks into reads (where data is simply skipped). Before this commit, only stream_skip() did this (which also mean that stream_skip() simply calls stream_seek() now). Replace all stream_peek() calls with something else (usually stream_read_peek()). The function was a problem, because it returned a pointer to the internal buffer, which is now a ring buffer with wrapping. The new function just copies the data into a buffer, and in some cases requires callers to dynamically allocate memory. (The most common case, demux_lavf.c, required a separate buffer allocation anyway due to FFmpeg "idiosyncrasies".) This is the bulk of the demuxer_* changes. I'm not happy with this. There still isn't a good reason why there should be a ring buffer, that is complex, and most of the time just wastes half of the available memory. Maybe another rewrite soon. It also contains bugs; you're an alpha tester now.
* demux: restore some of the DVD/BD/CDDA interaction layerswm42019-10-031-0/+359
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This partially reverts commit a9d83eac40c94f44d19fab7b6955331f10efe301 ("Remove optical disc fancification layers"). Mostly due to the timestamp crap, this was never really going to work. The playback layer is sensitive to timestamps, and derives the playback time directly from the low level packet timestamps. DVD/BD works differently, and libdvdnav/libbluray do not make it easy at all to compensate for this. Which is why it never worked well, but not doing it at all is even more awful. demux_disc.c tried this and rewrote packet timestamps from low level TS to playback time. So restore demux_disc.c, which should bring behavior back to the old often non-working but slightly better state. I did not revert anything that affects components above the demuxer layer. For example, the properties for switching DVD angles or listing disc titles are still gone. (Disc titles could be reimplemented as editions. But not by me.) This commit modifies the reverted code a bit; this can't be avoided, because the internal API changed quite a bit. The old seek resync in demux_lavf.c (which was a hack) is replaced with a hack. SEEK_FORCE and demux_params.external_stream are new additions. Some of this could/should be further cleaned up. If you don't want "proper" DVD/BD support to disappear, you should probably volunteer. Now why am I wasting my time for this? Just because some idiot users are too lazy to rip their ever-wearing out shitty physical discs? Then why should I not be lazy and drop support completely? They won't even be thankful for me maintaining this horrible garbage for no compensation.
* Remove optical disc fancification layerswm42019-09-131-379/+0
| | | | | | | | | | | | | | | | | This removes anything related to DVD/BD/CD that negatively affected the core code. It includes trying to rewrite timestamps (since DVDs and Blurays do not set packet stream timestamps to playback time, and can even have resets mid-stream), export of chapters, stream languages, export of title/track lists, and all that. Only basic seeking is supported. It is very much possible that seeking completely fails on some discs (on some parts of the timeline), because timestamp rewriting was removed. Note that I don't give a shit about optical media. If you want to watch them, rip them. Keeping some bare support for DVD/BD is the most I'm going to do to appease the type of lazy, obnoxious users who will care. There are other players which are better at optical discs.
* demux, stream: rip out the classic stream cachewm42018-08-311-5/+2
| | | | | | The demuxer cache is the only cache now. Might need another change to combat seeking failures in mp4 etc. The only bad thing is the loss of cache-speed, which was sort of nice to have.
* demux: get rid of free_demuxer[_and_stream]()wm42018-05-241-2/+5
| | | | | | | Them being separate is just dumb. Replace them with a single demux_free() function, and free its stream by default. Not freeing the stream is only needed in 1 special case (demux_disc.c), use a special flag to not free the stream in this case.
* command: whitelist some blocking accesses for certain demuxers/streamswm42018-05-241-0/+2
| | | | | | | | | | | | | | | | | | | | | The properties/commands touched in this commit are all for obscure special inputs (BD/DVD/DVB/TV), and they all block on the demuxer/stream layer. For network streams, this blocking is very unwelcome. They will affect playback and probably introduce pauses and frame drops. The player can even freeze fully, and the logic that tries to make playback abortable even if frozen complicates the player. Since the mentioned accesses are not needed for network streams, but they will block on network streams even though they're going to fail, add a flag that coarsely enables/disables these accesses. Essentially it establishes a whitelist of demuxers/streams which support them. In theory you could to access BD/DVD images over network (or add such support, I don't think it's a thing in mpv). In these cases these controls still can block and could even "freeze" the player completely. Writing to the "program" and "cache-size" properties still can block even for network streams. Just don't use them if you don't want freezes.
* demux_disc: fix bluray subtitle language retrievalwm42017-07-161-4/+4
| | | | | | | | | It seems like adjusting the raw stream ID should be done only for DVD. Otherwise, getting the subtitle language for Bluray breaks. Untested. Regression since fb9a32977d6. Fixes #4611 (probably).
* demux: get rid of DEMUXER_CTRL_GET_TIME_LENGTHwm42017-06-201-7/+4
| | | | | | | | | | | | Similar purpose as f34e1a0deea45e. Somehow this is much more natural too, and needs less code. This breaks runtime updates to duration. This could easily be fixed, but no important demuxer does this anyway. Only demux_raw and demux_disc might (the latter for BD/DVD). For the latter it might actually have some importance when changing titles at runtime (I guess?), but guess what, I don't care.
* demux: replace custom return codes with CONTROL_ oneswm42017-06-191-2/+2
| | | | | | | | This is more uniform, and potentially gets rid of some past copyrights. It might be that this subtly changes caching behavior (it seems before this, it synced to the demuxer if the length was unknown, which is not what we want.)
* stream: get rid of streamtype enumwm42017-02-021-6/+22
| | | | | | | | | Because it's kind of dumb. (But not sure if it was worth the trouble.) For stream_file.c, we add new explicit fields. The rest are rather special uses and can be killed by comparing the stream impl. name. The changes to DVD/BD/CD/TV are entirely untested.
* player: improve instant track switchingwm42016-08-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | When switching tracks, we normally have the problem that data gets lost due to readahead buffering. (Which in turn is because we're stubborn and instruct the demuxers to discard data on unselected streams.) The demuxer layer has a hack that re-reads discarded buffered data if a stream is enabled mid-stream, so track switching will seem instant. A somewhat similar problem is when all tracks of an external files were disabled - when enabling the first track, we have to seek to the target position. Handle these with the same mechanism. Pass the "current time" to the demuxer's stream switch function, and let the demuxer figure out what to do. The demuxer will issue a refresh seek (if possible) to update the new stream, or will issue a "normal" seek if there was no active stream yet. One case that changes is when a video/audio stream is enabled on an external file with only a subtitle stream active, and the demuxer does not support rrefresh seeks. This is a fuzzy case, because subtitles are sparse, and the demuxer might have skipped large amounts of data. We used to seek (and send the subtitle decoder some subtitle packets twice). This case is sort of obscure and insane, and the fix would be questionable, so we simply don't care. Should mostly fix #3392.
* demux: remove relative seekingwm42016-02-281-19/+5
| | | | | | | | | | | | | | | | | | | Ever since a change in mplayer2 or so, relative seeks were translated to absolute seeks before sending them to the demuxer in most cases. The only exception in current mpv is DVD seeking. Remove the SEEK_ABSOLUTE flag; it's not the implied default. SEEK_FACTOR is kept, because it's sometimes slightly useful for seeking in things like transport streams. (And maybe mkv files without duration set?) DVD seeking is terrible because DVD and libdvdnav are terrible, but mostly because libdvdnav is terrible. libdvdnav does not expose seeking with seek tables. (Although I know xbmc/kodi use an undocumented API that is not declared in the headers by dladdr()ing it - I think the function is dvdnav_jump_to_sector_by_time().) With the current mpv policy if not giving a shit about DVD, just revert our half-working seek hacks and always use dvdnav_time_search(). Relative seeking might get stuck sometimes; in this case --hr-seek=always is recommended.
* Relicense some non-MPlayer source files to LGPL 2.1 or laterwm42016-01-191-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This covers source files which were added in mplayer2 and mpv times only, and where all code is covered by LGPL relicensing agreements. There are probably more files to which this applies, but I'm being conservative here. A file named ao_sdl.c exists in MPlayer too, but the mpv one is a complete rewrite, and was added some time after the original ao_sdl.c was removed. The same applies to vo_sdl.c, for which the SDL2 API is radically different in addition (MPlayer supports SDL 1.2 only). common.c contains only code written by me. But common.h is a strange case: although it originally was named mp_common.h and exists in MPlayer too, by now it contains only definitions written by uau and me. The exceptions are the CONTROL_ defines - thus not changing the license of common.h yet. codec_tags.c contained once large tables generated from MPlayer's codecs.conf, but all of these tables were removed. From demux_playlist.c I'm removing a code fragment from someone who was not asked; this probably could be done later (see commit 15dccc37). misc.c is a bit complicated to reason about (it was split off mplayer.c and thus contains random functions out of this file), but actually all functions have been added post-MPlayer. Except get_relative_time(), which was written by uau, but looks similar to 3 different versions of something similar in each of the Unix/win32/OSX timer source files. I'm not sure what that means in regards to copyright, so I've just moved it into another still-GPL source file for now. screenshot.c once had some minor parts of MPlayer's vf_screenshot.c, but they're all gone.
* demux: merge sh_video/sh_audio/sh_subwm42016-01-121-14/+10
| | | | | | | | | | This is mainly a refactor. I'm hoping it will make some things easier in the future due to cleanly separating codec metadata and stream metadata. Also, declare that the "codec" field can not be NULL anymore. demux.c will set it to "" if it's NULL when added. This gets rid of a corner case everything had to handle, but which rarely happened.
* demux: remove weird tripple-buffering for the sh_stream listwm42015-12-231-10/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The demuxer infrastructure was originally single-threaded. To make it suitable for multithreading (specifically, demuxing and decoding on separate threads), some sort of tripple-buffering was introduced. There are separate "struct demuxer" allocations. The demuxer thread sets the state on d_thread. If anything changes, the state is copied to d_buffer (the copy is protected by a lock), and the decoder thread is notified. Then the decoder thread copies the state from d_buffer to d_user (again while holding a lock). This avoids the need for locking in the demuxer/decoder code itself (only demux.c needs an internal, "invisible" lock.) Remove the streams/num_streams fields from this tripple-buffering schema. Move them to the internal struct, and protect them with the internal lock. Use accessors for read access outside of demux.c. Other than replacing all field accesses with accessors, this separates allocating and adding sh_streams. This is needed to avoid race conditions. Before this change, this was awkwardly handled by first initializing the sh_stream, and then sending a stream change event. Now the stream is allocated, then initialized, and then declared as immutable and added (at which point it becomes visible to the decoder thread immediately). This change is useful for PR #2626. And eventually, we should probably get entirely of the tripple buffering, and this makes a nice first step.
* demux_disc: fix aspect ratio retrieval (again)wm42015-12-201-3/+3
| | | | | | Commit 127da161 was not properly tested either - it did nothing, and just made it use the video bitstream aspect ratio determined by libavformat (which isn't always the correct one).
* demux_disc: fix aspect ratiowm42015-12-201-2/+6
| | | | | Broken by commit 0a0bb905. STREAM_CTRL_GET_ASPECT_RATIO returns a display aspect ratio, not a pixel aspect ratio.
* video: switch from using display aspect to sample aspectwm42015-12-191-1/+4
| | | | | | | | | | | | | | | | MPlayer traditionally always used the display aspect ratio, e.g. 16:9, while FFmpeg uses the sample (aka pixel) aspect ratio. Both have a bunch of advantages and disadvantages. Actually, it seems using sample aspect ratio is generally nicer. The main reason for the change is making mpv closer to how FFmpeg works in order to make life easier. It's also nice that everything uses integer fractions instead of floats now (except --video-aspect option/property). Note that there is at least 1 user-visible change: vf_dsize now does not set the display size, only the display aspect ratio. This is because the image_params d_w/d_h fields did not just set the display aspect, but also the size (except in encoding mode).
* csputils: rename "yuv2rgb" functionswm42015-12-091-1/+1
| | | | | | They're not necessarily restricted to YUV aka YCbCr. vo_direct3d.c and demux_disc.c (DVD specific code) changes untested.
* csputils: remove obscure int_bits matrix scalingwm42015-12-091-4/+3
| | | | | | | This has no reason to be there. Put the functionality into another function instead. While we're at it, also adjust for possible accuracy issues with high bit depth YUV (matters for rendering subtitles into screenshots only).
* player: remove higher-level remains of DVD/BD menu supportwm42015-08-031-3/+0
| | | | | | | | | | | | | | | Nobody wanted to restore this, so it gets the boot. If anyone still wants to volunteer to restore menu support, this would be welcome. (I might even try it myself if I feel masochistic and like wasting a lot of time for nothing.) But if it does get restored, it should be done differently. There were many stupid things about how it was done. For example, it somehow tried to pull mp_nav_events through all the layers (including needing to "buffer" them in the demuxer), which was needlessly complicated. It could be done simpler. This code was already inactive, so this commit actually changes nothing. Also keep in mind that normal DVD/BD playback still works.
* demux: get rid of some bstr thingswm42015-06-241-2/+2
| | | | | Change the demuxer_add_attachment() and demuxer_add_chapter() signatures to take char* instead of bstr, and everything which depends on it.
* demux: merge extradata fieldswm42015-06-211-2/+2
| | | | | | | MPlayer traditionally had completely separate sh_ structs for audio/video/subs, without a good way to share fields. This meant that fields shared across all these headers had to be duplicated. This commit deduplicates essentially the last remaining duplicated fields.
* demux: rename sh_stream.format to sh_stream.codec_tagwm42015-06-211-1/+1
| | | | | Why not. "format" sounds too misleading for the actual importance and meaning of this field.
* demux: change demux_open() signaturewm42015-02-201-3/+4
| | | | Fold the relatively obscure force_format parameter into demuxer_params.
* demux_disc: fix CDDA seekabilitywm42015-02-031-6/+13
| | | | | | | | The only reason why cdda:// goes through this wrapper-demuxer is so that we add chapters to it. Most things related to seeking apply only to DVD/BD, and in fact broke CDDA sekkability. Fixes #1555.
* demux_disc: pass seek flags to stream layerwm42015-01-191-1/+5
| | | | | | | | | | | | | | | | Pass through the seek flags to the stream layer. The STREAM_CTRL semantics become a bit awkward, but that's still the least awkward part about optical disc media. Make demux_disc.c request relative seeks. Now the player will use relative seeks if the user sends relative seek commands, and the demuxer announces it wants these by setting rel_seeks to true. This change probably changes seek behavior for dvd, dvdnav, bluray, cdda, and possibly makes seeking useless if the demuxer-cache is set to a high value. Will be used in the next commit. (Split to make reverting the next commit easier.)
* csputils: replace float[3][4] with a structwm42015-01-061-3/+3
| | | | | Not being able to use the 3x3 part of the matrix was annoying, so split it into a float[3][3] matrix and a separate float[3] constant vector.
* dvd, bd: don't unnecessarily block on demuxer/stream all the timewm42014-12-041-0/+3
| | | | | | | | | | | | | | | | | | This was completely breaking any low-level caching. Change it so that at least demuxer caching will work. Do this by using the metadata cache mechanism to funnel through the menu commands. For some incomprehensible reason, I had to reorder the events (which affects their delivery priority), or they would be ignored. Probably some crap about the event state being cleared before it could be delivered. I don't give a shit. All this code sucks. It would probably be better to let discnav.c access the menu event "queue" directly, and to synchronize access with a mutex, instead of going through all the caching layers, making things complicated and slow.
* player: always use demux_chapterwm42014-11-021-1/+1
| | | | | | | | | Instead of defining a separate data structure in the core. For some odd reason, demux_chapter exported the chapter time in nano-seconds. Change that to the usual timestamps (rename the field to make any code relying on this to fail compilation), and also remove the unused chapter end time.
* demux_disc: bluray: fix stream language (2)wm42014-09-301-0/+1
| | | | | | | | | Commit 50e131b43ed happened to make it work for DVD (because the higher bits of the ID are masked in the DVD case), but failed for Bluray. This probably fixes it, although I don't have a sample to multiple streams to confirm it really does it right. CC: @mpv-player/stable
* demux_disc: export BD/DVD audio languagewm42014-09-291-0/+1
| | | | This was "forgotten".
* demux_disc: bluray: potentially fix some aspects of seekingwm42014-09-291-0/+6
| | | | | | | | | | | | | When flushing the AVIOContext, make sure it can't seek back to discarded data. buf_ptr is just the current read position, while buf_end - buffer is the actual buffer size. Since mpegts.c is littered with seek calls, it might be that the ability to seek could read Mark the stream (which the demuxer uses) as not seekable. The cache can enable seeking again (this behavior is sometimes useful for other things). I think this should have had no bad influence in theory, since seeking BD/DVD first does the "real" seek, then flushes libavformat and reads new packets.
* demux_disc: handle new_sh_stream() fail correctlyshdown2014-08-301-2/+4
| | | | | Break the cycle on fail. Old code was checking if sh is NULL after accessing it's fields.
* demux: fix timestamp type for seek callswm42014-07-211-1/+1
| | | | | mpv/mplayer2/MPlayer use double for timestamps, but the demuxer API used float.
* dvd, bd: fix A/V syncwm42014-07-181-30/+29
| | | | | Slightly less robust, but simpler, and usually guarantees that audio and video are properly in sync.
* demux: drop some unused definitionswm42014-07-171-1/+0
|
* demux: add a demuxer threadwm42014-07-161-1/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds a thread to the demuxer which reads packets asynchronously. It will do so until a configurable minimum packet queue size is reached. (See options.rst additions.) For now, the thread is disabled by default. There are some corner cases that have to be fixed, such as fixing cache behavior with webradios. Note that most interaction with the demuxer is still blocking, so if e.g. network dies, the player will still freeze. But this change will make it possible to remove most causes for freezing. Most of the new code in demux.c actually consists of weird caches to compensate for thread-safety issues (with the previously single-threaded design), or to avoid blocking by having to wait on the demuxer thread. Most of the changes in the player are due to the fact that we must not access the source stream directly. the demuxer thread already accesses it, and the stream stuff is not thread-safe. For timeline stuff (like ordered chapters), we enable the thread for the current segment only. We also clear its packet queue on seek, so that the remaining (unconsumed) readahead buffer doesn't waste memory. Keep in mind that insane subtitles (such as ASS typesetting muxed into mkv files) will practically disable the readahead, because the total queue size is considered when checking whether the minimum queue size was reached.
* Revert "Remove DVD and Bluray support"wm42014-07-151-0/+347
| | | | | | This reverts commit 4b93210e0c244a65ef10a566abed2ad25ecaf9a1. *shrug*
* Remove DVD and Bluray supportwm42014-07-141-347/+0
| | | | It never worked well. Just remux your DVD and BD images to mkv.
* dvdnav: fix time display when starting in the middle of the DVDwm42014-07-131-0/+5
| | | | | | | | | | | | | | | | | | | libdvdnav can actually jump into the middle of the DVD (e.g. scene selection menus do that). Then time display is incorrect: we start from 0, even though playback time is somewhere else. This really matters when seeking. If the display time mismatches, a small relative seek will apparently jump to the beginning of the movie. Fix this by initializing the PTS stuff on opening. We have to do this after some small amount of data has bee