summaryrefslogtreecommitdiffstats
path: root/DOCS/mplayer.1
diff options
context:
space:
mode:
authorarpi <arpi@b3059339-0415-0410-9bf9-f77b7e298cf2>2002-10-15 00:47:17 +0000
committerarpi <arpi@b3059339-0415-0410-9bf9-f77b7e298cf2>2002-10-15 00:47:17 +0000
commitd25af23a40d9b0cc98216106638ba2035ab8a3af (patch)
tree8fb6caae46070317e5dead050f9ac7ae5577f7f6 /DOCS/mplayer.1
parent0f27e7deafff2c6c4c91d2a7db590f797421cad1 (diff)
downloadmpv-d25af23a40d9b0cc98216106638ba2035ab8a3af.tar.bz2
mpv-d25af23a40d9b0cc98216106638ba2035ab8a3af.tar.xz
All right: The patch adresses two issues which I found, when I analyzed
the input from some DVDs with known subtitle-dropouts: 1. The packet-size at the beginning of the packet, which is used to check, whether we got all fragments, is sometimes one byte too long. It seems to be always padded to an even number, while the actual size can be odd. 2. The original algorythm used to assemble the fragments relies on the timestamps to check, whether a new packet begins. This has proven to be unrelieable on some disks. So instead, I use the timestamp only to check, whether it's been too long (defined as 0,01sec) since the last fragment, which is probably indicating a broken packet, and normaly starting a new packet when the last one has been finished. patch by Christof Buergi <christof@buergi.lugs.ch> git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@7744 b3059339-0415-0410-9bf9-f77b7e298cf2
Diffstat (limited to 'DOCS/mplayer.1')
0 files changed, 0 insertions, 0 deletions