| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The d_video->pts field was a bit strange. The code overwrote it multiple
times (on decoding, on filtering, then once again...), and it wasn't
really clear what purpose this field had exactly. Replace it with the
mpctx->video_next_pts field, which is relatively unambiguous.
Move the decreasing PTS check to dec_video.c. This means it acts on
decoder output, not on filter output. (Just like in the previous commit,
assume the filter chain is sane.) Drop the jitter vs. reset semantics;
the dec_video.c determined PTS never goes backwards, and demuxer
timestamps don't "jitter".
|
| |
|
|
|
|
| |
Also get rid of the PTS check _after_ filters. This means if there's a
video filter which unsets PTS, no warning will be printed. But we assume
that all filters are well-behaved enough by now.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Refactor the PTS handling code to make it cleaner, and to separate the
bits that use PTS sorting.
Add a heuristic to fall back to DTS if the PTS us non-monotonic. This
code is based on what FFmpeg/Libav use for ffplay/avplay and also
best_effort_timestamp (which is only in FFmpeg). Basically, this 1. just
uses the DTS if PTS is unset, and 2. ignores PTS entirely if PTS is non-
monotonic, but DTS is sorted.
The code is pretty much the same as in Libav [1]. I'm not sure if all of
it is really needed, or if it does more than what the paragraph above
mentions. But maybe it's fine to cargo-cult this.
This heuristic fixes playback of mpeg4 in ogm, which returns packets
with PTS==DTS, even though the PTS timestamps should follow codec
reordering. This is probably a libavformat demuxer bug, but good luck
trying to fix it.
The way vd_lavc.c returns the frame PTS and DTS to dec_video.c is a bit
inelegant, but maybe better than trying to mess the PTS back into the
decoder callback again.
[1] https://git.libav.org/?p=libav.git;a=blob;f=cmdutils.c;h=3f1c667075724c5cde69d840ed5ed7d992898334;hb=fa515c2088e1d082d45741bbd5c05e13b0500804#l1431
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
These used the suffix _resync_stream, which is a bit misleading. Nothing
gets "resynchronized", they really just reset state.
(Some audio decoders actually used to "resync" by reading packets for
resuming playback, but that's not the case anymore.)
Also move the function in dec_video.c to the top of the file.
|
| | |
|
| | |
|
| |
|
|
|
| |
This used a really weird idiom: a loop that iterates only once, so you
can use break; to jump out of the block.
|
| |
|
|
|
|
|
|
|
|
| |
These packets have to be explicitly dropped, because usually libavcodec
uses 0-sized packets to flush delayed frames, meaning just passing
through these packets would have bad consequences.
Normally, libavformat doesn't output 0-sized packets anyway. But I don't
want to take any chances, so don't delete it, and just move it out of
the way to demux.c.
|
| | |
|
| |
|
|
|
|
|
| |
Solve this by passing through the language to the player, which then
uses the generic subtitle selection code to make a choice.
Fixes #367.
|
| |
|
|
|
|
|
|
|
| |
If the value for --cache-on-pause is larger than --cache-min, and the
cache runs below --cache-on-pause, but above --cache-min, the logic
would demand to pause the player and then unpause immediately again.
This doesn't make much sense, and alternating the pause state in each
playloop iteration has negative consequences. Add an explicit check to
avoid this situation.
|
| |
|
|
|
|
|
|
|
|
| |
This means the code that tries to figure out the timestamp from
demuxer and decoder output is now all in dec_video.c. We set the
final timestamp on the returned image (mp_image.pts), as well as
the d_video->pts field.
The way the player uses d_video->pts field is still a bit messy. Maybe
this could be cleaned up later.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It appears PTS sorting was useful only for avi files (and VfW-muxed
mkv). Maybe it was historically also important for decoders with broken
or non-existent PTS reordering (win32 codecs?). But now that we handle
demuxers which outputs DTS only correctly, it just seems dead weight.
Disable it by default. The --pts-association-mode option is now forced
to always use the decoder's PTS value. You can still enable the old
default (auto) or force sorting. But we will probably remove this option
entirely at some point.
Make demux_mkv export timestamps at DTS when it's in VfW mode. This is
needed to get correct timestamps with the new default mode. demux_lavf
already does that.
|
| |
|
|
|
|
|
|
|
| |
Having the DTS directly can be useful for restoring PTS values.
The avi file format doesn't actually store PTS values, just DTS. An
older hack explicitly exported the DTS as PTS (ignoring the [I assume]
genpts generated non-sense PTS), which is not necessary anymore due to
this change.
|
| |
|
|
|
|
| |
Now the --no-correct-pts mode is like the normal mode, just with
different timestamp calculations. The semantics should be about the
same as before this commit.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Before this commit, this mode estimated the frame time by subtracting
successive packet PTS values. This is complete non-sense for video
codecs which use reordering. The code compensated frame times for these
non-sense using the FPS value, but confused the rest of the player with
non-sense jumping around timestamps. So, all in all this mode is not
very useful.
Repurpose this mode for fixed frame rate playback. This gives almost the
same behavior as the old mode with forced framerate (--fps option). The
result is simpler and often more robust.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of passing the PTS as separate field, pass it as part of the
usual data structures. Basically, this removes strange artifacts from
the API. (It's not finished, though: the final decoded PTS goes through
strange paths, and filter_video() finally overwrites the decoded
mp_image's pts field with it.)
We also stop using libavcodec's reordered_opaque fields, and use
AVPacket.pts and AVFrame.pkt_pts. This is slightly unorthodox, because
these pts fields are not "really" opaque anymore, yet we treat them as
such. But the end result should be the same, and reordered_opaque is
marked as partially deprecated (it's not clear whether it's really
deprecated).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This normally shouldn't happen. It does happen with VfW-muxed mkv files,
and would normally happen with avi files (except that we force the
correct association mode using an explicit hack for avi).
This is usually prepended by warnings like:
Decreasing video pts: 0.125000 < 0.167000
and after the switch, there should be no warnings anymore.
Background: avi likes to use DTS for timestamps instead of PTS.
Basically, there are no proper timestamps in the file, only frame
numbers. And Matroska is insane and stores the made-up DTS instead
of a proper PTS. This will be handled properly later.
|
| |
|
|
|
|
|
|
|
|
|
| |
Apparently Cocoa precise scrolling generates a lot of spurious events with
a delta that is equal to 0.0. Make sure that they are discarded and not added
to the input queue.
Even though this only known to happen with Cocoa, I implemented this at core
level since it makes sense in general.
Fixes: #310
|
| |
|
|
|
| |
Demuxer might access stream even when closing. For now, this is not
a real problem (because it didn't actually happen), but it's cleaner.
|
| |
|
|
|
|
| |
This is not needed anymore, because we decided that the PAR of the
decoded video matters, and not the PAR of the filtered video that
arrives at the VO.
|
| |
|
|
|
| |
This was way too misleading. osd.c merely calls the subtitle renderers,
instead of actually dealing with subtitles.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In theory, we can't really do this, because we don't know when a spdif
frame ends. Spdif transports compressed audio through audio setups that
were originally designed for PCM only (which includes the audio filter
chain, the AO API, most audio output APIs, etc.), and to reach this
goal, spdif pretends to be PCM. Compressed data frames are padded with
zeros, until a certain data rate is reached, which corresponds to a
pseudo-PCM format with 2 bytes per sample and 2 channels at 48000 Hz.
Of course an actual spdif frame is significantly larger than a frame
of the PCM format it pretends to be, so cutting audio data on frame
boundaries (as according to the pseudo-PCM format) merely yields an
incomplete and broken frame, not audio that plays for the desired
duration.
However, sending an incomplete frame might still be much better than the
current behavior, which simply ignores --end/--length (but still lets
the video end at the exact end time).
Should this result in trouble with real spdif receivers, this commit
probably has to be reverted.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the --fps option was given (MPOpts->force_fps), the demuxer FPS value
was overwritten with the forced value. This was fine, since the demuxer
value wasn't needed anymore. But with the recent changes not to write to
the demuxer stream headers, we don't want to do this anymore. So
maintain the (forced/updated) FPS value in dec_video->fps.
The removed code in loadfile.c is probably redundant, and an artifact
from past refactorings.
Note that sub.c will now always use the demuxer FPS value, instead of
the user override value. I think this is fine, because it used the
demuxer's video size values too. (And it's rare that these values are
used at all.)
|
| |
|
|
|
|
|
|
|
|
|
| |
The only reason why these structs were dynamically allocated was to
avoid recursive includes in stheader.h, which is (or was) a very central
file included by almost all other files. (If a struct is referenced via
a pointer type only, it can be forward referenced, and the definition of
the struct is not needed.) Now that they're out of stheader.h, this
difference doesn't matter anymore, and the code can be simplified.
Also sneak in some sanity checks.
|
| |
|
|
| |
It's redundant.
|
| |
|
|
|
|
|
|
|
| |
This used to be needed to access the generic stream header from the
specific headers, which in turn was needed because the decoders had
access only to the specific headers. This is not the case anymore, so
this can finally be removed again.
Also move the "format" field from the specific headers to sh_stream.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Use sh_stream over sh_sub. Use dec_sub (and mpctx->d_sub) instead of the
stream header. This aligns the subtitle code with the recent audio and
video refactoring.
sh_sub still has the decoder context, though. This is because we want to
avoid reinit when switching segments with ordered chapters. (Reinit is
fast, except for creating the ASS_Renderer, which in turn triggers
fontconfig.) Not sure how much this matters, though, because the initial
segment switch will lazily initialize the decoder anyway.
|
| |
|
|
|
|
|
|
|
|
| |
This is similar to the sh_audio commit.
This is mostly cosmetic in nature, except that it also adds automatical
freeing of the decoder driver's state struct (which was in
sh_video->context, now in dec_video->priv).
Also remove all the stheader.h fields that are not needed anymore.
|
| |
|
|
|
| |
Commit 0cb9227a added this to the option list help output, but it looks
strange with sub-options.
|
| |
|
|
| |
Make it work via --vf=pp:help instead.
|
| |
|
|
|
|
|
|
|
|
| |
This drops the --pp option, which was probably broken for a while. The
option automatically inserted the "pp" filter. The value passed to it
was ignored (which is probably broken, it always selected maximal
quality).
Inserting this filter can be done simply with --vf=pp, so this is not
needed anymore.
|
| |
|
|
| |
Useful in rather special situations. See following commits.
|
| |
|
|
|
|
|
|
| |
This means most code accessing this struct must now include hwdec.h
instead of dec_video.h. I just put it into dec_video.h at first because
I thought a separate file would be a waste, but it's more proper to do
it this way, as there are too many files which include dec_video.h only
to get the mp_hwdec_info definition.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was printed before something was decoded, and thus was not really
correct. Also, this code is hilariously broken:
/* Assume FOURCC if all bytes >= 0x20 (' ') */
if (sh_audio->format >= 0x20202020)
mp_msg(MSGT_IDENTIFY, MSGL_INFO,
"ID_AUDIO_FORMAT=%.4s\n", (char *)&sh_audio->format);
Time to kill it.
This information can be accessed through properties instead.
|
| |
|
|
|
|
|
|
| |
sh_audio is supposed to contain file headers, not whatever was decoded.
Fix this, and write the decoded format to separate fields in the decoder
context, the dec_audio.decoded field. (Note that this field is really
only needed to communicate the audio format from decoder driver to the
generic code, so no other code accesses it.)
|
| |
|
|
|
|
|
|
|
| |
Move all state that basically changes during decoding or is needed in
order to manage decoding itself into a new struct (dec_audio).
sh_audio (defined in stheader.h) is supposed to be the audio stream
header. This should reflect the file headers for the stream. Putting the
decoder context there is strange design, to say the least.
|
| | |
|
| |
|
|
| |
This is Better(tm).
|
| |
|
|
|
|
|
|
|
|
|
| |
This was forgotten when the parser for mplayer2 EDL files was removed.
Change the header of the mpv EDL format to include a '#', so a naive
parser could skip the header as comment. (Maybe this is questionable;
on the other hand, if it can be simpler, why not.)
Also, strip the header in demux_edl.c before passing on the data, so the
header check doesn't need to be duplicated in tl_mpv_edl.c.
|
| | |
|
| |
|
|
|
| |
It was a bit too complicated and inconvenient, and I doubt anyone
actively used it. The mpv EDL format should cover all use cases.
|
| | |
|
| |
|
|
|
| |
Questionable change from user perspective, but internally needed to
implement the next commit. Also useful for testing timeline stuff.
|
| |
|
|
|
|
|
|
|
|
| |
Edit Decision Lists (EDL) allow combining parts from multiple source
files into one virtual file. MPlayer had an EDL format (which sucked),
which mplayer2 tried to improve with its own format (which sucked). As
logic demands, mpv introduces its very own format (which sucks).
The new format should actually be much simpler and easier to use, and
its implementation is simpler and smaller too.
|
| |
|
|
|
|
|
| |
The intention of the existing code was trying to match demuxer-reported
stream IDs, instead of using possibly arbitrary ordering of the frontend
track list. But EDL files can consist of quite different files, for
which trying to match the stream IDs doesn't always make sense.
|
| |
|
|
|
|
| |
This didn't have any consequences, other than suddenly reinitializing
video when it works again (such as with EDL timeline mixing video and
audio-only files).
|
| |
|
|
| |
This always bothered me.
|
| |
|
|
|
| |
This could lead to (barely) audible artifacts with --af=scaletempo and
modified playback speed.
|
| |
|
|
|
|
|
|
| |
The AF control commands used an elaborate and unnecessary organization
for the command constants. Get rid of all that and convert the
definitions to a simple enum. Also remove the control commands that
were not really needed, because they were not used outside of the
filters that implemented them.
|
| |
|
|
|
|
|
|
|
|
| |
Some decoders used to read packets and decode data when calling
resync_audio_stream(). This required a special case in mp_seek() for
audio. (A comment mentions liba52, which is long gone; but until
recently ad_mpg123.c actually exposed this behavior.)
No decoder does this anymore, and resync_audio_stream() works similar
as resync_video_stream(). Remove the special case.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When the decoder detects a format change, it overwrites the values
stored in sh_audio (this affects the members sample_format, samplerate,
channels). In the case when the old audio data still needs to be
played/filtered, the audio format as identified by sh_audio and the
format used for the decoder buffer can mismatch. In particular, they
will mismatch in the very unlikely but possible case the audio chain is
reinitialized while old data is draining during a format change.
Or in other words, sh_audio might contain the new format, while the
audio chain is still configured to use the old format.
Currently, the audio code (player/audio.c and init_audio_filters) access
sh_audio to get the current format. This is in theory incorrect for the
reasons mentioned above. Use the decoder buffer's format instead, which
should be correct at any point.
|
| |
|
|
|
| |
Don't call ao_play() if there's nothing left. Of course this still asks
the AO to play internally buffered audio by setting drain=true.
|
| |
|
|
| |
Also break that line a bit.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
demuxer->filepos contains the byte offset of the last read packet. This
is so that the player can estimate the current playback position, if no
proper timestamps are available. Simplify it to use demux_packet->pos in
the generic demuxer code, instead of bothering every demuxer
implementation about it.
(Note that this is still a bit incorrect: it relfects the position of
the last packet read by the demuxer, not that returned to the user. But
that was already broken, and is not that trivial to fix.)
|
| | |
|
| |
|
|
| |
This was needed for ao_jack.c., but not anymore.
|
| |
|
|
|
|
