Otherwise subtitles will stay on screen forever for ASS subtitles in
mkv if no ASS renderer is used.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@32032 b3059339-0415-0410-9bf9-f77b7e298cf2
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.