| Age | Commit message (Collapse) | Author |
|---|
|
Pt. 3: does not see these are protected by trak == NULL already :-/
|
|
|
|
This is an ISO extension, and even they dont recommend
breaking some players with it. In other words:
I have no file for testing.
|
|
|
|
|
|
|
|
Eliminate 5 temporary tables.
Fix compressed CBR audio (a52).
Add lots of table size guards.
Optimize.
|
|
|
|
No more byte scanning the entire atom,
what was slow and gave room for misinterpretations.
BTW. The diff looks worse than it is ;-)
|
|
|
|
|
|
Follow ISO 14496-12 (2005).
|
|
Dont hang when user seeks behind the end of audio while there is
still some video left.
|
|
BTW. Happy 2014 to you!
Didnt think xine will survive this far :-)
And yes, I finally got an ffmpeg patch through. That kind of rounds the circle :-)
|
|
|
|
That is, when "data" does not immediately follow "fmt ".
|
|
|
|
|
|
|
|
|
|
Read: fix misleading frontend audio selector list.
|
|
Long overdue I think.
To do: provide language info.
|
|
Flood log only when requested.
|
|
cook audio frames are fairly long (almost 2 seconds). For obfuscation
purposes, they are sent as multiple fragments in intentionally wrong order.
The first sent fragment has the timestamp for the whole frame.
Sometimes, the remaining fragments carry fake timestamps interpolated across
the frame duration. Let's be careful not to trap metronom into a big lag.
|
|
Metronom does not strictly follow audio pts. They usually are too coarse
for seamless playback. Instead, it takes the latest discontinuity as a
starting point. This can lead to terrible lags for our very long audio frames
(nearly 2" for cook). So let's make sure audio has the last word here.
|
|
|
|
Dont try to guess reordering scheme in demuxer.
Just pass proper pts, and let the decoder reorder them along with the frame,
like ff already does.
|
|
|
|
|
|
Works at least with dvb stuff.
|
|
|
|
(was duplicated when the function was splitted in 2004 ...)
|
|
(was broken in merge commit 5 years ago)
detected with valgrind (branch condition depends on uninitialized data)
|
|
|
|
(there won't be any more data -> no pusi -> last buffer is never flushed)
|
|
|
|
asfheader.c is used in two places: same compiler flags, so is safe.
|
|
script execution time: 55"
|
|
Why?
I use FLV a lot for editing. It is simple, and it is playable while writing.
However, seeking was often terribly slow or non working. Reordered video
(most h.264) also yielded some nasty unpredictable a/v lag, making music
videos not much fun.
And there are quite a few FLV files out there that do not follow all the
standards. The flash browser plugin plays them normally, but xine liked to
show strange malfunctions such as video collapsed to a horizontal line, or
even crashed.
How?
This is the first file I ever edited in xine-lib. I started years ago, and
I did not keep track of all the intermediate states.
So please apoplogize me pushing all in one go. It wont happen again.
Promised.
What?
* Overrun-safe iterative metainfo parser that tolerates at least most of
the trash left by various "injector tools".
* Skip obviously truncated tags.
* Try to find the reliable settings in contradiction.
* Send pts not dts for reordered (b-framed) video.
* Large file support >= 2Gb on 32bit systems.
* Fast time-based seek routine for files with working, damaged and no
keyframe index.
* Major optimizations. Less reads, and a lot less seeks.
* More codecs.
|
|
|
|
Append sequence end code to video stream at end of stream
|
|
|
|
|
|
|
|
|
|
|
|
|
|
--HG--
rename : src/libfaad/xine_faad_decoder.c => src/audio_dec/xine_faad_decoder.c
|
|
|
|
discontinuity is not detected with short streams.
_x_demux_control_start() is not enough; BUF_CONTROL_START in
decoders skips discontinuity indication when gapless switch is in use.
|
