aboutsummaryrefslogtreecommitdiffhomepage
path: root/osdep/subprocess.c
diff options
context:
space:
mode:
authorGravatar wm4 <wm4@nowhere>2016-08-06 15:47:04 +0200
committerGravatar wm4 <wm4@nowhere>2016-08-06 15:47:04 +0200
commitd41f0a54b07d855227b63a6b2c4e92794ff7b86f (patch)
tree45837e7bfd3d55e614c3c38a78c937153c0c491d /osdep/subprocess.c
parentd4ee5e5a8ad450d16fb2ede212c536e01970ae16 (diff)
player: improve instant track switching
When switching tracks, we normally have the problem that data gets lost due to readahead buffering. (Which in turn is because we're stubborn and instruct the demuxers to discard data on unselected streams.) The demuxer layer has a hack that re-reads discarded buffered data if a stream is enabled mid-stream, so track switching will seem instant. A somewhat similar problem is when all tracks of an external files were disabled - when enabling the first track, we have to seek to the target position. Handle these with the same mechanism. Pass the "current time" to the demuxer's stream switch function, and let the demuxer figure out what to do. The demuxer will issue a refresh seek (if possible) to update the new stream, or will issue a "normal" seek if there was no active stream yet. One case that changes is when a video/audio stream is enabled on an external file with only a subtitle stream active, and the demuxer does not support rrefresh seeks. This is a fuzzy case, because subtitles are sparse, and the demuxer might have skipped large amounts of data. We used to seek (and send the subtitle decoder some subtitle packets twice). This case is sort of obscure and insane, and the fix would be questionable, so we simply don't care. Should mostly fix #3392.
Diffstat (limited to 'osdep/subprocess.c')
0 files changed, 0 insertions, 0 deletions