| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
| |
Since the libavformat API is crap, we have to apply tons of heuristics
to check whether seeking will work. (No, checking it at seek time isn't
going to work either, because if a seek fails, the demuxer will be in an
undefined state. Because the libavformat API is crap.)
|
| |
|
|
|
|
|
|
|
|
|
| |
AVFormatContext.codec is deprecated now, and you're supposed to use
AVFormatContext.codecpar instead.
Handle this for all of the normal playback code.
Encoding mode isn't touched.
|
|
|
|
|
|
|
|
|
|
| |
This was changed in 2014, so I suppose users will usually have a FFmpeg
release which includes the corresponding upstream change. If not, well
too bad for those MicroDVD-obsessed users.
Also don't try to retrieve the default framerate as exported by the
demuxer, and instead hardcode it and trust it won't ever change. this
avoids that we have to deal with a larger mess in the codecpar commit.
|
|
|
|
|
|
| |
I don't trust it one bit, and it's a bother with the codecpar change.
If it turns out to be important for some file formats, it could be
added back (or FFmpeg fixed).
|
|
|
|
| |
Use the AVPacket refcounting mechanism instead.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes relative seeks. Without this, a seek back could skip so much data
that the seek would effectively jump forward. (Or insert silence for
files with video.)
There's the question whether the frontend should do this instead (by
using information from the decoders), but for now this seems more
proper.
demux_mkv.c does this already, sort of.
libavformat doesn't for seeks in .ogg (aka .opus), but might be doing it
for mkv. Seems to be a mess as well.
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
Stops mpv from trying to run a subtitle charset detector on .ass files
loaded by libavformat.
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
If this is not done, libavformat could change the headers while
demuxing, all while the decoder thread reads these fields during
initialization.
|
|
|
|
|
|
| |
This AVPacket field was a hack against the fact that the duration field
was merely an int (too small for things like subtitle durations). Newer
libavcodec drops this field and makes duration 64 bit.
|
|
|
|
|
| |
And use it everywhere, instead of retrieving the size manually. Slight
simplification.
|
|
|
|
| |
Yep, the FFmpeg API can return this.
|
|
|
|
|
|
| |
At least Matroska files have a "forced" flag (in addition to the
"default" flag). Export this flag. Treat it almost like the default
flag, but with slightly higher priority.
|
|
|
|
| |
Obvious bug added earlier today.
|
|
|
|
|
| |
Change the demuxer_add_attachment() and demuxer_add_chapter() signatures
to take char* instead of bstr, and everything which depends on it.
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
Why not. "format" sounds too misleading for the actual importance and
meaning of this field.
|
|
|
|
|
| |
"f.len - 4" is size_t, not int. Fix by using BSTR_P() (and a bstr
function to adjust the length).
|
|
|
|
|
|
|
|
|
|
|
| |
Vobsubs come as .idx/.sub pair of files. The .idx file is the one that
should be opened, but the name of the .sub file is unknown. We can now
make our own guess what the name of that file is. In particular, improve
support with URLs (as these can have the file extension in the middle of
the filename string if there are HTTP parameters).
Note that this works only with newer ffmpeg versions, because the
recently added sub_name demuxer option is used for this.
|
|
|
|
| |
stream.url can never be NULL, although it probably used to be.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Remove the old implementation for these properties. It was never very
good, often returned very innaccurate values or just 0, and was static
even if the source was variable bitrate. Replace it with the
implementation of "packet-video-bitrate". Mark the "packet-..."
properties as deprecated. (The effective difference is different
formatting, and returning the raw value in bits instead of kilobits.)
Also extend the documentation a little.
It appears at least some decoders (sipr?) need the
AVCodecContext.bit_rate field set, so this one is still passed through.
|
| |
|
|
|
|
| |
Signed-off-by: wm4 <wm4@nowhere>
|
|
|
|
|
|
|
| |
We handle picking out font attachments by mime type ourselves in a
higher level, so we really just want to use the mimetype. Also, Matroska
is currently the only code in libavformat which uses the fonts at all,
and we can drop use of the codec IDs completely.
|
|
|
|
|
| |
Don't bother with making these visible by default, because often they
are bogus and/or useless.
|
|
|
|
|
| |
There are obscure methods to add timestamps to such streams, but assume
they're unused.
|
|
|
|
|
|
|
|
|
|
|
| |
Trying to handle such video is almost worthless, but it was requested by
at least 2 users.
If there are no timestamps, enable byte seeking by setting
ts_resets_possible. Use the video FPS (wherever it comes from) and the
audio samplerate for timing. The latter was already done by making the
first packet emit DTS=0; remove this again and do it "properly" in a
higher level.
|
| |
|
|
|
|
|
|
|
| |
This reverts commit c8f49be919ffaf983bde77b63d75f96a593ec7a8.
Not needed anymore; fixed in all supported FFmpeg releases. Though I
could not test again, because all sample files are gone (oops).
|
|
|
|
|
|
| |
All of these are now in the supported FFmpeg and Libav versions.
The 3 remaining API checks are for FFmpeg-only things.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use the (relatively new) libavformat image format probing functionality,
instead of letting demux_mf guess by file extension and MIME type.
The libavformat support is weird, though. Traditionally, it uses an
absolutely terrible hack to detect images by extension, _and_ (which is
the horrible part) will randomly interpret parts of the filename as
specifiers for matching by number. So something like '%03d' will be
interpreted as placeholder for a frame number. The worst part is that
such character sequences can be perfectly valid and common in http URLs.
This is known as "image2" demuxer. The newer support, which probes by
examining the file header, is split into several format-specific
demuxers with names ending in "_pipe". So we check for such a name
suffix. (At this point we're doing fine-grained hacking around ffmpeg
weirdness, so a clean solution is impossible anyway until upstream
changes.)
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some of the hacks were not applied if the file format was forced. Commit
37a0c914 moved them to a table, which is checked with normal probing
only.
Fixes #1612 (DVD forces mpeg, which in turn has to export native stream
IDs specifically).
Do some code restructuring on the way. For example, the probescore can
simply be set to the correct initial value, instead of checking whether
it was set at all.
|
|
|
|
|
|
| |
Whatever the hell that is. FFmpeg tries to open any files with .bin file
extension with this demuxer (unless it finds a better demuxer), and then
reads the whole damn file, along with spamming dumb crap.
|
|
|
|
|
|
|
|
|
| |
Includes some logic for not starting the demuxer thread for fully read
subtitles. (Well, the cache will still waste _lots_ of resources, and
the cache always has to be created, because we don't know whether it'll
be needed _before_ opening the file.)
See #1597.
|