If you want this, fix the implementation to not crash at least occasionally,
or wait till I get bored enough to fix it.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@25918 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 code calculated the pts values of audio packets by adding the length
of the current packet to the pts of the previous one. The length of the
previous packet should be added instead. This broke WAV timestamps near
the end of the stream where a short packet occurs.
Change the code to store the pts of the next packet instead of the last
one. This fixes the WAV timestamps and allows some simplifications.
MP3 timestamps are not affected as packets are always treated as
constant decoded length, and FLAC timestamps still have worse problems
(FLAC is treated as as if it was constant bitrate even though it isn't).
Also store the timestamps as double instead of float.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@24609 b3059339-0415-0410-9bf9-f77b7e298cf2
(same as new_sh_audio()) instead of sh_audio_t *, use those to remove
the pointer from demuxer->a_streams[] before freeing it.
Some demuxers use free_sh_audio() to undo the creation of an
already-allocated audio stream in case of error. These uses were unsafe
since free_sh_audio() freed the data structure but left the pointer in
demuxer->a_streams[], leading to double free later in free_demuxer()
(and perhaps use of the freed stream before that, I didn't check).
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@18711 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
Also adds a check if stream_read read the requested length.
This and the movi_end check on error help not accidently playing ID3 tags.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@16439 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
basically demux_audio was mixing data in its header buffer in a bogus
manner, whereby it could sometimes "make up" valid mpeg headers where
no such header actually occurred in the file. it should be correct now.
btw these changes also fix the bug where mplayer reports huge initial
cpu usage for sound when playing mp3 files.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@15206 b3059339-0415-0410-9bf9-f77b7e298cf2
-hr-mp3-seek bug (pts was -inf after seeking) and remove the workaround
from demux_audio.c.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@13358 b3059339-0415-0410-9bf9-f77b7e298cf2
ever infinite?!?!) but at least it makes it work... :)
patch by Balazs KOSSOVICS (tevefeju AT freemail.hu):
Hi!
When we listening music with "-hr-mp3-seek" option, than there is a
negative value at the first rewinds in the statusrange (-52 hours, some
minutes). The patch is against this.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@13257 b3059339-0415-0410-9bf9-f77b7e298cf2
Patch by Aurelien Jacobs ( aurel at gnuage dot org )
dts in wav by me
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@13007 b3059339-0415-0410-9bf9-f77b7e298cf2