From d54e8c3f40934501d5fb5875defd797eff0ae57b Mon Sep 17 00:00:00 2001 From: Dudemanguy Date: Wed, 25 Sep 2024 21:04:31 -0500 Subject: [PATCH] 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. --- demux/demux_mkv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/demux/demux_mkv.c b/demux/demux_mkv.c index 276138acdf..c551205694 100644 --- a/demux/demux_mkv.c +++ b/demux/demux_mkv.c @@ -2139,7 +2139,7 @@ static void probe_if_image(demuxer_t *demuxer) int64_t timecode = -1; // 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) break; if (mkv_d->blocks[block].track != track)