This affects 64 bit floats and big endian integer PCM variants
(basically crap nobody uses). Possibly not all MS-muxed files work, but
I couldn't get or produce any samples.
Remove a bunch of format tags that are not needed anymore. Most of these
were used by demux_mov, which is long gone. Repurpose/abuse 'twos' as
mpv-internal tag for dealing with the PCM variants mentioned above.
This member was redundant. sh_audio->sample_format indicates the sample
size already.
The TV code is a bit strange: the redundant sample size was part of the
internal TV interface. Assume it's really redundant and not something
else. The PCM decoder ignores the sample size anyway.
Somehow the new parser ends up much smaller. Much of it is because we
don't parse some additional information. We just skip it, instead of
parsing it and then throwing it away.
More importantly, we use the physical order of entries, instead of
trying to sort them by entry number. Each "File" entry is followed by a
number that is supposed to be the entry number, and "File1" is first.
(Should it turn out that this is really needed, an additional field
should be added to playlist_entry, and then qsort().)
Make TOOLS/matroska.pl output structs with fields sorted by name in
ebml_types.h to make the order of fields deterministic. Fix warnings in
demux_mkv.c caused by the first struct fields switching between scalar
and struct types due to non-deterministic ebml_types.h field order.
Since it's deterministic now, this shouldn't change anymore.
The warnings produced by the compilers are bogus, but we want to silence
them anyway, since this could make developers overlook legitimate
warnings.
What commits 7b52ba8, 6dd97cc, 4aae1ff were supposed to fix. An earlier
attempt sorted fields in the generated C source file, not the header
file. Hopefully this is the last commit concerning this issue...
The configure followed 5 different convetions of defines because the next guy
always wanted to introduce a new better way to uniform it[1]. For an
hypothetic feature 'hurr' you could have had:
* #define HAVE_HURR 1 / #undef HAVE_DURR
* #define HAVE_HURR / #undef HAVE_DURR
* #define CONFIG_HURR 1 / #undef CONFIG_DURR
* #define HAVE_HURR 1 / #define HAVE_DURR 0
* #define CONFIG_HURR 1 / #define CONFIG_DURR 0
All is now uniform and uses:
* #define HAVE_HURR 1
* #define HAVE_DURR 0
We like definining to 0 as opposed to `undef` bcause it can help spot typos
and is very helpful when doing big reorganizations in the code.
[1]: http://xkcd.com/927/ related
Instead of having each demuxer do it (only demux_mkv actually did...),
let generic code determine whether the file is seekable. This requires
adding exceptions to demuxers where the stream is not seekable, but the
demuxer is.
Sort-of try to improve handling of unseekable files in the player. Exit
early if the file is determined to be unseekable, instead of resetting
all decoders and then performing a pointless seek.
Add an exception to allow seeking if the file is not seekable, but the
stream cache is enabled. Print a warning in this case, because seeking
outside the cache (which we can't prevent since the demuxer is not aware
of this problem) still messes everything up.
Pointless, using stream->start_pos/end_pos instead.
demux_mf was the only place where this was used specially, but we can
rely on timestamps instead for this case.
There are some Microsoft Windows symbols which are traditionally used by
the mplayer core, because it used to be convenient (avi was the big
format, using binary windows decoders made sense...). So these symbols
have the exact same definition as the Windows one, and if mplayer is
compiled on Windows, the symbols from windows.h are used.
This broke recently just because some files were shuffled around, and
the symbols defined in ms_hdr.h collided with windows.h ones. Since we
don't have windows binary decoders anymore, there's not the slightest
reason our symbols should have the same names. Rename them to reduce the
risk for collision, and to fix the recent regression.
Drop WAVEFORMATEXTENSIBLE, because it's mostly unused. ao_dsound defines
its own version if the windows headers don't define it, and ao_wasapi is
not available on systems where this symbol is missing.
Also reindent ms_hdr.h.
Now that matroska.pl generates struct fields in deterministic order,
this should be the last time I change this.
(gcc and clang shouldn't warn about this line of code, but since they
do, we want to workaround and silence the warning anyway.)
Unfortunately, we can't avoid this warning 100%, because ebml_info is
written by a Perl script. I think the script writes the struct fields in
random order (thanks Perl), so there's no way to know whether the first
struct field is a scalar or a struct.
At least {0} is always valid here, even if it shows a warning. (The
compilers are wrong, see e.g. [1].)
[1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53119
This one really did bite me hard (see previous commit), so enable it by
default.
Fix some cases of shadowing throughout the codebase. None of these
change behavior, and all of these were correct code, and just tripped up
the warning.
gcc and clang happen to allow {} to default-initialize a struct, but
strictly speaking, C99 requires at least {0}. In one case, we use {{0}},
but that's only because gcc as well as clang are too damn stupid not
to warn about {0}, which is a perfectly valid construct in this case.
(Sure is funny, don't warn about the non-standard case, but warn about
another standard conform case.)
Leaving these braces away just because the syntax allows them is really
obnoxious. It removes the visual cues which help understanding the code
at the first look.
For the record,
if (cond)
something();
is ok, as long as there's no else branch, and the if body is one
physical line. But everything else should have braces.
This was probably not a real problem. But it's not entirely clear
whether this could actually happen or not, so it's better to be
defensive. The code is now also somewhat easier to understand.
This adds support for ChapterSegmentEditionUID (pull request #258),
and also fixes issue #278 (pull request #292).
In fact, this is a straight merge of pr/292, which also contains pr/258.
Note that you still need --vd-lavc-o='strict=-2' to enable the decoder.
Also, there's no guarantee that all required features for HEVC demuxing
are actually implemented, nor that the current muxing schema is the
final one.
Change talloc destructor so that they can never signal failure, and
don't return a status code. This makes our talloc copy even more
incompatible to upstream talloc, but on the other hand this is
preparation for getting rid of talloc entirely.
(The talloc replacement in the next commit won't allow the talloc_free
equivalent to fail, and the destructor return value would be useless.
But I don't want to change any mpv code either; the idea is that the
talloc replacement commit can be reverted for some time in order to
test whether the talloc replacement introduced a regression.)
To support edition references in matroska chapters, editions need to be
remembered for each chapter and source. To facilitate easier management
of these now-paired uids, a single structure is used.
There is uninitialized memory access if the actual size isn't passed
along. In the worst case, this can cause a source to be loaded against
the uninitialized memory, causing a false count of found versus required
sources, preventing the "Failed to find ordered chapter part" message.
By default, libavformat uses UDP for rtsp playback. This doesn't work
very well. Apparently the reason is that the buffer sizes libavformat
chooses for UDP are way too small, and switching to TCP gets rid of this
issue entirely (thanks go to Reimar Döffinger for figuring this out).
In theory, you can set buffer sizes as libavformat options, but that
doesn't seem to help.
Add an option to select the rtsp transport, and make TCP the default.
Also remove an outdated comment from stream.c.
In insane files with a very huge number of subtitle events, and if the
--demuxer-mkv-subtitle-preroll option is given, seeking can still
overflow the packet queue. Normally, the subtitle_preroll variable
specifies the maximum number of packets that can be added. But once this
number is reached, the normal seeking behavior is enabled, which will
add all subtitle packets with the right timestamps to the packet queue.
At this point the next video keyframe can still be quite far away, with
enough subtitle packets on the way to overflow the packet queue.
Fix this by always setting an upper limit of subtitle packets read
during seeking. This should provide additional robustness even if the
preroll option is not used.
This means that even with normal seeking, at most 500 subtitle packets
are demuxed. Packets after that are discarded.
One slightly questionable aspect of this commit is that subtitle_preroll
is never reset in audio-only mode, but that is probably ok.
The quicktime html scripting guide suggests to wrap urls not
necesarly associated with quicktime in a .mov file.
(so that when <embed>ing videos quicktime would be forced.)
These mov files may contain several "Text Hacks".
One of these is RTSPtext.
The suggested/allowed format (as regex) is like:
RTSPtext[ \r]RTSP://url
See also p.51 of:
https://developer.apple.com/library/mac/documentation/QuickTime/Conceptual/QTScripting_HTML/QTScripting_HTML.pdf
In reality there are also files like (e.g. zdfmediathek.de):
RTSPtext\nrtsp://url\n\n
Lets handle these files as a playlist with one element.
The --deinterlace option does on playback start what the "deinterlace"
property normally does at runtime. You could do this before by using the
--vf option or by messing with the vo_vdpau default options, but this
new option is supposed to be a "foolproof" way.
The main motivation for adding this is so that the deinterlace property
can be restored when using the video resume functionality
(quit_watch_later command).
Implementation-wise, this is a bit messy. The video chain is rebuilt in
mpcodecs_reconfig_vo(), where we don't have access to MPContext, so the
usual mechanism for enabling deinterlacing can't be used. Further,
mpcodecs_reconfig_vo() is called by the video decoder, which doesn't
have access to MPContext either. Moving this call to mplayer.c isn't
currently possible either (see below). So we just do this before frames
are filtered, which potentially means setting the deinterlacing every
frame. Fortunately, setting deinterlacing is stable and idempotent, so
this is hopefully not a problem. We also add a counter that is
incremented on each reconfig to reduce the amount of additional work per
frame to nearly zero.
The reason we can't move mpcodecs_reconfig_vo() to mplayer.c is because
of hardware decoding: we need to check whether the video chain works
before we decide that we can use hardware decoding. Changing it so that
this can be decided in advance without building a filter chain sounds
like a good idea and should be done, but we aren't there yet.
Retrieve per-chapter metadata, but don't do much with it. We just make
the metadata of the _current_ chapter available as chapter-metadata
property. Returning the full chapter list with metadata would be no
problem, except that the property interface isn't really good with
structured data, so it's not available for now.
Not sure if it's worth it, but it was requested via github issue #201.
Consider the cluster used for prerolling contains an insane amount of
subtitle packets. Then the demuxer packet queue would be full of
subtitle packets, and demux.c would refuse to read any further packets -
including video and audio packets, resulting in EOF. Since everything
involving Matroska and subtitles is 100% insane, this can actually
happen.
Fix this by putting a limit on the number of subtitle packets read by
preroll, and throw away any further packets if the limit is exceeded. If
this happens, the preroll mechanism will stop working, but the player's
operation is unaffected otherwise.
The really funny thing about this commit is that this code is added on
top of another work around. Basically, subtitle seeking in libavformat
is completely broken. To make it useful, we have to add yet another
workaround.
The basic problem is that libavformat's subtitle seeking code always
uses the stream time base, instead of AV_TIME_BASE if stream index -1 is
passed to the avformat_seek_file() function.
Fixes github issue #216. Hopefully this will be fixed in ffmpeg too at
some point.
Port it from playlist_parser.c to demux_playlist.c. Also, change the m3u
parser to drop whitespace from the trailing part of the line (will make
it work properly with windows line endings).
(I hoped that this would make MMS URIs with http instead of mmsh
prefixes work, but it doesn't. Instead, it leads to a playlist loop. So
solving this issue would require a change in ffmpeg, probably.)
Apparently, it is popular to store large files in uncompressed rar
archives. Extracting files is not practical, and some media players
suport playing directly from uncompressed rar (at least VLC and some
DirectShow components).
Storing or accessing files this way is completely idiotic, but it is
a common practice, and the ones subjected to this practice can't do
much to change this (at least that's what I assume/hope). Also, it's
a feature request, so we say yes.
This code is mostly taken from VLC (commit f6e7240 from their git tree).
We also copy the way this is done: opening a rar file by itself yields
a playlist, which contains URLs to the actual entries in the rar file.
Compressed entries are simply skipped.
Modeled after the old playlist_parser.c, but actually new code, and it
works a bit differently.
Demuxers (and sometimes streams) are the component that should be used
to open files and to determine the file format. This was already done
for subtitles, but playlists still use a separate code path.
The way this was added to FFmpeg is less than ideal, because it requires
text parsing in the Matroska demuxer. But in order to use the FFmpeg
webvtt-to-ass converter, we still have to mimic this in some way. We do
this by putting the parsing into sd_lavc_conv.c, before the subtitle
packet is passed to libavcodec. At least this keeps the ugliness out of
unrelated code.
There is some change that FFmpeg will fix their design eventually.
Instead of rewriting the parsing code, we simply borrow it from FFmpeg's
Matroska demuxer.
Otherwise, this would just try to demux a good chunk of the file, even
though the operation can't succeed anyway.
This caused some pretty strange issues, where perfectly valid use cases
would print a "Too many packets in the demuxer packet queue..." message.
The rawaudio demuxer read one frame per packet, basically a few bytes,
which caused insane overhead. (I found this when I couldn't play raw
audio without dropouts when using -v, which printed a line per packet
read.)
Fix this and read 1 second of audio per packet. This is a regression
since cfa5712 (merging of demux_rawaudio and demux_rawvideo).
Originally, the objective of this commit was changing --edition to be
1-based, but this was cancelled. I'm still leaving the change to
demux_mkv.c though, which is now only of cosmetic nature.
This is completely useless, and in this particular case, it broke the
fallback for MLP2 subtitles (stored as .txt files) to demux_subreader.
(Yes, libavformat should be fixed to handle this, but for now this will
_always_ break playback of subtitle files stored in .txt.)
You can still force this demuxer, but by default we will just pretend
that the "tty" demuxer does not exist.
Perhaps not very useful, but reserved for situations when a user reports
awful latency and experimentation/debugging might be required to find
out why or to fix it (happens often).
avio_alloc_context() is documented to require an av_malloc'ed buffer. It
appears libavformat can even reallocate the buffer while it is probing,
so passing a static buffer can in theory lead to crashes.
I couldn't reproduce such a crash, but apparently it happened to
mplayer-svn. This commit follows the mplayer fix in svn commit r36397.
Move the decoder parts from vo_vdpau.c to a new file vdpau_old.c. This
file is named so because because it's written against the "old"
libavcodec vdpau pseudo-decoder (e.g. "h264_vdpau").
Add support for the "new" libavcodec vdpau support. This was recently
added and replaces the "old" vdpau parts. (In fact, Libav is about to
deprecate and remove the "old" API without deprecation grace period,
so we have to support it now. Moreover, there will probably be no Libav
release which supports both, so the transition is even less smooth than
we could hope, and we have to support both the old and new API.)
Whether the old or new API is used is checked by a configure test: if
the new API is found, it is used, otherwise the old API is assumed.
Some details might be handled differently. Especially display preemption
is a bit problematic with the "new" libavcodec vdpau support: it wants
to keep a pointer to a specific vdpau API function (which can be driver
specific, because preemption might switch drivers). Also, surface IDs
are now directly stored in AVFrames (and mp_images), so they can't be
forced to VDP_INVALID_HANDLE on preemption. (This changes even with
older libavcodec versions, because mp_image always uses the newer
representation to make vo_vdpau.c simpler.)
Decoder initialization in the new code tries to deal with codec
profiles, while the old code always uses the highest profile per codec.
Surface allocation changes. Since the decoder won't call config() in
vo_vdpau.c on video size change anymore, we allow allocating surfaces
of arbitrary size instead of locking it to what the VO was configured.
The non-hwdec code also has slightly different allocation behavior now.
Enabling the old vdpau special decoders via e.g. --vd=lavc:h264_vdpau
doesn't work anymore (a warning suggesting the --hwdec option is
printed instead).
Remove the (now unused) code for determining correct-pts mode based on
the demuxer in use. Change its description in the manpage to reflect
what this option does now.
Gives really funky results with PNG attachments otherwise. The main
problem is that avcodec_flush_buffers() does not fully reset the
decoder, so passing multiple PNG packets without keyframe flags will
attempt to combine the new picture with the previously decoded
contents. (Makes no sense with proper PNG - maybe this codepath is
intended for MNG or APNG.)
In general, this warning can hint to actual bugs. We don't enable it
yet, because it would conflict with some unmerged code, and we should
check with clang too (this commit was done by testing with gcc).
This also affects --audiofile. The previous behavior wasn't really
useful. There are even separate switches for that: --audio-demuxer and
--sub-demuxer.
This fixes the sample RA_missing_timestamps.mkv. Pretty funny how this
code got it almost right, but not quite, so it was broken all these
years. And then, after everyone stopped caring, someone comes and fixes
it. (By the way, I know absolutely nothing about realaudio.)
This fixes playback of the sample linked by FFmpeg ticket 2508. The fix
follows ffmpeg commit 6158a3b (although it's not exactly the same).
The problem here is that the file contains an apparently non-sense
DefaultDuration value. DefaultDuration for audio tracks is used to
derive PTS values for packets with no timestamps, like they can happen
with frames inside a laced block. So the first packet of a SimpleBlock
will have a correct PTS, while the PTS values of the following packets
are calculated using DefaultDuration, and thus are broken.
This leads to seemingly ok playback, but broken A/V sync. Not using the
DefaultDuration value will leave the PTS values of these packets unset,
and the audio decoder can derive them from the output instead.
The fix more or less uses a heuristic to detect the broken case: if the
sample rate is 8 KHz (Matroska default, can assume unset), and the codec
is AC3 (as the broken file did), don't use it. I'm not sure why this
should be done only for AC3, maybe the muxing application (mkvmerge
v4.9.1) has known issues with AC3. AC3 also doesn't support 8 KHz as
sample rate natively.
(By the way, I'm not sure why we should honor the DefaultDuration at all
for audio. It doesn't seem to be needed. You can't seek to these frames,
and decoders should always be able to produce perfect PTS values by
adding the duration of the decoded audio to the first PTS.)
Matroska has an output sample rate (OutputSamplingFrequency), which in
theory should be forced instead of whatever the decoder outputs. But it
appears no software (other than mplayer2 and mpv until now) actually
respects this. Even worse, there were broken files around, which played
correctly with (in theory) broken software, but not mplayer2/mpv. Hacks
were added to our code to play these files correctly, but they didn't
catch all cases.
Simplify this by doing what everyone else does, and always use the
decoder's sample rate instead. In particular, we try to handle all
sample rate issues like libavformat's Matroska demuxer does.
Guess the colorspace directly in mpcodecs_reconfig_vo(), instead of in
set_video_colorspace(). The difference is that the latter function just
makes the video filter chain (and VOs) force the detected colorspace,
and then throws it away, while the former is a bit more general and
central. Not really a big difference and it doesn't matter much in
practice, but it guarantees that there is no internal disagreement about
the colorspace.
DVD playback had some trouble with PTS resets: libavformat's genpts
feature would try reading until EOF (worst case) to find a new usable
PTS in case a packet's PTS is not set correctly. Especially with slow
DVD access, this would make the player to appear frozen.
Reimplement it partially in demux_lavf.c, and use that code in the DVD
case. This is heavily "inspired" by the code in av_read_frame from
libavformat/utils.c. The difference is that we stop reading if no PTS
has been found after 50 packets (consider this a heuristic). Also, we
don't bother with the PTS wrapping and last-frame-before-EOF handling.
Even with normal PTS wraps, the player frontend will go to hell for the
duration of a frame anyway, and should recover quickly after that.
The terribleness of this commit is mostly that we duplicate libavformat
functionality, and that we suddenly need a packet queue.
All demuxers make a reasonable effort to set packet timestamps, and thus
support correct-pts mode. This commit also implicitly switches
demux_rawvideo to correct-pts mode.
We still allow demuxers to disable correct-pts mode in theory.
Get rid of the strange and messy reliance on DEMUXER_TYPE_ constants.
Instead of having two open functions for the demuxer callbacks (which
somehow are both optional, but you can also decide to implement both...),
just have one function. This function takes a parameter that tells the
demuxer how strictly it should check for the file headers. This is a
nice simplification and allows more flexibility.
Remove the file extension code. This literally did nothing (anymore).
Change demux_lavf so that we check our other builtin demuxers first
before libavformat tries to guess by file extension.
This removes the dependency on DEMUXER_TYPE_* and the file_format
parameter from the stream open functions.
Remove some of the playlist handling code. It looks like this was
needed only for loading linked mov files with demux_mov (which was
removed long ago).
Delete a minor bit of dead network-related code from stream.c as well.
Move codec_tags.h include to demux_mkv.c, because this is the only file
which still uses it.
Move new_sh_stream() to demux.h, because this is more proper.
Before this commit, we tried to play along with libavformat and tried
to pretend that attached pictures are video streams with a single
frame, and that the frame magically appeared at the seek position when
seeking. The playback core would then switch to a mode where the video
has ended, and the "remaining" audio is played.
This didn't work very well:
- we needed a hack in demux.c, because we tried to read more packets in
order to find the "next" video frame (libavformat doesn't tell us if
a stream has ended)
- switching the video stream didn't work, because we can't tell
libavformat to send the packet again
- seeking and resuming after was hacky (for some reason libavformat sets
the returned packet's PTS to that of the previously returned audio
packet in generic code not related to attached pictures, and this
happened to work)
- if the user did something stupid and e.g. inserted a deinterlacer by
default, a picture was never displayed, only an inactive VO window)
- same when using a command that reconfigured the VO (like switching
aspect or video filters)
- hr-seek didn't work
For this reason, handle attached pictures as separate case with a
separate video decoding function, which doesn't read packets. Also,
do not synchronize audio to video start in this case.
The code touched by this commit makes sure that DVD subtitle tracks
known by libdvdread but not known by demux_lavf can be selected and
displayed properly. These subtitle tracks have the first packet
some time late in the packet stream, so that libavformat won't
immediately recognize them, and will add the track as soon as the
first packet is seen during normal demuxing.
demux_mpg used to handle this elegantly: you just set the MPEG ID of
the stream you wanted. demux_lavf couldn't do this, so it was emulated
with a DEMUXER_CTRL. This commit changes it so that new streams are
selected by default (if autoselect is enabled), and the playloop
simply can take appropriate action before the lower layer throws away
the first packet.
This also changes the demux_lavf behavior that subtitle packets are
always demuxed, even if not needed. (They were immediately thrown away,
so there was no advantage to this.)
Further, this adds the ability to demux.c to deal with demuxing more
than one stream of a kind at once. (Though currently it's not useful.)
AVDISCARD_DEFAULT is probably a bit better for normal decoding.
AVDISCARD_NONE would (as by documentation) include "useless" packets
too, while DEFAULT filters these.
Generally remove all accesses to demux_stream from all the code, except
inside of demux.c. Make it completely private to demux.c.
This simplifies the code because it removes an extra concept. In demux.c
it is reduced to a simple packet queue. There were other uses of
demux_stream, but they were removed or are removed with this commit.
Remove the extra "ds" argument to demux fill_buffer callback. It was
used by demux_avi and the TV pseudo-demuxer only.
Remove usage of d_video->last_pts from the no-correct-pts code. This
field contains the last PTS retrieved after a packet that is not NOPTS.
We can easily get this value manually because we read the packets
ourselves. Reuse sh_video->last_pts to store the packet PTS values. It
was used only by the correct-pts code before, and like d_video->last_pts,
it is reset on seek. The behavior should be exactly the same.
Currently, all demuxer fill_buffer functions have a demux_stream
parameter. We want to remove that, but the TV code still depends on
it. Add a hack to remove that dependency.
The problem with the TV code is that reading video and audio frames
blocks, so in order to avoid a deadlock, you should read either of
them only if the decoder actually requests new data.
For now, we want to get rid of the demux->sub access, because this
field will become private to demux.c in a later commit. So replace the
current hack with another hack.
The need for the hack will be removed sooner or later. (Instead of
autoselecting a specific stream, all new streams will be enabled by
default, so that no packets can get lost. The frontend will then be
responsible to deselect unwanted streams.)
This is not directly related to the handling of format changes itself,
but playing audio normally after the change. This was broken: the output
byte rate was not recalculated, so audio-video sync was simply broken.
Fix this by calculating the byte rate on the fly, instead of storing it
in sh_audio.
Format changes are relatively common (switches between stereo and 5.1
in TV recordings), so this fixes a somewhat critical bug.
Partial packet reads were needed because the video/audio parsers were
working on top of them. So it could happen that a parser read a part of
a packet, and returned that to the decoder. With libavformat/libavcodec,
packets are already parsed, and everything is much simpler.
Most of the simplifications in ad_spdif could have been done earlier.
Remove some other stuff as well, like the questionable slave mode start
time reporting (could be replaced by proper code, but we don't bother).
Remove the unused skip_audio_frame() functionality as well (it was used
by old demuxers). Some functions become private to demux.c, like
demux_fill_buffer(). Introduce new packet read functions, which have
simpler semantics. Packets returned from them are owned by the caller,
and all packets in the demux.c packet queue are considered unread.
Remove special code that dropped subtitle packets with size 0. This
used to be needed because it caused special cases in the old code.
The demux_open as well as demux_open_withparams calls don't use the
stream selection parameters anymore, so remove them everywhere.
Completes the previous commit.
These separate arrays were used by the old demuxers and are not needed
anymore. We can simplify track switching as well.
One interesting thing is that stream/tv.c (which is a demuxer) won't
respect --no-audio anymore. It will probably work as expected, but it
will still open an audio device etc. - this is because track selection
is now always done with the runtime track switching mechanism. Maybe
the TV code could be updated to do proper runtime switching, but I
can't test this stuff.
The audio parser was needed only by the "old" demuxers, and
demux_rawaudio. All other demuxers output already parsed packets.
demux_rawaudio is usually for raw audio, so using a parser with it
doesn't usually make sense. But you can also force it to read
compressed formats with fixed packet sizes, in which case the parser
would have been used. This use case is probably broken now, but you
will be able to do the same thing with libavformat demuxers.
Delete demux_avi, demux_asf, demux_mpg, demux_ts. libavformat does
better than them (except in rare corner cases), and the demuxers have
a bad influence on the rest of the code. Often they don't output
proper packets, and require additional audio and video parsing. Most
work only in --no-correct-pts mode.
Remove them to facilitate further cleanups.
STREAM_CTRL_GET_METADATA will be used to poll for streamcast metadata.
Also add DEMUXER_CTRL_UPDATE_INFO, which could in theory be used by
demux_lavf.c. (Unfortunately, libavformat is too crappy to read metadata
mid-stream for mp3 or ogg, so we don't implement it.)
The filter chain and the video ouputs have config() functions. They are
strictly limited to transfering the video size and format. Other
parameters (like color levels) have to be transferred separately.
Improve upon this by introducing a separate set of reconfig() functions,
which use mp_image_params to carry format parameters. This struct
contains all image format related parameters from config(), plus
additional parameters such as colorspace.
Change vf_rotate to use it, as well as vo_opengl. vf_rotate is just
an example/test case, but vo_opengl will need it later.
The intention is also to get rid of VOCTRL_SET_YUV_COLORSPACE. This
information is now handed to the VOs via reconfig(). The getter,
VOCTRL_GET_YUV_COLORSPACE, will still be needed though.
Old code used to use libass' recoding feature, which is a copy of the
old MPlayer code. We dropped that a few commits ago. Unfortunately,
this made it impossible to load some subtitle files, like UTF-16 files.
Make .ass loading respect -subcp again. We do this by recoding the
probe buffer to UTF-8, and then trying to load it normally. (Yep.)
Since UTF-16 in particular will effectively half the probe buffer size,
double the probe size.
demux_libass.c allows us to make subtitle format detection part of the
normal file loading process. libass has no probe function, but trying to
load the start of a file (the first 4 KB) is good enough. Hope that
libass can even handle random binary input gracefully without printing
stupid log messages, and that the libass parser doesn't accept too many
non-ASS files as input.
This doesn't handle the -subcp option correctly yet. This will be fixed
later.
The default correct-pts mode depended on which demuxer was opened last.
Often this is the subtitle demuxer. The correct-pts mode should be
decided on the demuxer for video instead.
subreader.c (before this commit renamed to demux_subreader.c) was
special cased to the -sub option. The plan is using the normal demuxer
codepath for all subtitle formats (so we can prefer libavformat demuxers
for most formats).
There are some subtle changes. The probe size is restricted to 32 KB
(instead of unlimitted + giving up after 100 lines of input). For
formats like MicroDVD, the video FPS isn't used anymore, because it's
not available on the subtitle demuxer level. Instead, hardcode it to
23.976 FPS (libavformat seems to do the same). The user can probably
still use -sub-fps to fix the timing. Checking the file extension for
".utf"/".utf8"/".utf-8" is simply removed (seems worthless, was in the
way, and I've never seen this anywhere).
Simpler, reduces the amount of copying.
We still have to malloc+memcpy the probe buffer though, because padding
with FF_INPUT_BUFFER_PADDING_SIZE is required by libavformat.
If a subtitle is external, read it completely and add all subtitle
events in advance when the subtitle track is selected. This is done
for text subtitles only. (Note that subreader.c and subtitles loaded
with libass are different and don't have anything to do with this
commit.)
Seems like a completely unnecessary complication. Instead, always add a
1 byte padding (could be extended if a caller needs it), and clear it.
Also add some documentation. There was some, but it was outdated and
incomplete.
The stream EOF flag should only be set when trying to read past the end
of the file (relatively similar to unix files). Always clear the EOF
flag on seeking. Trying to set it "properly" (depending whether data is
available at seek destination or not) might be an ok idea, but would
require attention to too many special cases. I suspect before this
commit (and in MPlayer etc. too), the EOF flag wasn't handled
consistently when the stream position was at the end of the file.
Fix one special case in ebml.c and stream_skip(): this function couldn't
distinguish between at-EOF and past-EOF either.
This function was called in various places. Most time, it was used
before a seek. In other cases, the purpose was apparently resetting
the EOF flag. As far as I can see, this makes no sense anymore. At
least the stream_reset() calls paired with stream_seek() are completely
pointless. A seek will either seek inside the buffer (and reset the
EOF flag), or do an actual seek and reset all state.
This branch heavily refactors the subtitle code (both loading and
rendering), and adds support for a few new formats through FFmpeg.
We don't remove any of the old code yet. There are still some subtleties
related to subreader.c to be resolved: code page detection & conversion,
timing post-processing, UTF-16 subtitle support, support for the -subfps
option. Also, SRT reading and loading ASS via libass should be turned
into proper demuxers. (SRT is needed because Libav's is gravely broken,
and we want ASS loading via libass to cover full libass format support.
Both should be demuxers which are probed _before_ libavformat, so that
all subtitles can be loaded through the demuxer infrastructure, and
libavformat subtitles don't need to be treated in a special way.)
Before this, subtitle packets were returned as data ptr/len pairs, and
mplayer.c got the rest (pts and duration) directly from the demuxer
data structures. Then mplayer.c reassembled the packet data structure
again.
Pass packets directly instead. The mplayer.c side stays a bit awkward,
because the (now by default unused) DVD path keeps getting in the way.
In demux.c there's lots of weird stuff (3 functions that read packets,
really?), but we want to keep the code equivalent for now to avoid
hitting weird issues and corner cases.
Makes WebVTT actually work.
Also simplify the logic for setting duration. Only the subtitle path
uses the packet duration, so the checks for STREAM_SUB as well as the
keyframe flag are redundant.
Apparently duration and convergence_duration are the same thing, but
convergence_duration was added as Matroska-specific hack to get a higher
value range (int vs. int64_t) with high resolution Matroska timebases.
For us it doesn't matter, because double floats are used for timestamps
and durations.
This means subassconvert.c is split in sd_srt.c and sd_microdvd.c. Now
this code is involved in the sub conversion chain like sd_movtext is.
The invocation of the converter in sd_ass.c is removed.
This requires some other changes to make the new sub converter code work
with loading external subtitles. Until now, subtitles loaded via
subreader.c was assumed to be in plaintext, or for some formats, in ASS
(except in -no-ass mode). Then these were added to an ASS_Track. Change
this so that subtitles are always in their original format (as far as
decoders/converters for them are available), and turn every sub event
read by subreader.c as packet to the dec_sub.c subtitle chain.
This removes differences between external/demuxed and -ass/-no-ass code
paths further.
Internally, stream_dvd.c returned DEMUXER_TYPE_MPEG_PS, and the same
value was hardcoded to enforced usage of demux_lavf in demux.c. But
"-demuxer mpegps" basically did the same, so that switch was broken
for this format. Undo this and don't request a demuxer in stream_dvd.c.
demux_lavf.c is (probably) good enough to probe correctly with DVD.
Otherwise, we'd actually have to do something completely different to
force the libavformat demuxer.
Make the sub decoder stuff independent from sh_sub (except for
initialization of course). Sub decoders now access a struct sd only,
instead of getting access to sh_sub. The glue code in dec_sub.c is
similarily independent from osd.
Some simplifications are made. For example, the switch_id stuff is
unneeded: the frontend code just has to make sure to call osd_changed()
any time subtitles are switched.
This is also preparation for introducing subtitle converters. It's much
cleaner to completely separate demuxer header/renderer glue/decoders
for this purpose, especially since sub converters might completely
change how demuxer headers have to be interpreted.
Also pass data as demux_packets. Currently, this doesn't help much, but
libavcodec converters might need scary stuff like packet side data, so
it's perhaps better to go with passing packets.
Subtitle files are opened in mplayer.c, not using the demuxer
infrastructure in general. Pretend that this is not the case (outside of
the loading code) by opening a pseudo demuxer that does nothing. One
advantage is that the initialization code is now the same, and there's
no confusion about what the difference between track->stream,
track->sh_sub and mpctx->sh_sub is supposed to be.
This is a bit stupid, and it would be much better if there were proper
subtitle demuxers (there are many in recent FFmpeg, but not Libav). So
for now this is just a transition to a more proper architecture. Look
at demux_sub like an artifical limb: it's ugly, but don't hate it - it
helps you to get on with your life.
This unifies the subtitle rendering path. Now all subtitle rendering
goes through sd_ass.c/sd_lavc.c/sd_spu.c.
Before that commit, the spudec.h functions were used directly in
mplayer.c, which introduced many special cases. Add sd_spu.c, which is
just a small wrapper connecting the new subtitle render API with the
dusty old vobsub decoder in spudec.c.
One detail that changes is that we always pass the palette as extra
data, instead of passing the libdvdread palette as pointer to spudec
directly. This is a bit roundabout, but actually makes the code simpler
and more elegant: the difference between DVD and non-DVD dvdsubs is
reduced.
Ideally, we would just delete spudec.c and use libavcodec's DVD sub
decoder. However, DVD playback with demux_mpg produces packets
incompatible to lavc. There are incompatibilities the other way around
as well: packets from libavformat's vobsub demuxer are incompatible to
spudec.c. So we define a new subtitle codec name for demux_mpg subs,
"dvd_subtitle_mpg", which only sd_spu can decode.
There is actually code in spudec.c to "assemble" fragments into complete
packets, but using the whole spudec.c is easier than trying to move this
code into demux_mpg to fix subtitle packets.
As additional complication, Libav 9.x can't decode DVD subs correctly,
so use sd_spu in that case as well.
The new wavpack packet format (see previous commit) doesn't work with
older libavcodec versions, so disable the new code in this case.
The version numbers are only approximate, since the libavcodec version
wasn't bumped with the wavpack change, but it's close enough.
Libav introduced a silent API breakage by changing what wavpack packets
the libavcodec decoder accepts. Originally the libavcodec codec accepted
Matroska-style wavpack packets. Libav commit 9b6f47c removed this
capability from the libavcodec code, and added code to libavformat's
Matroska demuxer to "rearrange" wavpack packets. Since demux_mkv still
sent Matroska-style packets, playback failed.
Fix this by "rearranging" packets in demux_mkv as well by copying
libavformat's code. (The best kind of fix.)
Tested with [CCCP]_Mega_Lossless_Audio_Test.mkv, as well as with a
sample generated by mkvmerge.
The core deselected all streams on initialization, and then selected the
streams it actually wanted. This was no problem for
demux_mkv/demux_lavf, but old demuxers (like demux_asf) could lose some
packets. The problem is that these demuxers can buffer some data on
initialization, which then is flushed on track switching. Fix this by
explicitly avoiding deselecting a wanted stream.
When AAC is streamed over HTTP, using libavformat defaults is
pathetically slow. One solution for that is skipping probing and using
the mimetype to identify that it's AAC instead. This is what we did
before this commit (and ffmpeg does it too, but their logic is too
"inaccessible" for mpv).
This is still pretty fragile though. Make it a bit more robust by
requiring minimal probing. A probescore of 25 is reached after feeding
2 KB to libavformat (instead of > 500 KB for the normal probescore), so
use that. This is done only when streaming AAC from HTTP to reduce the
possibility of weird breakages for other formats.
Also reduce analyzeduration. The default analyzeduration will make
libavformat read lots of data, which makes playback start slow. So we
set analyzeduration to a low value. On the other hand, doing that for
other formats is risky, because there are unspecified effects with
certain "strange" formats (like transport streams). So we do this only
if we're streaming AAC from HTTP as well.
tl;dr libavformat is shit for media players
This can control whether demux_lavf should use the HTTP mime type to
determine the format, instead of probing the data with the libavformat
API. Do this to allow easier debugging in case the mimetype is
incorrect. (This is done only for AAC streams right now.)
Playing Youtube videos often requires an additional seek to the end of
the file. This flushes the stream cache. The reason for the seek is
reading the cues (seek index). This poses the question why Google is
muxing its files in such a way, since nothing in Matroska mandates that
cues are located at the end of the file, but we want to handle this
situation better anyway.
The seek index is not needed for normal playback, only for seeking.
This commit changes header parsing such that the index is not read on
initialization in order to avoid the additional stream-level seek.
Instead, read the index on the first demuxer-level seek, when the seek
index is actually needed.
If the cues are at the beginning of the file, they are read immediately
as part of the normal header reading process. This commit changes
behavior only if cues are outside of the header (i.e. not in the area
between EBML header and clusters), and linked by a SeekHead. Other
level 1 elements linked by the SeekHead might still cause seeks to the
end of the file, although that seems to be rare.
Before this commit, the demuxer would in theory accept multiple cues
elements (and append its contents to the index in the order as
encountered during reading). According to the Matroska specification,
there can be only one cues element in the segment, so this seems like
an overcomplication.
Change it so that redundant elements are ignored, like with all other
unique header elements. This makes implementing deferred reading of the
cues element easier.
The sequence of avcodec_alloc_context3() / avcodec_copy_context() /
avcodec_close() / av_free() leaks some memory. So don't copy the context
and use it directly.
Originally avcodec_copy_context() was used to guarantee that libavformat
can't update the fields of the context during demuxing in order to make
things a little more robust, but it's not strictly needed, and
ffmpeg/ffplay don't do this anyway. Still might make the situation worse
should we move demuxing into a separate thread, though.
Using -demuxer mpegts -correct-pts triggered the assertion in
ds_get_packet2(). This is not surprising, because the correct-pts code
was changed to accept _complete_ packets, while all the old demuxers
(including the mpegts demuxer) require you to use "partial" packet
reads, together with the video_read_frame(). (That function actually
parses video frames, so fragments of the original "packets" can be fed
to the decoder.)
However, it returns out demux_ts packet's are mostly useable. demux_ts
still adds an offset (i.e. ds->buffer_pos != 0) to the packets when
calling internal parser functions, such as in parse_es.c. While this is
unclean design due to mplayer's old video demuxing/decoding path, it can
be easily be made work by modifying the packet as returned by
ds_get_packet2(). We also have to change the packet freeing code, as
demux_packet->buffer doesn't have to point to the start of the memory
allocation anymore.
MPlayer handles this "correctly" because it doesn't have a function that
reads a complete packet.
Nobody uses this, and this is an absolute waste of time. Even the user
who reported this turned out to have produced a sample manually.
Sample produced with:
wget http://diracvideo.org/download/test-streams/raw/vts/vts.LD-8Mb.drc
mkvmerge -o dirac.mkv vts.LD-8Mb.drc
mkvmerge writes a sort of broken aspect ratio. libavformat interprets it
as 1:1 PAR, while demux_mkv thinks this is a 1:1 DAR. Maybe libavformat
is more correct here.
wm4
Stefano Pigozzi
Ben Boeckel
Benjamin Franzke