do whatever is best/necessary, this method will just drop cached data.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@31324 b3059339-0415-0410-9bf9-f77b7e298cf2
issue with PAFF seems solved to me, and disabled correct-pts causes
flickering with -ass (which of course should be fixed as well though).
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@31313 b3059339-0415-0410-9bf9-f77b7e298cf2
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 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.
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
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).
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
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
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.
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
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
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
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
Also make lavf the default demuxer for vqf.
Ok'ed by Compn on IRC.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@29655 b3059339-0415-0410-9bf9-f77b7e298cf2
can correctly display the languages of audio and subtitle tracks.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@29383 b3059339-0415-0410-9bf9-f77b7e298cf2
Currently "name" and "title" are both used at random, this makes it consistent.
"title" was chosen because it is less ambiguous and also the get_meta_title
slave mode command uses that (there is no get_meta_name command).
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@29330 b3059339-0415-0410-9bf9-f77b7e298cf2
demux_lavf interpreted absolute seeks as relative to the start of the
file, so if the file didn't start at timestamp 0 then seeking to
timestamp X went to a position MPlayer would display as start+X. Make
the seeks use the same timestamps as used in the original file. This
works better for most use cases as no part of MPlayer normally uses or
displays such "since start of file" timestamp values. There could be
some cases where the old semantics are useful, but I think they do not
justify making it the default behavior; a separate feature for that
could be added if it turns out to be needed.
When the new mode is active relative seeks are converted to absolute
ones (current video pts + relative seek amount) and forward/backward
flag before being sent to the demuxer. This mode is used if the
demuxer has set the accurate_seek field in the demuxer struct and
there is a video stream. At the moment the mkv and lavf demuxers
enable the flag.
This change is useful for later Matroska ordered chapter support (and
for more general timelime editing), but also fixes problems in
existing functionality. The main problem with the old mode, where
relative seeks are passed directly to the demuxer, is that the user
wants to seek relative to the currently displayed position but the
demuxer does not know what that position is. There can be an arbitrary
amount of buffering between the demuxer read position and what is
displayed on the screen. In some situations this makes small seeks
fail to move backward at all (especially visible at high playback
speed, when audio needs to be demuxed and decoded further ahead to
fill the output buffers after resampling).
Some container formats that can be used with the lavf demuxer do not
always have reliable timestamps that could be used for unambiguous
absolute seeking. However I made the demuxer always enable the new
mode because it already converted all seeks to absolute ones before
sending them to libavformat, so cases without reliable absolute seeks
were failing already and this should only improve the working cases.
Undo Aurelien's previous commit which made the lavf demuxer the
default. SSA/ASS subtitles do not work properly with the lavf demuxer
at the moment. That's much more important than any issues with the
internal demuxer. The internal demuxer must remain the default at least
until the subtitle issues are resolved.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@27556 b3059339-0415-0410-9bf9-f77b7e298cf2
Change the default demuxer back to the internal one at least until the
current lavf breakage with SSA/ASS subtitles is sorted out. There have
also been quite a few other regressions so maybe the lavf demuxer
should be tested a bit more before trying to make it the default again.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@27551 b3059339-0415-0410-9bf9-f77b7e298cf2
Some symbols were dropped or renamed, requiring corresponding changes
in MPlayer.
- Use AVCodecContext->bits_per_coded_sample instead of ->bits_per_sample.
- Use AVCodecContext->trellis instead of ->flags&CODEC_FLAG_TRELLIS_QUANT.
- Don't set AVCodecContext->rtp_mode (already marked unused before).
- Use ff_eval2() instead of ff_eval().
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@27548 b3059339-0415-0410-9bf9-f77b7e298cf2
I can't spot any regression anymore. If you find one, please tell me.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@27484 b3059339-0415-0410-9bf9-f77b7e298cf2
aurel
reimar
Uoti Urpala
diego
hyc
Anton Khirnov
cehoyos
vitor
greg
Amar Takhar
gpoirier
uau