RepoMirrors
/
mpv
mirror of https://github.com/mpv-player/mpv
1
0
Fork 0
Code Issues Releases Wiki Activity

demux_mkv: drop image probing down to 10000 blocks 

It turns out that probing too many blocks is bad. I did not attempt to
go through all the logic but reading that many blocks causes the
demux_reader_state have some pretty funny values which then makes the
playloop think it needs to buffer for cache. It's probably fixable...
but seems hard admittedly so I'll be lazy. Just take out a magnitude off
the probing down to 10000. These seems to be more than sufficient. The
sample in #13975 where we had the opposite issue only needs somewhere
between 1700 and 1750 blocks to be properly detected. Crudely looking
at the demuxer values, 10000 here doesn't appear to alter anything
meaningfully so it does not have the "too many blocks problem".
Hopefully this is a perfect medium? Further improvements to the probe
can always be added later. Or maybe we decide this is all a giant
mistake and delete it. Fixes #14924.
This commit is contained in:
Dudemanguy 2024-09-25 21:04:31 -05:00
parent c9f3fa33a6
commit d54e8c3f40
1 changed files with 1 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
demux/demux_mkv.c
View File

@ -2139,7 +2139,7 @@ static void probe_if_image(demuxer_t *demuxer)
int64_t timecode = -1; int64_t timecode = -1;
// Arbitrary restriction on packet reading. // Arbitrary restriction on packet reading.
for (size_t block = 0; block < 100000; block++) { for (size_t block = 0; block < 10000; block++) {
if (block >= mkv_d->num_blocks && read_next_block_into_queue(demuxer) != 1) if (block >= mkv_d->num_blocks && read_next_block_into_queue(demuxer) != 1)
break; break;
if (mkv_d->blocks[block].track != track) if (mkv_d->blocks[block].track != track)