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.
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 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.
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.
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.
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.
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 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.
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.
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).
The Matroska timeline code was the only thing which still used the
demuxer.type field. This field explicitly identifies a demuxer
implementation. The purpose of the Matroska timeline code was to reject
files that are not Matroska. But it already forces the Matroska format,
meaning loading will explicitly only use the Matroska demuxer. If the
demuxer can't open the file, no other demuxer will be tried, and thus
checking the field is redundant.
The change in demux_mkv_timeline.c removes the if condition, and
unindents the if body.
This removes the delay when switching audio tracks in mkv or mp4 files.
Other formats are not enabled, because it's not clear whether the
demuxers fulfill the requirements listed in demux.h. (Many formats
definitely do not with libavformat.)
Background:
The demuxer packet cache buffers a certain amount of packets. This
includes only packets from selected streams. We discard packets from
other streams for various reasons. This introduces a problem: switching
to a different audio track introduces a delay. The delay is as big as
the demuxer packet cache buffer, because while the file was read ahead
to fill the packet buffer, the process of reading packets also discarded
all packets from the previously not selected audio stream. Once the
remaining packet buffer has been played, new audio packets are available
and you hear audio again.
We could probably just not discard packets from unselected streams. But
this would require additional memory and CPU resources, and also it's
hard to tell when packets from unused streams should be discarded (we
don't want to keep them forever; it'd be a memory leak).
We could also issue a player hr-seek to the current playback position,
which would solve the problem in 1 line of code or so. But this can be
rather slow.
So what we do in this commit instead is: we just seek back to the
position where our current packet buffer starts, and start demuxing from
this position again. This way we can get the "past" packets for the
newly selected stream. For streams which were already selected the
packets are simply discarded until the previous position is reached
again.
That latter part is the hard part. We really want to skip packets
exactly until the position where we left off previously, or we will skip
packets or feed packets to the decoder twice. If we assume that the
demuxer is deterministic (returns exactly the same packets after a seek
to a previous position), then we can try to check whether it's the same
packet as the one at the end of the packet buffer. If it is, we know
that the packet after it is where we left off last time.
Unfortunately, this is not very robust, and maybe it can't be made
robust. Currently we use the demux_packet.pos field as unique packet
ID - which works fine in some scenarios, but will break in arbitrary
ways if the basic requirement to the demuxer (as listed in the demux.h
additions) are broken. Thus, this is enabled only for the internal mkv
demuxer and the libavformat mp4 demuxer.
(libavformat mkv does not work, because the packet positions are not
unique. Probably could be fixed upstream, but it's not clear whether
it's a bug or a feature.)
Until now, some packets could return the same file position if they were
split off from a Matroska-level packet. This was perfectly fine, because
the file position isn't used for anything overly important (it uses it
to estimate playback position if no other information is available). The
following commit will use the demux_packet.pos field as unique ID (as a
simplification), so make the demuxer export more finegrained
information.
Also, the last_filepos field didn't have to be global, at least not
anymore.
Reindent the whole handle_realaudio() function, and make the surrouding
if block return early instead.
Also contains some cosmetics to the sipr swapping, which hopefully does
not change the semantics, but is untested (the kind of cosmetic changes
everyone loves so much). May the person responsible for sipr rot in
hell. (It was probably done to obfuscate the codec?)
Staring at the code, it doesn't look like the extra code for "normal"
audio is needed. Most of it looks like artifacts from the previous code
structure (much of it was added in the initial commit). I couldn't find
a sample that uses this code path to fully confirm this, though.
I suppose it could lead to subtle changes in behavior in presence of
realvideo files that change aspect radio. With the only sample I had
available, the behavior actually improved (azumi.mkv from the MPlayer
samples FTP; when starting playback in the middle it used the wrong
aspect ratio).
Appears to work, so we can drop some code. For some really odd reason,
the descrambling done on the timestamp requires millisecond units (due
to the "algorithm", not the libavcodec API).
Fixes vp9 missing timestamps. This requires a brand new libavcodec (the
patch for this was just applied to FFmpeg git master).
The timestamp mangling is applied to VP9 only. It'd probably work with
other codecs, but it's not needed. It could break in various ways, so
it has to be explicitly checked for every enabled codec.
Makes it somewhat more uniform, and breaks up the awfully deep nesting.
This implicitly changes multiple small details, rather than only moving
code around. In particular, this computes the packet fields first and
parses them afterwards, which is needed for the next commit.
Might fix behavior with mkv files that use ordered chapters and have
cover art tags. In my opinion, this should actually have worked (because
cover art pseudo-tracks are strictly appended), but I don't have a
sample file to test at hand.
The VP9 codec parser has a bug: it doesn't set the data/size pointers
passed to it. As I understand, it must always do this, and in fact, if
it doesn't some libavcodec generic code would be in trouble too.
This helps with #1448, but is not the full fix for it. The codec parser
must be fixed in libavcodec itself.
Removes an annoying "No video PTS! Making something up." warning.
Mark it as keyframe, which is needed to prevent strange behavior with
PNG. Also, don't leak the picture data.
For some codecs, we need to invoke a codec parser (because libavcodec
will run into trouble otherwise). This was done based on the Matroska
codec field.
But this ignores handling of vfw-muxed files, which use a pseudo-codec
to signal presence of vfw structures, which we must unmangle to get the
real codec. Handle this by rearranging the code.
This fixes at least mp3-in-mkv for vfw-muxed files; typically old files.
This message can happen a lot for mkv files which index clusters in the
seekhead (which is also broken non-sense, but that's a different story).
Also remove a duplicate define from matroska.h.
The code could as well be in demux.c, but it's better to avoid
accidental clashes with demux_lavf.c.
FFmpeg provides no way yet to map a mime type to a codec, so do it
manually. (It _can_ map a mime type to an "input format", but not a
codec.)
Fixes#1374.
The most awesome codec, not.
The actual code for svq3 is actually just the part that checks for
MKV_V_QUICKTIME (no other QT-muxed codecs are supported). The rest is
minor refactoring, that actually improves the code in general.
This is just enough to support the 2 svq3-in-mkv sample files I have.
All of this is basically due to how MPlayer's codecs.conf worked. It
had a demuxer-interface based an AVI, using FourCCs and data structures
found in AVI. FourCCs were used to map streams to decoders. For codecs
not supported by AVI, "MPlayer internal" FourCCs were made up.
codec_tags.c is there to bridge demuxers written against the old API to
the mpv one. By now, only demux_mkv.c needs this (because demux_mkv is
the only serious demuxer left - preferably, we should use libavformat
for mkv too, but I can't see this happening any time soon, because
libavformat _still_ doesn't support segment linking). But the codec
tables are full of weird stuff automatically extracted from the old
codecs.conf tables. Most of it isn't needed for mkv.
Remove all custom tags, readd those used by demux_mkv.c internally
(see vinfo and mkv_audio_tag tables). The rest is handled by the
tables provided by libavformat, which includes AVI and QT tags.
It was more complicated than necessary.
The behavior changes slightly. Now it might pass through extradata when
it didn't before (hopefully harmless), and doesn't fail with an error if
extradata is not available, even though it's needed (harmless, will fail
either way).
