Tags: clowd/Clowd
Tags
Let a frame rate preset reach 999, or be cleared away entirely The preset boxes were bounded by the Fps setting's own [Range(1, 240)], which made them unable to describe the faster panels that exist now, and unable to describe a cycle of fewer than three stops: every box had to hold some rate, so a user who wanted to toggle between just 60 and native had to invent a third. Raise the box ceiling to 999 and drop its floor to 0, and let the cycle decide what is actually offerable rather than the box: a preset outside 1..360 is skipped, on top of the existing "above the monitor's refresh rate" rule. 0 is how an emptied box is stored, so clearing one removes that stop. Clearing all three leaves the native rate as the only option, which is what that asks for; with no native rate to fall back on, the built-in 30/60/120 still stand in so the tile is never left with nowhere to cycle to. The boxes needed their own converter for this. NumericTypeConverter answers a cleared box with UnsetValue, which leaves the old number in the settings - the box looks empty until the page is reopened and the preset comes back.
Bound the thumbnail's derived width so its byte count cannot wrap ThumbWidth follows the source's shape - srcWidth * PAR * ThumbHeight / srcHeight - and nothing bounded it. ThumbHeight is clamped to 512 but that is the multiplier, not a limit: a file declaring 8194x2 asks for a thumb 2,097,664 pixels wide, whose byte count is 4,296,015,872 and wraps a 32-bit int to 1,048,576. The decoder then allocated 1 MiB and told sws_scale the destination was gigabytes wide, into a pinned managed array - the same undersized-buffer smash the stride padding was for, reached by arithmetic instead. Predates the stride work (at that shape the rounded stride is identical to width * 4), so it has shipped for as long as the thumbnailer has, but it is the one remaining way to get an under-allocated destination. Cap the width - nothing is legible as a thumbnail past 16384 anyway - clamp as a double, since casting one larger than int.MaxValue is undefined and would have silently landed on the Math.Max(2, ...) floor, and check the byte count so a wrap can never again be silent. Two smaller hardenings from the same review: SyncReadbackRing's staging is handed to sws_scale as a SOURCE by Nv12Converter, and the scaler reads the last row in whole blocks past the used width. It was allocated exactly; give it the pool's tail. Only reachable on canvases 8px and narrower, but it is the same defect seen from the other side. IFrameSink hands the present thread a buffer to scale into, and its contract said nothing about the stride, so an implementer wrapping a foreign buffer (a locked bitmap) could reintroduce the whole bug. Say what the stride must be and what to do when you do not control it. The y4m fixture takes a size now, which is how the degenerate shape gets a regression test: uncompressed, so a frame no encoder would accept costs only its bytes.
Pad BGRA strides so swscale writes every column and no more The crash fixed in aed6cec was only half the defect. swscale's unscaled yuv420p-to-BGRA converter writes whole 16-pixel blocks with no scalar tail, and picks how many fit from the stride it is handed: h_size = (dstW + 7) & ~7; if (h_size * 4 > dstStride) h_size -= 8; At a tight width*4 stride that costs a frame one of two ways. A width under 16, or one whose remainder mod 16 is 8..15, still gets a full 64-byte block per row and runs off the end of the allocation - the heap smash that took CI down, which the pool's tail now absorbs. But a width of 17 or more whose remainder mod 16 is 1..7 takes the other branch and the last 1..7 columns of every row are never written at all: a 1366-wide frame keeps 6 columns of whatever the buffer held before, and nothing downstream crops them - the composer samples the full stored rect and Skia is handed the full width. Verified end to end on the pre-fix build: 1366 -> 6 stale columns, 854 -> 6, 500 -> 4, 100 -> 4; 1360 and 1920 clean. It has shipped unnoticed because a fresh pool buffer is zeroed, so on a real source it is a stable black strip at the far right edge that reads as the video's own, and because monitor-sized captures are all multiples of 16 wide. The exposure is imported files and odd-width region captures. Round the stride up to a whole block instead, at the three producers that hand swscale a BGRA destination, and both branches go away: every block fits, so the full width is written and nothing runs past the row. ThumbnailDecoder is the one that could corrupt the GC heap rather than the native one - it scales into a pinned managed array, and takes the unscaled path whenever a source is already the thumb's height at square pixels. Its stride is public, so FilmstripProvider's cache entry now carries it instead of recomputing width*4. Keep the pool's tail as a backstop: swscale also over-reads a buffer handed to it as a source by up to 64 bytes, which the matte path does, and the block width belongs to the kernel swscale picks rather than to the pixel format - on an FFmpeg bump the constant is re-measured, not re-derived.
PreviousNext