UnigramDev/Unigram/develop • 0f035f1 • 3 files, +56/-9 Make VideoAnimation::Stop actually able to st

UnigramDev/Unigram/develop • 0f035f1 • 3 files, +56/-9
Make VideoAnimation::Stop actually able to stop a decode

Nothing in the app has ever called Stop, so neither of these has been
exercised. They matter now because the cancellation survey points at Stop as
the lever for aborting a preview render, and it would not have worked.

stopped was a plain bool, written by Stop from whichever thread wants to abort
and read by the decode loop and by the IO callbacks running under it. It is
now std::atomic<bool>. Every use is a plain load or store, so only the
declaration changed. Stop still does not take m_lock, and that is deliberate:
taking it would block until the decode it is trying to interrupt had finished.

readCallback returned 0 once stopped. ffmpeg reads 0 as "no bytes this call"
rather than as a failure, so it can keep asking and spin instead of unwinding
the demuxer. It returns AVERROR_EOF now. seekCallback had the same shape, where
returning 0 reports a successful seek to offset 0 and sends the demuxer back to
the start rather than letting it fail out.

Not built: Telegram.Native needs the vcpkg ffmpeg setup, so this is unverified
by a compiler. std::atomic<bool> needs <atomic>, which is now included.

Left alone next door: seekCallback's live path has the same 0 return when
SetFilePointerEx fails, reporting a successful seek to the start. Same class of
bug, but on the path that plays video rather than the one that aborts it, so it
wants someone who can run it.

Also closes 2.3 in the review doc as won't-fix, with the reasoning. Probing a
media item twice is real, but the probe answers what a file is and how big
before the item can be published, and the thumbnail answers what it looks like
on realization and has to stay releasable. Every way of collapsing the two puts
back what moving the thumbnails off the models took away.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

UnigramDev/Unigram/develop • 200e65f • 1 files, +20/-10
Correct what probing a video actually costs

The note closing 2.3 said the video path pays a real avformat_open_input plus
find_stream_info twice. That overstates it: VideoAnimation already has a light
mode and the probe already uses it.

LoadFromFile takes preview and probe flags that exist for this. preview sets
AVFMT_FLAG_NOBUFFER so nothing is buffered, and probe skips the frame and
packet allocation along with the no-video-stream bail. StorageVideo.CreateAsync
and StorageAudio.CreateAsync both ask for both, so the first pass is headers
only. The photo probe is the same shape, since BitmapDecoder.CreateAsync reads
a header rather than decoding.

So what runs twice is a header read plus a real decode, not two decodes. The
conclusion is unchanged and the reasoning is stronger: the design already has a
cheap probe mode and deliberately uses it, which is about as good as a lazy,
releasable thumbnail gets.

Also records an inconsistency noticed while checking, without acting on it:
ImageHelper loads with preview false, so its format context does buffer, but
passes preview true to RenderSync, which is what raises the retry count to 50.
Whether NOBUFFER helps or hurts a single frame grab is a measurement.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

#unigram