Remove the "num_chapters" and "mode" parameters that aren't needed by
any callers. Change "float *seek_pts" to "double *". Allocate the
string returned via "chapter_name" with talloc.
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.
Firstly 32 MB is not that much with HD video and the different
values depending on whether CONFIG_TV_BSDBT848 is set or not
makes debugging harder.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28190 b3059339-0415-0410-9bf9-f77b7e298cf2
The hard limit on the amount of buffered bytes per demuxer stream had
not been increased since 2001. Since then there have been significant
increases in both video bitrates (so it's easier to hit the limit) and
typical memory available on a computer (so there's less reason to
limit the memory used for buffering). The 8 MiB limit was too easy to
hit in the case of high-bitrate video lagging behind audio, when the
file is demuxed ahead to get audio packets but video has to be
buffered until the decoder catches up to that point.
Increase the limit to 128 MiB and remove the #ifdef for
CONFIG_TV_BSDBT848 because the normal limit is now higher than the
increased value under the #ifdef.
Replace all USE_ prefixes by CONFIG_ prefixes to indicate
options which are configurable.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@27373 b3059339-0415-0410-9bf9-f77b7e298cf2
FF_INPUT_BUFFER_PADDING_SIZE.
Instead use MP_INPUT_BUFFER_PADDING_SIZE and add a preprocessor check that it
is big enough.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@27314 b3059339-0415-0410-9bf9-f77b7e298cf2
Remove some #include lines from headers, some of those removals made
possible by using incomplete struct types instead of typedefs. Include
mp_osd.h in mplayer.c and command.c after removing it from mp_core.h.
Remove "#ifdef USE_ASS" around some "struct ass_track_s *" fields
which will now compile even without ASS support.
Give sh_audio_t, sh_video_t and sh_sub_t which before had typedef
names only a matching struct name (without _t) too.
Change the a_streams, v_streams and s_streams demuxer fields from
void * to struct sh_audio *, struct sh_video * and struct sh_sub *.
Remove a now unnecessary cast from mplayer.c.
According to VCS history this function has never been used since it
was added in 2001...
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@26401 b3059339-0415-0410-9bf9-f77b7e298cf2
The first default track is chosen for playback if language-based selection
failes. Additionally, for audio tracks, the first one is chosen if there are
no default tracks at all.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@26301 b3059339-0415-0410-9bf9-f77b7e298cf2
If it's != MP_NOPTS_VALUE ds_fill_buffer() will keep
on demuxing until the pts of the next_pts is <= reference_clock.
It guarantees the compliance with the buffering model indicated
by the transmitter of the multiplex and a long-time stability
of playback (at least for me).
In any case up to a maximum of 64 packets are accumulated to prevent
memory hogging and leaks.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@26069 b3059339-0415-0410-9bf9-f77b7e298cf2
I did not see anything obvious that would break, it if it does it should be
fixed properly once and for all.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@25988 b3059339-0415-0410-9bf9-f77b7e298cf2
A better solution should be considered later, esp. for the many
broken demuxers that do not treat these flags correctly.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@25911 b3059339-0415-0410-9bf9-f77b7e298cf2
The "#ifndef __DEMUXER_H" / "#endif" pair did not cover the whole file.
Move the #endif to the last line.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@23591 b3059339-0415-0410-9bf9-f77b7e298cf2
before our native demuxers and remove some now unneeded file-extension
hacks.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@22989 b3059339-0415-0410-9bf9-f77b7e298cf2
This mode has the following differences:
- Video timing is correct for streams with B frames, at least with some
demuxers.
- Video filters can modify frame timestamps and insert new frames, and
removing frames is handled better than before.
- Some things are known to break, it's not usable as the default yet.
Things should work as before when the -correct-pts option is not used.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@18922 b3059339-0415-0410-9bf9-f77b7e298cf2
audio decoded with ad_libvorbis, ad_ffmpeg and ad_faad.
Patch by Uoti Urpala
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@18243 b3059339-0415-0410-9bf9-f77b7e298cf2
make it available in more files (needed for next patch).
Patch by Uoti Urpala
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@18242 b3059339-0415-0410-9bf9-f77b7e298cf2
1. Include audio_delay as an argument to demux_seek.
2. Modify demux_seek_avi to adjust the audio/video stream positions so
that mplayer/mencoder will instantly be in sync even when -delay is
specified.
I've quadruple checked this time; hopefully I haven't missed anything.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@17637 b3059339-0415-0410-9bf9-f77b7e298cf2
2. Modify demux_seek_avi to adjust the audio/video stream positions so
that mplayer/mencoder will instantly be in sync even when -delay is
specified.
Other demuxers could be modified similarly in the future.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@17554 b3059339-0415-0410-9bf9-f77b7e298cf2
accuracey may be totally fake for some demuxers (mpg), but accurate for
others.. (avi)
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@16347 b3059339-0415-0410-9bf9-f77b7e298cf2
Demuxer selection by name with -demuxer command (bakward compatible)
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@16176 b3059339-0415-0410-9bf9-f77b7e298cf2
Patch by Michael Behrisch < behrisch $ informatik * hu-berlin * de >
commited with the kind blessing of D. Richard Felker III
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@15047 b3059339-0415-0410-9bf9-f77b7e298cf2
that works with signle image in single file.
removing is part of vu1nerabi1ity fix.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@14161 b3059339-0415-0410-9bf9-f77b7e298cf2
diego
Uoti Urpala
reimar
compn
Uoti Urpala
nicodvb
uau
eugeni
ulion
lu_zero
zuxy
ods15
reynaldo
rtogni
rtognimp
corey
henry
gpoirier
faust3
iive
joey