| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
Always use the already existing extradata[_len] variable, instead of the
awkward switch between manually changed extradata and falling back to
passing through extradata at the end.
|
|
|
|
|
| |
Why not. "format" sounds too misleading for the actual importance and
meaning of this field.
|
|
|
|
|
|
|
|
| |
That's how mime types are.
(This makes redirection with a specific HLS URL work, because some idiot
thought it'd be a great idea to spell the mime type as
"application/x-mpegURL".)
|
| |
|
|
|
|
|
| |
These decoders do not reference it. I suspect this was originally done
for the sake for MPlayer's vfw/dshow wrappers.
|
|
|
|
|
|
| |
The only decoders I could find and which (possibly) require this field
are codecs which can be used via VfW only, and realaudio sipr. For VfW
we still passthrough this field.
|
|
|
|
|
|
| |
Verify memory accesses and such. The behavior should be equivalent.
(RealAudio causes pain for everyone even in its grave.)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Native Matroska codec support has to map the Matroska codec IDs to
libavcodec ones, and also has to undo codec-specific Matroska
strangeness, such as restoring AAC extradata and realaudio handling. The
VfW codec support doesn't need it, because AVI maps well enough to
libavcodec conventions (possibly because AVI was a dominant codec when
libavcodec was created). But there's still some need for generic codec
handling, such as enabling parsers and messing with various codec
parameters.
Separate these two, and move the parts which are guaranteed not to be
needed by VfW to the if-else tree that handles the VfW case
("A_MS/ACM"), making the cases exclusive.
(This should probably be done more radically, since it's very unlikely
that we should or have to mess with the VfW parameters at all - they
should just be passed through to the decoder.)
|
|
|
|
|
| |
This is actually more readable. Most of the defines are used only once,
so using a symbol instead of the direct string only obfuscated it.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This removes the last traces of the old MPlayer FourCC-based codec
mapping code. Forcing all codec IDs through a FourCC table and then
back to codec names was confusing at best, so this is a nice cleanup.
Handling of PCM (non-VfW case) is redone to some degree.
Handling of AC3 is moved below realaudio handling, since "A_REAL/DNET"
is apparently AC3, and we must not skip realaudio-specific handling.
(It seems unlikely that anything would actually break, but on the other
hand I don't have any A_REAL/DNET samples for testing.)
Instead of explicitly matching all the specific AAC codec names, just
match them all as prefix.
Some codecs don't need special handling other than their mapping
entries, so they fall away (like Vorbis and Opus).
The prores check in mkv_parse_and_add_packet() is not strictly related
to this, but is done for consistency with the wavpack check above.
|
| |
|
|
|
|
| |
Signed-off-by: wm4 <wm4@nowhere>
|
|
|
|
|
|
| |
The existing code avoided doing this for some codecs. I see no point in
this, and it seems the original reason this exists was due to some
cleanup in 2007. libavformat doesn't do this. So just drop it.
|
|
|
|
|
|
|
|
| |
It's well possible that we've always ended up invoking the
AV_CODEC_ID_MPEG1VIDEO codec, but it's hard to tell. Mangling everything
through FourCCs (and then back) makes it hard to analyze. Also,
libavformat's Matroska demuxer uses AV_CODEC_ID_MPEG2VIDEO here, so it
should be quite safe to do anyway.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Inherited from MPlayer times, we used FourCCs to identify video codecs.
This was later changed to libavcodec codec names (which made life a
whole lot simpler). But demux_mkv still uses FourCCs a lot.
Change this for video. It's pretty simple, because some preparation was
done in the past. We just have to replace some "internal" FourCCs with
different handling.
One potentially complicated issue is that there is no natural way to
set the sh->format (AVCodecContext.codec_tag) field anymore. Most
decoders do not need it, though mjpeg is an exception.
Note that the AVI compatibility code still requires codec mappings, but
these are provided by FFmpeg. Also, the audio code is not changed.
For the MKV_V_MPEG2 -> mpeg1video thing see next commit.
|
|
|
|
|
| |
Replace an else block with a nested if with just "else if". No
functional or other changes.
|
|
|
|
| |
Reduces the mess slightly.
|
|
|
|
|
| |
"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.
|
|
|
|
|
| |
In this case, streaming ogg via mpd over icecast made it buffer
infinitely on new tracks.
|
|
|
|
| |
It doesn't need access to the playback core state anymore.
|
|
|
|
|
|
|
|
|
| |
This reads the "CUESHEET" tag, and attempts to parse it as .cue data. If
any is found, the cue tracks are added as chapters.
This reuses the parser written for demux_cue.c.
Fixes #1957.
|
|
|
|
| |
Preparation for the next commit.
|
|
|
|
|
| |
Instead of bstr. Most callers of this function do not need bstr. The
bstr version of this function is now mp_path_join_bstr().
|
|
|
|
| |
stream.url can never be NULL, although it probably used to be.
|
|
|
|
|
| |
And also fix the description. It didn't actually reflect what the code
did.
|
|
|
|
|
| |
There is some potential for breakage. If it happens, this might have to
be disabled by default.
|
|
|
|
|
|
|
| |
The options don't change, but they're now declared and used privately by
demux_mkv.c. This also brings with it a minor refactor of the subpreroll
seek handling - merge the code from playloop.c into demux_mkv.c. The
change in demux.c is pretty much equivalent as well.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change allows forward seeking even if there are no more video
keyframes in forward direction. This helps with files that e.g. encode
cover art as a single video frame (within a _real_ video stream - ffmpeg
seems to like to produce such files). Seeking backwards will still jump
to the nearest video frame, so this improvement has limited use.
The old code didn't do this because of the logic the min_diff variable
followed. Instead of somehow using the timestamp of the last packet read
for min_diff, use the first index entry for it. This actually makes it
fall back to the first/last index entry as the (removed) comment claims.
Note that last_pts is basically random at this point (because the
demuxer can be far ahead of playback position), so this didn't make
sense in the first place.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On EOF, this stopped reporting the actual cache duration, and just
signalled unknown duration. Fix this and keep reporting whatever is left
in the packet queue.
This reverts commit 5438a8b3. The commit doesn't give a good explanation
as to why it is needed, but I guess it was because the reporting was
imperfect (it switched between unknown or 0, and the correct duration).
This also removes a line added in commit 848546f2. The line is
ds->active = false;
The "active" flag basically says that data from this stream is actively
needed, and it's used to calculate the minimum data that can actually be
played (approximately). If this were ignored, a sparse subtitle stream
would set the cache duration to 0s. The commit message adding the line
says "actually does nothing, but in theory it's cleaner". Well, screw
it.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
| |
If a directory is encountered, replace it with its contents in the
internal playlist.
This is messed into demux_playlist.c, because why not. STREAMTYPE_DIR
could be avoided by unconditonally trying opendir() in demux_playlist.c,
but it seems nicer not to do weird things like calling it on real files.
This does not work on Windows, because msvcrt is retarded.
|
| |
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With a recent cleanup, rar support was stuffed into demux_playlist.c
(because "opening" rar files pretty much just lists archive contents and
adds them to a playlist using a special rar:// protocol, which will
actually access the rar file contents).
Since demux_playlist.c is probed _after_ demux_lavf.c (and should/must
be), libavformat was given the chance to detect DTS streams embedded
within the rar file. This is not really what we want, and a regression
what happened before rar listing was moved to demux_playlist.c.
Fix it by moving the rar listing into its own pseudo-demuxer, and let ir
probe before demux_lavf.c.
(Yes, this feature still has users.)
|
|
|
|
|
| |
Don't bother with making these visible by default, because often they
are bogus and/or useless.
|
|
|
|
|
| |
Could theoretically dereference "d" later in the loop. It's on an error
codepath, so just give up.
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
If this happens, the file is actually broken, but the assumption is
simply that the file was truncated, and printing a warning would be
strange.
|
|
|
|
|
|
|
|
|
| |
Check async abort notification. libavformat already do something
equivalent.
Before this commit, the demuxer could enter resync mode (and print silly
warning messages) when the stream stopped returning data because of an
abort.
|
|
|
|
|
| |
This is missing from the previous commit. Not that harmful, but also
slightly un-nice since even a failed seek will reset the cache.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A user reported a webm stream that couldn't be played. The issue was
that this stream 1. was on an unseekable HTTP connection, and 2. had a
SeekHead element (wtf?). The code reading the SeekHead marked the
element as unreadable too early: although you can't seek in the stream,
reading the header elements after the SeekHead read them anyway. Marking
them as unreadable only after the normal header reading fixes this.
(The way the failing stream was setup was pretty retarded: inserting
these SeekHead elements makes absolutely no sense for a stream that
cannot be seeked.)
Fixes #1656.
|
| |
|
|
|
|
|
|
|
| |
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.)
|
|
|
|
|
|
|
|
|
|
|
|
| |
It was possible to make the player play local files by putting rar://
links into remote playlists, and some other potentially unsafe things.
Redo the handling of it. Now the rar-redirector (the thing in
demux_playlist.c) sets disable_safety, which makes the player open any
playlist entries returned. This is fine, because it redirects to the
same file anyway (just with different selection/interpretation of the
contents). On the other hand, rar:// itself is now considered fully
unsafe, which means that it is ignored if found in normal playlists.
|
|
|
|
|
|
|
|
|
| |
This warning wasn't overly helpful in the past, and warned against
perfectly fine code. But at least with recent gcc versions, this is the
warning that complains about assignments in if expressions (why???), so
we want to enable it.
Also change all the code this warning complains about for no reason.
|
|
|
|
| |
Unused since the previous commit. (Apparently it was a stupid idea.)
|
|
|
|
|
|
|
|
|
|
|
|
| |
Refactors an older hack, which for some reason used a more complicated
way. This generates the playlist representing the contents of the rar
file in demux_playlist.c. The pseudo-demuxer could easily be separate
from the the playlist parsers (and in fact there's almost no shared
code), but I don't think this obscure feature deserves a separate file.
Sample files created with:
rar a -v20000k -m0 files.rar file1.mkv file1.mkv
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the cache is enabled, the demuxer is closed and opened again (because
currently, the cache can not be enabled atfer data was already read).
The call for opening a new demuxer uses the same params struct, which
references the ctx->uids array. But there is a MP_TARRAY_GROW()
invocation somewhere on the way, which can reallocate the ctx->uids
array, making params.uids a dangling pointer.
This issue probably existed for a longer time, probably since 5cd33853
(slightly more obvious since f50b105d).
|
|
|
|
|
|
|
| |
Again removes some indirections and extra arguments.
Also replace some memcpy/memmoves with assignments. (Assignments became
possible only later, when reference UIDs were turned into a struct.)
|
|
|
|
| |
Removes tripple pointer indirections and such.
|
|
|
|
|
|
| |
Should behave about the same, but reduces code some duplication with
seeking and reading a header element pointed to by a SeekHead. It also
makes behavior with incomplete files slightly better.
|
|
|
|
|
| |
Limit it to a single message. It often printed more than that, and in
some cases (old files with "cluster" index), spammed a lot.
|
|
|
|
|
|
|
| |
Remove coded_width and coded_height. This was originally added in commit
fd7dde40, when BITMAPINFOHEADER was killed. The separate fields became
redundant in commit e68f4be1. Remove them (nothing passed to the
decoders actually changes with _this_ commit).
|
| |
|
|
|
|
|
| |
Often stream and a demuxer are opened at the same time. Provide a
function for this and repla |