libmpdemux/demux_mkv.c:1873: warning: pointer of type 'void *' used in arithmetic
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@31276 b3059339-0415-0410-9bf9-f77b7e298cf2
Change 'struct vf_instance' pointer arguments to more standard style
as in the subject. Also some other minor formatting fixes.
Patch by Diego Biurrun.
This has the side-effect of using fftheora by default instead of
theora, which possibly should be changed.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@31225 b3059339-0415-0410-9bf9-f77b7e298cf2
The code handling larger-than-minimum realvideo extradata sizes was
complete nonsense. It tried to add the additional data to the exported
track extradata by reading data from the input stream, which was
completely bogus as this code is called long after the original
Matroska track extradata information has been read. As a result the
data read had nothing to do with correct values, and the read call
messed up the stream position which likely broke further parsing of
the file and caused complete playback failure. Change the code to
instead copy any additional part at the end of input extradata to the
end of output extradata. I believe this is the intended semantics,
though I haven't verified it from any specs.
Commit fc39d48465 ("demux_mkv: store streams sequentially in
demuxer->[avs]_streams") had a simple bug in automatic stream
selection causing a crash if no video or audio track was marked as
'default'. Fix.
Allow audio stream switching to turn off sound or enable it, and also
include nosound as one of the values cycled through when stepping to
the next audio stream.
demux_mkv used the Matroska TrackNumber as the array offset in demuxer
stream lists. The TrackNumber entry stored in the file can be an
arbitrary 64-bit value, and some of the code could try reading from
the arrays with that offset, causing a crash if the file had insane
values. Fill the arrays sequentially instead. Also add some checks to
make the handling of too high stream counts more robust.
The handling of audio stream numbering was handled in the stream
selection property was a total mess. The most important issue was
confusion between values used as index for demuxer->audio_streams[]
array (consistently stored in demuxer->audio->id) and values stored
in sh_audio->aid and used as "-aid N" option values. Now demuxer audio
switch control functions and demuxer_switch_audio() are supposed to
return the new value for the "-aid" option (internal MPEG demuxers
still don't; the demuxer requirement could perhaps be dropped as it
can be easily calculated afterwards). That is also the value
returned for the "switch_audio" property. The main changes are:
- Make command.c mp_property_audio() consistently use and return the
"-aid" values. Before it used that as input but the array index as
output, with extra mess related to demuxer_switch_audio() return
value. Don't modify the audio_id option field any more.
- Make demuxer_switch_audio() always return "-aid" values (like it
takes as input). There are two changes for this: picking this
return value in case the demuxer doesn't support switching, and
overriding demuxer return value (for internal MPEG demuxers).
- Make demux_lavf return "-aid" values from DEMUXER_CTRL_SWITCH_AUDIO
code. This isn't actually necessary because of the override part
above.
Here's some history of the relevant behavior that I looked up:
* For most demuxers array index and "-aid" values are the same. At
least demux_mkv, (some of?) the internal MPEG demuxers and demux_ogg
have differed for a long time. demux_ogg doesn't matter because it
doesn't support stream switching.
* Old code seemed to assume that demuxer_switch_audio() return value was
array index, but this wasn't true at least for demux_mkv.
* In svn r19951 reimar mostly removed use of the return value.
* In r20162 ptt added mp_property_audio(). This set the global
audio_id variable (-aid option value) to the return value of
demuxer_switch_audio() and treated the global as the persistent
value of the property, apparently assuming that it would be set to
the "-aid" value, not array index. This was false for internal
MPEG.
* In r30124 reimar changed the property code so that even though it
still modified the option value it didn't use that as the value of
the property any more; instead it incorrectly used the array index.
This meant that for demux_mkv the return value didn't match -aid any
more (though input still did, so setting the property and querying
it didn't match as they used different value systems).
* In r31129 aurel made demux_lavf changes that resulted in its -aid
and array index values no longer matching either. He didn't change
the return value from audio switch when changing -aid, so it now
matched array index only. The latter part didn't cause additional
problems from r20162 though because either choice would have been
broken anyway after r30124 as long as they weren't the same value.
The option field corresponding to -slang is now called "sub_lang"
instead of the old misleading global name "dvdsub_lang". The code
handling -slang in subreader.c looks rather broken; disable it instead
of converting it to use the option field.
Move "struct bstr" definition from ebml.h to its own header and add
some utility functions/macros. Change length field type from int to
size_t and adjust using code accordingly.
Partially based on a patch from Anton Khirnov.
Nowadays FFmpeg is faster than liba52 and external liba52 is well supported.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@31147 b3059339-0415-0410-9bf9-f77b7e298cf2
libmpdemux/muxer_mpeg.c:2121: warning: implicit declaration of function 'a52_syncinfo'
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@31146 b3059339-0415-0410-9bf9-f77b7e298cf2
aid and vid are now 0-based, instead of being a globally unique id.
This matches the way sid is handled and the way other demuxers manage aid.
As a side effect, it slightly simplifies demux_lavf.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@31129 b3059339-0415-0410-9bf9-f77b7e298cf2
Playback of nonseekable y4m streams was broken by a change merged from
svn, r30970 which added support for multiple yuv4mpeg files
concatenated together. The change included a stream_skip(stream, -1)
call which only works for seekable files. Work around this by
disabling the concatenated-file check for nonseekable streams. This
means concatenated files are only supported if the stream is seekable,
but this is an improvement compared to the svn commit which caused a
regression making _all_ files fail in the nonseekable case.
It would be reasonably easy to make the concatenation support work in
all cases, either by modifying demux_y4m or (probably better) adding a
general stream API to allow pushing back the read byte. However for
now I'm only fixing the regression with the above trivial change.
Before "-chapter 1" did nothing even if the first chapter didn't start
at the beginning of file. Fix it.
Before all chapter property commands (including chapter seek keys)
failed if the current playback position was before the start of the
first chapter. Now they'll work. Relative chapter seeks will go to the
first chapter (even if that's in the wrong direction for backward
seeks).
Use lavf's flv demuxer for rtmp/rtmps/... stream types. Letting
generic format probing handle this could work, but with the current
probing implementation it'd at least depend on not-really-guaranteed
details of the stream layer (probing different formats and then
decoding depends on seeking back in between; rtmp streams don't
support such seeking directly so would need to rely on details of
caching behavior).
Only try to use the dvd/dvdnav stream seek hack with those stream
types. Generally demuxers can not be expected to cope with the stream
suddenly seeking under them. In principle it would be more correct to
make the test demuxer-based (instead of assuming that using stream
seeks in this manner is OK with whatever demuxer that will be used
with these streams), but that'd be more work.
Move code for resetting decoders after seeks, chapter seeks and angle
changes out of demuxer.c. This functionality belongs on a higher
level; the demux layer can't always know what kind of reinitialization
is required.
to restart without seeking even without cache for easily detectable formats.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@30946 b3059339-0415-0410-9bf9-f77b7e298cf2
Convert demux_mkv_decode() to allocate possible new storage with
talloc and fix a talloc/malloc conflict in demux_mkv_open_sub() that
broke decoding of files which had a subtitle track with compressed
private data.
Fixes elementary streams with -vc ffodivxvdpau and the native demuxer.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@30904 b3059339-0415-0410-9bf9-f77b7e298cf2
FFmpeg increased the amount of padding that must be readable beyond
input buffers without SIGSEGV from 8 to 64, and the MPlayer value must
be changed accordingly.
Tweak some code parts that used to rely on string literals from
translation macros being concatenated with other adjacent string
literals. Break up the resulting string into independently translated
parts, so that the existing translations for those parts can still be
used.
For some reason commit e306174952, which
replaced translation macro names with the corresponding English
strings, also collapsed multiple consecutive space characters into
one. Change most of these back. In a couple of cases the amount of
whitespace is important for alignment, and for the rest it at least
keeps the strings closer to the existing translations.
These functions return void*, which is compatible with any pointer,
so there is no need for casts.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@30744 b3059339-0415-0410-9bf9-f77b7e298cf2
-identify still does not show the right values though.
Fixes bug #1636.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@30681 b3059339-0415-0410-9bf9-f77b7e298cf2
format autodetection with -nocache and non-seekable streams.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@30668 b3059339-0415-0410-9bf9-f77b7e298cf2
This ensures that function declarations in both files always match.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@30596 b3059339-0415-0410-9bf9-f77b7e298cf2
This will read progressively more data if we still did not detect
the format. The lavfpref demuxer is unaffected to avoid hanging
for a long time in case of a slow network stream that some native
demuxer may be able to handle.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@30547 b3059339-0415-0410-9bf9-f77b7e298cf2
Add support for compression algorithm 3 (header stripping). Rewrite
some of the code related to handling manyfold compression, it was just
completely broken (I don't have samples to test whether it actually
works now).
The decompression step wasn't run at all for subtitle types other than
vobsub. Fix that. Remove a "!mkv_d->v_skip_to_keyframe" test from the
subtitle handling - for properly timed subtitles unnecessary packets
do little harm, and the subtitles could stay visible.
Allow decoding a 0-sized buffer with zlib algorithm to produce 0-sized
output. Fixes spurious errors reported with subtitle tracks marked to
use compression for track private data without having any such data.
Change the demuxer_add_attachment() and demuxer_add_chapter()
functions to take a length argument for various name strings, so those
strings do not need to be 0-terminated. This will make it easier to
directly pass demuxed data without first making a copy just to add
0-termination. Also allocate the struct demuxer data structures for
attachments and chapters with talloc.
The main demuxing code signaled EOF and stopped playback if it hit a
top-level element other than Cluster. There are files with other
elements between Cluster ones, at least repeated copies of Track
headers. Change the code to skip any non-Cluster element and only stop
searching on real file EOF.
Rewrite Cues parsing code using the new EBML parser. The new version
fixes a hang in some cases of incomplete files and supports a cuepoint
specifying multiple tracks per timecode (the previous code added an
index entry for the track mentioned last only).
Restructure the code reading toplevel header elements and rewrite the
SeekHead parsing code using the new EBML parser. Now every type of
header element is read anywhere in the file if there's a SeekHead
entry pointing to it. The new SeekHead parsing code has more
diagnostic output in case of errors.
Add a new EBML parser implementation that should allow significant
improvements to the Matroska demuxer. The new parsing code is not
actually used yet by the demuxer. The only changes to existing code in
this commit are to generate the MATROSKA_ID_* / EBML_ID_* macro
definitions from the new implementation and to rename some of them
(the new implementation uses names matching the official Matroska spec).
The main parser implementation is added in ebml.c. There are two new
generated files, ebml_defs.c and ebml_types.h, that contain
definitions of EBML elements. Those are generated by the new script
TOOLS/matroska.py. There's a new Makefile target "generated_ebml" that
run the script to refresh the content of the generated files.
the ASF demuxer (seek seems to end up right after the keyframe?) and seem to have
no purpose anyway.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@30438 b3059339-0415-0410-9bf9-f77b7e298cf2
This is necessary to use the ffmp2 decoder with dvr-ms files.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@30437 b3059339-0415-0410-9bf9-f77b7e298cf2
based only on substream id.
Works with all available DTS and TrueHD samples available (2 each).
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@30429 b3059339-0415-0410-9bf9-f77b7e298cf2
AC3 is still broken due to the libavcodec parser being broken.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@30421 b3059339-0415-0410-9bf9-f77b7e298cf2
scattered all over the place with half of it forgotten in some places.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@30420 b3059339-0415-0410-9bf9-f77b7e298cf2
not be used without a declaration, causing issues on 64 bit systems.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@30355 b3059339-0415-0410-9bf9-f77b7e298cf2
When using generated index (-idx / -forceidx) the Matroska seeking
code first guessed a file position using bitrate-based heuristics,
then located the cluster nearest to that file position. Change it to
store cluster timestamps in addition to file positions and seek to the
cluster with the closest timestamp. This makes seeking with -idx a lot
more accurate.
This change also fixes a crash when trying to seek with generated
index before playing any data from the beginning of the file (could be
triggered by -idx together with ordered chapters or -ss for example).
I removed the code handling MATROSKA_ID_CUES in the middle of parsing
clusters. Such cue entries were not consistently handled if
encountered during playback instead of index creation and the seek
code was also buggy when they were encountered and parsed; i didn't
consider it worth the effort to fix it.
via libavcodec.
Parsing can be done at the demuxer stage (currently disabled) or at the decoder
(ad_ffmpeg, enabled).
Should allow using the libavcodec AAC, DTS, ... decoders independent of container
format.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@30130 b3059339-0415-0410-9bf9-f77b7e298cf2
and sub "stream headers".
One reason for this is to help avoid/make more obvious things like members with
the same function but different name (extradata vs. codecdata etc.), or members
with the same name but different semantics (pts for audio vs. pts for video).
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@30128 b3059339-0415-0410-9bf9-f77b7e298cf2
in the lavf preferred_list, and thus will be handled by lavf immediately.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@30111 b3059339-0415-0410-9bf9-f77b7e298cf2
variable instead.
should fix seeking after starting playback with -force-idx broken by
r29914.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@30052 b3059339-0415-0410-9bf9-f77b7e298cf2
Some code used an invalid '%lf' conversion specification for double
arguments. Maybe they were written that way due to confusion with
scanf where doubles are indicated by '%lf'; however it is not a valid
printf format specifier. Change those cases to use '%f'.
Add code to intelligently choose an appropriate Matroska edition when
there are several. Will choose, in descending order of preference: the
edition chosen by the user through the option "-edition <edition id>"
if it exists, the first edition with EditionFlagDefault set to 1 if
there is one, or the first edition.
Detect use of ChapterSegmentEditionUID element in a Matroska chapter
definition, indicating inclusion of an external virtual timeline,
which is not yet supported. Leave the chapter is the chapter list but
set segment_uid to zero. This way timeline parsing will skip the
chapter and avoid nonsensical output but will still print information
about missing content.
name clashes, in particular with Windows headers (which define STREAM_SEEK as an enum type).
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@29962 b3059339-0415-0410-9bf9-f77b7e298cf2
Add a mode where libavcodec's reordered_opaque feature is used to
associate container packet timestamps with decoded frames. This should
improve behavior at least for MPEG files with interlaced h264; the
previous code does not cope well with the libavformat demuxer
producing two field packets with separate timestamps but the
libavcodec h264 decoder only producing a single output frame for those
two packets (so half the timestamps have no associated output frame).
The current libavformat mpeg demuxer seems to finally work with
interlaced h264 files and produce valid timestamps which are useful
with a mode like this.
By default MPlayer now selects between this new mode and the old one
automatically based on the number of timestamp problems they cause; by
default the new mode is used if both seem to work. The new option
-pts-association-mode can be used to force a particular mode. If
correct-pts mode is disabled this has no effect on timing.
Also remove the "EXPERIMENTAL" marker from the manpage description of
-correct-pts.
This patch hopefully makes them playable as long as they have and index without
breaking any other files.
Fixes http://samples.mplayerhq.hu/avi/invalid_unaligned.avi with native demuxer.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@29913 b3059339-0415-0410-9bf9-f77b7e298cf2
from lavf demuxer, mplayer.c makes sure IDENTIFY_PROGRAM is called with the
right arguments, and that code actually works in contrast to the one in demux_open_lavf.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@29847 b3059339-0415-0410-9bf9-f77b7e298cf2
instead of incorrectly claiming that the demuxer does not support programs.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@29845 b3059339-0415-0410-9bf9-f77b7e298cf2
Reimar's previous commit ("Unbreak the demuxer-specific code in
video.c with e.g.") added the new field "non_interleaved" in
demux_stream structs, but this field was not initialized anywhere.
Under suitable circumstances this could cause a "Too many
video/audio packets in the buffer" error and failing playback. Fix
the problem by cleaning up the code that creates new instances of the
struct. Now fields will be initialized to 0 by default.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@29812 b3059339-0415-0410-9bf9-f77b7e298cf2
-audiofile by moving the code to manually interleave
subtitles to mp_common.c.
video.c should still be changed to not be demuxer-specific
anymore, it is bad practice but fully fixing it is non-trivial.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@29810 b3059339-0415-0410-9bf9-f77b7e298cf2
The Matroska demuxer didn't place FLAC codec extradata in the normal
extradata field but instead constructed a fake data packet and inserted
that at the start of the demuxer stream. Current FFmpeg FLAC decoder
can read the data from the proper extradata field too, so use that
mechanism instead.
This fixes a problem with files that use ordered chapters to load
external segments from other files that have FLAC audio. In that case
there can be a seek before the audio decoder is first initialized, and
the seek will flush all stream packets so the decoder would never see
the inserted extra packet. That particular issue could be fixed by
initializing the decoder before any seeks instead (and there could
still be other similar problem cases where doing that would be more
robust), but this change is still generally right. I think the
previous code would also cause problems in case there are multiple
audio streams; there's only a single demuxer stream used for data
packets, meaning that a packet inserted for the sake of a secondary
audio stream could be read by the codec of the default stream
(possibly not FLAC at all) and the packet would not be available when
switching to the secondary audio stream later.
This also makes the demuxing function set the keyframe flag for
vorbis packets that aren't header packets and have a time stamp,
even if we do not have vorbis_info struct yet.
The reason for this is that header packets always have 0 as time stamp.
Fixes bug #1585
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@29776 b3059339-0415-0410-9bf9-f77b7e298cf2
As part of merging subtitle-in-terminal changes make
update_subtitles() only clear existing subtitles if called with the
reset argument, and not try to set new ones. Later calls should set
the needed new subtitles, and this change avoids some problems with
trying to set subtitles when mp_property_sub() in command.c gets
called from initialization code before full initialization.
otherwise we might end up at some random position (where lavf last ended
up while trying to build the index).
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@29741 b3059339-0415-0410-9bf9-f77b7e298cf2
violation (thus making gcc 4.4.x compile the code correctly) and allows to get
rid of some casts at the expense of making the code less clear.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@29733 b3059339-0415-0410-9bf9-f77b7e298cf2
When the attachment-reading code was changed to use
demuxer_add_attachment it should have been changed to free its
internally-allocated objects too, since demuxer_add_attachment creates
copies of everything and leaves ownership of original objects to
caller.
ds->demuxer.
This makes it also work again with -audiofile without having to add more hacks to
demux_demuxers.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@29677 b3059339-0415-0410-9bf9-f77b7e298cf2
claims the Wave64 files but can not handle them).
Patch by Daniel Verkamp [daniel drv nu].
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@29668 b3059339-0415-0410-9bf9-f77b7e298cf2
