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.
It seems that if there is no padding between packets then they actually belong to one subtitle picture.
The new hack seems to work far more reliable than the (already removed) old one.
Patch by Ubitux (gmail)
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@31104 b3059339-0415-0410-9bf9-f77b7e298cf2
libvo/video_out.c:461: warning: implicit declaration of function 'mp_input_queue_cmd'
libvo/video_out.c:461: warning: implicit declaration of function 'mp_input_parse_cmd'
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@31101 b3059339-0415-0410-9bf9-f77b7e298cf2
This svn commit is wrong in multiple ways. First, it doesn't actually
work; there's more than one functionality bug. Second, it's the wrong
overall approach. If FFmpeg continues to insist on mangling subtitles
to this badly-thought-out format and support for it is desired in
MPlayer then the right approach would be conversion to a saner format
in demux_lavf, instead of trying to handle the mangled format
elsewhere.
Due to inexact seeks, chapter seek commands may result in a playback
position that's inside the previous chapter. This causes problems when
the user does repeated next-chapter/previous-chapter seeks, because
the code will use the wrong base for calculating 'next' or
'previous'. Improve the behavior by adding a heuristic that keeps
track of what chapter the user last wanted to seek to and adjusts the
"current chapter" value based on that.
The code processing seek commands only sets/alters variables
specifying the current seek target. Before all queued commands were
processed first, and any needed seeks were executed after that. This
was somewhat unreliable, as commands queued later were not guaranteed
to see all the effects of earlier seek commands if they happened to be
processed in the same batch. Change the behavior so that processing
commands is interrupted and the real seek executed if the next command
is anything other than a basic seek. This guarantees that other
commands see a consistent state, while still allowing the combining of
consecutive seeks (which is useful for example when the user keeps the
seek-forward key pressed down, and key repeat is faster than seeks can
be executed).
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).
-chapter can optionally take a range with a start and an end. Add a
new option type which supports such values and use that instead of a
custom per-option function.
This commit also fixes a build configuration bug: before the
availability of the -chapter option depended on DVD functionality
being enabled in the binary, even though the option works with other
sources too.
Move code resetting various things after a seek into a separate
function and use that for chapter seeks too. In most cases this won't
change behavior because chapter seeks were already falling back to the
same time-based seek code.
For fullscreen, vo_screenwidth/vo_screenheight have to be set correctly still.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@31095 b3059339-0415-0410-9bf9-f77b7e298cf2
