summaryrefslogtreecommitdiffstats
path: root/demux
Commit message (Collapse)AuthorAgeFilesLines
* demux_mkv: simplify avi compat. codec_tags.c GUID lookupwm42018-12-061-13/+3
| | | | | | | The redundancy here always annoyed me. Back then I didn't change it because it's hard to test and I just had fixed something. This doesn't matter anymore, so simplify it, without testing and with the risk that something breaks (why care).
* demux: remove some dead codewm42018-12-062-10/+0
| | | | | No idea what that shit is. Likely forgotten when timed metadata was introduced, and some of the old mechanisms were replaced.
* demux: add another stream recording featurewm42018-12-062-0/+41
| | | | | | --record-file is nice, but only sometimes. If you watch some sort of livestream which you want to record, it's actually much nicer not to record what you're currently "seeing", but anything you're receiving.
* demux_lavf: to get effective HLS bitratewm42018-12-061-1/+80
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In theory, this could be easily done with custom I/O. In practice, all the halfassed garbage in FFmpeg shits itself and fucks up like there's no tomorrow. There are several problems: 1. FFmpeg pretends you can do custom I/O, but in reality there's a lot that custom I/O can do. hls.c even contains explicit checks to disable important things if custom I/O is used! In particular, you can't use the HTTP keepalive functionality (needed for somewhat decent HLS performance), because some cranky asshole in the cursed FFmpeg dev. community blocked it. 2. The implementation of nested I/O callbacks (io_open/io_close) is bogus and halfassed (like everything in FFmpeg, really). It will call io_open on some URLs without ever calling io_close. Instead, it'll call avio_close() on the context directly. From what I can tell, avio_close() is incompable to custom I/O anyway (overwhelmed by their own garbage, the fFmpeg devs created the io_close callback for this reason, because they couldn't fix their own fucking garbage). This commit adds some shitty workaround for this (technically triggers UB, but with that garbage heap of a library we depend on it's not like it matters). 3. Even then, you can't proxy I/O contexts (see 1.), but we can just keep track of the opened nested I/O contexts. The bytes_read is documented as not public, but reading it is literally the only way to get what we want. A more reasonable approach would probably be using curl. It could transparently handle the keep-alive thing, as well as propagating cookies etc. (which doesn't work with the FFmpeg approach if you use custom I/O). Of course even better if there were an independent HLS implementation anywhere. FFmpeg's HLS support is so embarrassing pathetic and just goes to show that they belong into the past (multimedia from 2000-2010) and should either modernize or fuck off. With FFmpeg's shit-crusted structures, todic communities, and retarded assholes denying progress, probably the latter. Did I already mention that FFmpeg is a shit fucked steaming pile of garbage shit? And all just to get some basic I/O stats, that any proper HLS consumer requires in order to implement adaptive streaming correctly (i.e. browser based players, and nothing FFmshit based).
* demux, stream: readd cache-speed in some other formwm42018-12-062-1/+36
| | | | it's more like an input speed rather than a cache speed, but who cares.
* Merge commit '559a400ac36e75a8d73ba263fd7fa6736df1c2da' into ↵Anton Kindestam2018-12-059-92/+213
|\ | | | | | | | | | | wm4-commits--merge-edition This bumps libmpv version to 1.103
| * demux, stream: rip out the classic stream cachewm42018-08-314-50/+24
| | | | | | | | | | | | 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: allow cache sizes > 2GBwm42018-08-241-4/+8
| | | | | | | | | | There was no reason to limit this. Only some int fields had to be changed to size_t.
| * demux_lavf: v4l streams are not seekablewm42018-08-241-0/+2
| | | | | | | | | | | | | | FFmpeg is retarded enough not to give us any indication whether it is (unless we query fields not in the ABI/API). I bet FFmpeg developers love it when library users have to litter their code with duplicated information.
| * demux_lavf: drop obscure genpts optionwm42018-05-241-5/+0
| | | | | | | | | | This code shouldn't even exist in libavformat. If you still need it, you can enable it via --demuxer-lavf-o.
| * m_config: add a special define to access main configwm42018-05-241-1/+1
| | | | | | | | | | | | | | | | Passing NULL to mp_get_config_group() returns the main option struct. This is just a dumb hack to deal with inconsistencies caused by legacy things (as I'll claim), and will probably be changed in the future. So before littering the whole code base with hard to find NULL parameters, require using callers an easy to find separate define.
| * demux: add a way to destroy the demuxer asynchronouslywm42018-05-242-8/+93
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This will enable the player core to terminate the demuxers in a "nicer" way without having to block on network. If it just used demux_free(), it would either have to block on network, or like currently, essentially kill all I/O forcefully. The API is slightly awkward, because demuxer lifetime is bound to its allocation. On the other hand, changing that would also be awkward, and introduce weird in-between states that would have to be handled in tons of places. Currently unused, to be user later.
| * player: some further cleanup of the mp_cancel crapwm42018-05-242-2/+24
| | | | | | | | | | | | | | | | | | | | Alway give each demuxer its own mp_cancel instance. This makes management of the mp_cancel things much easier. Also, instead of having add/remove functions for mp_cancel slaves, replace them with a simpler to use set_parent function. Remove cancel_and_free_demuxer(), which had mpctx as parameter only to check an assumption. With this commit, demuxers have their own mp_cancel, so add demux_cancel_and_free() which makes use of it.
| * demux: get rid of free_demuxer[_and_stream]()wm42018-05-246-25/+29
| | | | | | | | | | | | | | 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-244-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| * command: make loadlist command async and abortablewm42018-05-241-1/+2
| | | | | | | | | | | | | | | | | | | | Don't allow it to freeze everything when loading a playlist from network (although you definitely shouldn't do that, but whatever). This also affects the really obscure --ordered-chapters-files option. The --playlist option on the other hand has no choice but to freeze the shit, because there's no concept of aborting the player during command line parsing.
| * demux: add a "cancel" fieldwm42018-05-245-5/+8
| | | | | | | | | | Instead of relying on demuxer->stream->cancel. This is better because the stream is potentially closed and replaced.
| * misc: move mp_cancel from stream.c to thread_tools.cwm42018-05-244-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | It seems a bit inappropriate to have dumped this into stream.c, even if it's roughly speaking its main user. At least it made its way somewhat unfortunately to other components not related to the stream or demuxer layer at all. I'm too greedy to give this weird helper its own file, so dump it into thread_tools.c. Probably a somewhat pointless change.
| * demux: late streams on start shouldn't restrict the seek rangewm42018-05-241-1/+9
| | | | | | | | | | | | If a stream starts later than the others at the start of the file, it shouldn't restrict the seek range to the time stamp where it begins. This is similar to the previous commit, just for the other end.
| * demux: streams that reached EOF shouldn't restrict the seek rangewm42018-05-241-6/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Normally, the seek range is the minimum overlap of the cached ranges of each stream. But if one of the streams ends earlier, this leads to the seek range getting cut off, even if you could seek there. Change it so that EOF streams cannot restrict the end of the seek range. They can only extend it. This is the opposite from not-EOF streams, so they need to be handled separately. In particular, they get exluded from normal end range calculation, but when full EOF is reached, all streams are EOF, and the maximum end time can be used to set the seek end time. (In theory we could also take the max with the demuxer signaled total file duration, but let's not for now.) Also, if a stream is completely empty, essentially skip it, instead of considering the range unseekable. (Also, we don't need to mess with seek_start in this case, because it will be NOPTS and is skipped anyway.)
| * demux: fix/improve aspects of EOF signalingwm42018-05-241-9/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When the current packet queue was completely empty, and EOF was reached, the queue->is_eof flag was not correctly set to true. Change this by reading ds->eof to check whether the stream is considered EOF. We also need to make sure update_seek_ranges() is called in this case, so change the code to simply call it when queue->is_eof changes. Also, read_packet() needs to call adjust_seek_range_on_packet() if ds->eof changes. In that case, the decoder also needs to be notified about EOF. So both of these should be called when ds->eof changes to true. (Other code outside of this function deals with the case when ds->eof is changed to false.) In addition, this code was kind of shoddy about calling wakeup_ds() correctly. It looks like there was an inverted condition, and sent a wakeup to the decoder only when ds->eof was already true, which is obviously bogus. The final EOF case tried to be somehow clever about checking in->last_eof for notifying the codec, which is sort of OK, but seems to be strictly worse than just checking whether ds->eof changed. Fix these things.
| * demux_lavf: remove ffm blacklist entrywm42018-05-241-2/+0
| | | | | | | | ffm (ffserver) was removed from ffmpeg.
* | demux_lavf: hack-fix EDL mp4 DASH hackwm42018-10-011-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | I encountered a stream that fails with "Could not demux init fragment.". It turns out this is a regression from the recent change to that code. The assumption was that demux_lavf.c would treat this as concatenated stream - which it does, but not for probing. Doing this transparently is hard without doing it properly. Doing it properly would mean creating some sort of stream_concat (reminiscent of that FFmpeg security bug). I probably don't want to go there, and I think libavformat should just support this directly, so whatever. Hack-fix this with the knowledge that the init segment will always contain the headers.
* | demux: allow cache sizes > 2GBwm42018-10-011-4/+9
| | | | | | | | | | There was no reason to limit this. Only some int fields had to be changed to size_t.
* | demux_lavf: v4l streams are not seekablewm42018-10-011-0/+2
| | | | | | | | | | | | | | FFmpeg is retarded enough not to give us any indication whether it is (unless we query fields not in the ABI/API). I bet FFmpeg developers love it when library users have to litter their code with duplicated information.
* | demux/packet: fix demux_packet_shortenTom Yan2018-09-301-2/+2
| | | | | | | | for the rawaudio demuxer to do the expected gapless playback
* | demux_edl: add title option to override title of chapterssfan52018-08-131-1/+4
| |
* | player: expose hearing/visual impaired flags on audio tracksAman Gupta2018-08-132-0/+6
| | | | | | | | Signed-off-by: Aman Gupta <aman@tmm1.net>
* | demux_mkv: add A_MLP to mkv_audio_tagsNicolas F2018-06-221-0/+1
| | | | | | | | Fixes #5923
* | demux_lavf: drop obscure genpts optionwm42018-05-311-5/+0
| | | | | | | | | | This code shouldn't even exist in libavformat. If you still need it, you can enable it via --demuxer-lavf-o.
* | demux: fix/improve aspects of EOF signalingwm42018-05-251-9/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When the current packet queue was completely empty, and EOF was reached, the queue->is_eof flag was not correctly set to true. Change this by reading ds->eof to check whether the stream is considered EOF. We also need to make sure update_seek_ranges() is called in this case, so change the code to simply call it when queue->is_eof changes. Also, read_packet() needs to call adjust_seek_range_on_packet() if ds->eof changes. In that case, the decoder also needs to be notified about EOF. So both of these should be called when ds->eof changes to true. (Other code outside of this function deals with the case when ds->eof is changed to false.) In addition, this code was kind of shoddy about calling wakeup_ds() correctly. It looks like there was an inverted condition, and sent a wakeup to the decoder only when ds->eof was already true, which is obviously bogus. The final EOF case tried to be somehow clever about checking in->last_eof for notifying the codec, which is sort of OK, but seems to be strictly worse than just checking whether ds->eof changed. Fix these things.
* | demux_lavf: remove ffm blacklist entrywm42018-05-251-2/+0
|/ | | | ffm (ffserver) was removed from ffmpeg.
* demux, player: fix playback of sparse video streams (w/ still images)Aman Gupta2018-05-243-2/+10
| | | | | | | | | | | | | | | Fixes several issues playing back mpegts with video streams marked as having "still images". For example, see this video which has frames only every 6s: https://s3.amazonaws.com/tmm1/music-choice.ts Changes include: - start playback right away, without waiting for first video frame - do not consider the sparse video stream in demuxer underrun detection - do not require multiple video frames for the VO - use audio as the master stream for demuxer metadata events - use audio stream for playback time Signed-off-by: Aman Gupta <aman@tmm1.net>
* demux_lavf: co-locate disposition checksAman Gupta2018-05-241-2/+2
| | | | Signed-off-by: Aman Gupta <aman@tmm1.net>
* demux_mkv: adjust log verbosity levelswm42018-04-292-40/+41
| | | | | | | | | With -v -v ("debug" level), which is the default for --log-file, this would log every damn Matroska EBML element and some other uninteresting things, which was very noisy. Adjust the log levels to make them less noisy. Also, change some log calls to MP_ERR for things which are actually errors.
* demux_lavf: discard "und" language tagwm42018-04-291-1/+1
| | | | | | | | | Going by ISO 639.2, "und" means "Undetermined". Whatever it's supposed to mean, in practice it's user for "unset". We prefer if the language tag remains simply unset in this case. This removes an ugliness with mp4 in partricular, because libavformat will export unset languages as such, which affects most mp4 files.
* demux: support for some kinds of timed metadatawm42018-04-185-114/+214
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This makes ICY title changes show up at approximately the correct time, even if the demuxer buffer is huge. (It'll still be wrong if the stream byte cache contains a meaningful amount of data.) It should have the same effect for mid-stream metadata changes in e.g. OGG (untested). This is still somewhat fishy, but in parts due to ICY being fishy, and FFmpeg's metadata change API being somewhat fishy. For example, what happens if you seek? With FFmpeg AVFMT_EVENT_FLAG_METADATA_UPDATED and AVSTREAM_EVENT_FLAG_METADATA_UPDATED we hope that FFmpeg will correctly restore the correct metadata when the first packet is returned. If you seke with ICY, we're out of luck, and some audio will be associated with the wrong tag until we get a new title through ICY metadata update at an essentially random point (it's mostly inherent to ICY). Then the tags will switch back and forth, and this behavior will stick with the data stored in the demuxer cache. Fortunately, this can happen only if the HTTP stream is actually seekable, which it usually is not for ICY things. Seeking doesn't even make sense with ICY, since you can't know the exact metadata location. Basically ICY metsdata sucks. Some complexity is due to a microoptimization: I didn't want additional atomic accesses for each packet if no timed metadata is used. (It probably doesn't matter at all.)
* demux: mark eia608 packets as keyframesAman Gupta2018-04-171-0/+1
| | | | | | This fixes an issue where captions stop rendering after an in-demuxer-cache seek, because the demuxer keeps waiting to find a keyframe (ds->skip_to_keyframe set to true in execute_cache_seek).
* demux, player: mark dependent tracksAman Gupta2018-04-172-0/+3
| | | | | | | ffmpeg marks audio tracks which are not meant to be played standalone as DEPENDENT. these are typically used in DVB broadcasts for audio descriptions, and are meant to be mixed into the main audio track during playback.
* demux_lavf: use new libavformat semantics for stream resyncwm42018-04-161-17/+2
| | | | | | | | | | I changed avio_flush() and introduced avformat_flush() exactly for this reason. Used with DVD/BD only (on seeks and when setting the "angle" property). Seems to work, but wasn't tested too thoroughly (I don't care about optical discs, I only want this ugly stuff gone that might even violate the API/ABI).
* demux: fix deadlock on "program" property changeswm42018-04-151-0/+6
| | | | | Tries to recursively lock a non-recursive lock, which usually ends in a deadlock. Must have been broken by some past refactor.
* demux_mkv: fix certain cases of recursive SeekHeadswm42018-04-151-4/+1
| | | | | | | | | | | | | | | Some shittily muxed files (by a certain HandBrake+libavformat combo) contain a SeekHead pointing to a SeekHead at the end of the file, which in turn points to track headers (also at the end of the file). This failed because the demuxer didn't bother to actually read the elements listed by the second SeekHead, so no track headers were read, and playback broke. Somehow commit 6fe75c38 broke this for no reason. It adds a "needed" field, which seems completely pointless and replaced the "parsed" flag in an incomplete way. In particular, the "needed" field was not set when a _recursive_ SeekHead was read, so those elements were not read. Just get rid of the field and use "parsed" instead.
* demux_lavf: skip demuxer hack iteration if hacks are disabledsergey.dobrodey2018-04-121-3/+1
|
* demux_mkv: add V_AV1 identifier for AV1Jan Ekström2018-04-081-0/+1
| | | | | | | | | | | Quickly tested by a person who had FFmpeg linked with libaom. Seems as simple as the VP9 mappings, where there is no extradata/ initialization data off-band, and just stuff in the packets themselves. Do note that the AV1 video format itself at this point is still not frozen, so what you might produce one day might not be decodable the following day.
* demux, stream: ignore packets and errors on forced exitwm42018-03-261-2/+2
| | | | | | | | | | When this happens, network calls are forcibly aborted (more or less), but demuxers might keep going, as most of them do not check for forced exits properly. This can possibly lead to broken packets being added. Also do not attempt to read more packets in this situation. Also do not print a stream open failed message if opening was aborted anyway.
* demux: fix comment typoAman Gupta2018-03-111-1/+1
|
* demux: correctly report buffered size as 0 if there are no packetswm4