| Commit message (Collapse) | Author | Age |
|---|
| ... | |
| |
|
|
|
|
|
|
|
| |
Slightly helps with timeline stuff, like EDL. There is no need to keep
network (or even just disk I/O) busy for all segments at the same time,
because 1. the data won't be needed any time soon, and 2. will probably
be discarded anyway if the stream is seeked when segment is resumed.
Partially fixes #2692.
|
| | |
|
| |
|
|
|
|
| |
Meh. Why are there even two code paths.
This adds an additional check; the big function is only moved.
|
| |
|
|
| |
Well, not that the unthreaded case is important, or even works properly.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
demux_lavf.c leaked the complete subtitle data if it was put through
iconv.
lavc_conv.c leaked AVCodecContext.subtitle_header (set by libavcodec),
which is fixed by using avcodec_free_context(). It also leaked the
subtitle that was decoded last.
|
| |
|
|
|
|
| |
Need to trigger demux_changed() manually since metadata
of tracks and streams is not changed, but demuxer-metadata
is still changed on program switch.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
UTF-16 subtitles are special in that they are usually read by
libavformat directly, even though they are not in UTF-8. This is
explicitly handled convert_charset() and skips conversion to UTF-8.
There was a bug due to not resetting the file position: if conversion
happens, the actual stream is replaced with a memory stream containing
the converted data, but if conversion is skipped, the original stream
with the wrong file position is kept.
Fix by always opening a memory stream. (We _could_ seek back, but there
is a slight possibility of additional failure due to unseekable
streams.)
Also, don't enter conversion if the subtitle is detected as UTF-8
either.
Fixes #2700.
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
This change helps avoiding conflict with talloc.h from libtalloc.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This slightly changes behavior when seeking with external audio/subtitle
tracks if transport streams and mpeg files are played, as well as
behavior when seeking with such external tracks.
get_main_demux_pts() is evil because it always blocks on the demuxer (if
there isn't already a packet queued). Thus it could lock up the player,
which is a shame because all other possible causes have been removed.
The reduced "precision" when seeking in the ts/mpeg cases (where
SEEK_FACTOR is used, resulting in byte seeks instead of timestamp seeks)
might lead to issues. We should probably drop this heuristic. (It was
introduced because there is no other way to seek in files with PTS
resets with libavformat, but its value is still questionable.)
|
| |
|
|
|
|
|
|
| |
There are a lot of incorrectly encoded subtitles with .ass extension
and non-ass subtitles (srt, ssa) with such extension, so we need to
try codepage detection even for .ass.
Signed-off-by: wm4 <wm4@nowhere>
|
| |
|
|
|
|
|
| |
EBML_ID_VOID might occur at any level, see:
https://github.com/Matroska-Org/ebml-specification/blob/master/specification.markdown
This change prevents "Corrupt file detected" errors on completely valid
files.
|
| |
|
|
|
|
|
|
| |
Slightly change how it is decided when a new packet should be read.
Switch to demux_read_packet_async(), and let the player "wait properly"
until required subtitle packets arrive, instead of blocking everything.
Move distinguishing the cases of passive and active reading into the
demuxer, where it belongs.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Just so I can remove a few lines from dec_sub.c.
This is slightly inelegant, as the whole subtitle file has to be read
into memory, converted at once in memory, and then provided to
libavformat in an awkward way by creating a memory stream instead of
using demuxer->stream. It also won't be possible to force the charset on
subtitles in binary container formats - but this wasn't exposed before,
and we just hope this won't be ever needed. (One motivation was fixing
broken files with non-UTF8 muxed.) It also won't be possible to change
the charset on the fly, but this was not exposed either.
|
| |
|
|
| |
Preparation for the next commit.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Always preroll by default if the cue (index) information indicates
overlapping subtitles.
Increase the amount of maximum data it will skip to get such subtitles
to 10 seconds. Since the index information can reliably tell whether
reading earlier is needed, the maximum should be rarely actually used,
thus we can set it high. On the other hand, the "old" prerolling
mechanism always has to skip the maximum amount of data; thus the method
using the index gets its own option to control the maximum amount of
data to skip.
(As more and more files With newer mkvtoolnix versions are muxed, and
with this new and hopefully sane default established, these options can
probably be removed in the future.)
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Since commit 6d9cb893, subtitle state doesn't survive timeline switches
(ordered chapters etc.). So there is no point in caching the state per
sh_stream anymore (which would be required to deal with multiple
segments). Move the cache to struct track.
(Whether it's worth caching the subtitle state just for the situation
when subtitle tracks get reselected is questionable. But for now, it's
nice to have the subtitles immediately show up when reselecting a
subtitle.)
|
| |
|
|
| |
It was total crap.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
| |
Signed-off-by: wm4 <wm4@nowhere>
|
| |
|
|
|
|
| |
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).
|
| |
|
|
|
| |
Broken by commit 0a0bb905. STREAM_CTRL_GET_ASPECT_RATIO returns a
display aspect ratio, not a pixel aspect ratio.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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).
|
| |
|
|
|
|
| |
If someone was "clever" enough to embed a cuesheet
referencing multiple files, mpv would create a bunch
of nonsense chapter markers.
|
| |
|
|
|
|
|
|
|
|
| |
This can happen if the file references a track, but does not specify
an INDEX 01 for it. This would cause mpv to just segfault due to
dereferencing the null pointer as a string.
A file causing this was observed in the wild by
ExactAudioCopy v0.99pb4 for a disk that contained a data track at the
end.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Slightly simpler, and removes the need to pre-read all subtitle packets.
This still does the subtitle charset conversion on the packet level
(instead converting when parsing the file), so in theory this still
could provide a way to change the charset at runtime. But maybe even
this should be removed, as FFmpeg is somewhat likely to get its own
charset detection and conversion mechanism in the future. (Would have
to keep the subtitle file in memory to allow changing the charset on
the fly, I guess.)
|
| |
|
|
|
| |
libavcodec's movtext-to-ass converter does the same and has more
features. On Libav, this commit disables mp4 subtitle display.
|
| |
|
|
|
|
|
|
|
| |
All of these are supported by FFmpeg now. It was disabled by default
too (with FFmpeg).
If compiled against Libav, mpv will lose the ability to read some
subtitle formats (but the most important ones, srt and ass, still should
work).
|
| |
|
|
|
|
| |
They're not necessarily restricted to YUV aka YCbCr.
vo_direct3d.c and demux_disc.c (DVD specific code) changes untested.
|
| |
|
|
|
|
|
| |
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).
|
| |
|
|
|
| |
.ts files (and some other raw streams) are the only files that enable
the SEEK_FACTOR code path, which was broken since commit 70df1608.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This is another regression of the recently added start time probing. If
a seek is executed after opening the file (but before reading any
packets), the first block is discarded instead of indexed. If there are
no other keyframes in the file, seeking will fail completely.
Fix it by seeking to the cluster start if there aren't any index entries
yet. This will read the skipped packet again.
Fixes #2498.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Most of this is explained in the DOCS additions.
This gives us slightly more sanity, because there is less interaction
between the various parts. The goal is getting rid of the video_offset
entirely.
The simplification extends to the user API. In particular, we don't need
to fix missing parts in the API, such as the lack for a seek command
that seeks relatively to the start time. All these things are now
transparent.
(If someone really wants to know the real timestamps/start time, new
properties would have to be added.)
|
| |
|
|
|
|
|
|
|
| |
This loaded external .ass files via libass. libavformat's .ass reader is
now good enough, so use that instead.
Apparently libavformat still doesn't support fonts embedded into text
.ass files, but support for this has been accidentally broken in mpv for
a while anyway. (And only 1 person complained.)
|
| |
|
|
|
| |
Stops mpv from trying to run a subtitle charset detector on .ass files
loaded by libavformat.
|
| |
|
|
| |
"libarchive:" is already added by the logging system
|
| |
|
|
|
|
|
|
| |
While it seemed like a pretty good idea at first, it's just a dead end
and works only in the simplest cases. While it may or may not help
slightly with audio sync mode, the display-sync mode already compensates
this in a better way. The main issue is that timestamps at this layer
are not in order, so it can look at single timestamps only.
|
| | |
|
| |
|
|
|
|
| |
av_free_packet() got finally deprecated. Use av_packet_unref() instead,
which has almost the same semantics, has existed for a while, and is
available in all FFmpeg and Libav versions we support.
|
| |
|
|
| |
The start time probing essentially broke it.
|
| |
|
|
|
| |
When using --demuxer-mkv-probe-video-duration=full and the file did not
start at timestamp 0, the reported duration was still wrong.
|
| |
|
|
|
|
|
|
| |
This makes the bitrate properties unavailable, instead of
returning 0 when:
1. No track is selected, or
2. Not enough packets have been read to have a bitrate estimate yet
|
| |
|
|
| |
Let's not waste precious lines.
|
| |
|
|
|
|
| |
If this is not done, libavformat could change the headers while
demuxing, all while the decoder thread reads these fields during
initialization.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
MKV files can very well start with timestamps other than 0. While mpv
has support for such files in general, and demux_lavf enables this
feature, demux_mkv didn't export a start time.
Implement this by simply reading the first cluster timestamp. This in
turn is done by reading 1 block. While we don't need the block for this
prupose at all, it's the easiest way to get the cluster timestamp read
correctly without code duplication. In theory this could be wrong, and
a packet could start at a much later time, but in practice this won't
happen.
This commit also adds an option to disable this feature. It's not
documented because nobody should use it. (But I happen to have a need
for this.)
|
| |
|
|
|
|
| |
This affects the subtitle preroll mode during seeking. It could matter
somewhat with insane files with ten-thousands of subtitle events, which
now seem to pop up, and will avoid packet queue overflow.
|
wm4
Oliver Freyermuth
Dmitrij D. Czarkoff
fwr
Kagami Hiiragi
Aman Gupta
Kevin Mitchell