|
|
|
|
<?php
|
|
|
|
|
|
|
|
|
|
namespace App\Util\Media;
|
|
|
|
|
|
|
|
|
|
use App\Models\Media;
|
|
|
|
|
use App\Util\Blurhash\Blurhash as BlurhashEngine;
|
|
|
|
|
|
|
|
|
|
class Blurhash
|
|
|
|
|
{
|
|
|
|
|
const DEFAULT_HASH = 'U4Rfzst8?bt7ogayj[j[~pfQ9Goe%Mj[WBay';
|
|
|
|
|
|
|
|
|
|
public static function generate(Media $media, $path = false)
|
|
|
|
|
{
|
|
|
|
|
if (! in_array($media->mime, ['image/png', 'image/jpeg', 'image/jpg', 'video/mp4'])) {
|
|
|
|
|
return self::DEFAULT_HASH;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if ($media->thumbnail_path == null) {
|
|
|
|
|
return self::DEFAULT_HASH;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if ($path) {
|
|
|
|
|
$file = $path;
|
|
|
|
|
} else {
|
|
|
|
|
$localFs = config('filesystems.default') === 'local';
|
|
|
|
|
$file = storage_path('app/'.$media->thumbnail_path);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (! is_file($file)) {
|
|
|
|
|
return self::DEFAULT_HASH;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
$image = imagecreatefromstring(file_get_contents($file));
|
|
|
|
|
if (! $image) {
|
|
|
|
|
return self::DEFAULT_HASH;
|
|
|
|
|
}
|
|
|
|
|
$width = imagesx($image);
|
|
|
|
|
$height = imagesy($image);
|
|
|
|
|
|
Fix videos never reaching cloud storage by downscaling in Blurhash
Blurhash::generate() allocates one PHP array per pixel of the source. At
roughly 255 bytes per pixel (measured: 224 MB peak for a 720x1280 frame) a
1920x1080 frame approaches half a gigabyte.
Image thumbnails survive this because they are capped at 640x640 in
Image::__construct() *and* run under that constructor's
ini_set('memory_limit', '1024M'). Video thumbnails get neither: FFmpeg saves
them at the source video's resolution, and VideoThumbnail never raises the
limit. So a video whose frame is 1080p or larger exhausts memory_limit.
That is a PHP fatal, not an \Exception, which has three consequences:
- the catch block in VideoThumbnail::handle() does not catch it
- the job never lands in failed_jobs, so nothing reports a problem
- MediaStoragePipeline::dispatch() on the last line of handle() never runs
The video therefore stays on local disk permanently while images beside it
replicate normally. Reported in #2652 (2021-02-13) and diagnosed correctly in
that thread on 2021-11-04.
Two changes:
1. Blurhash::generate() downscales to 128px on the long edge before sampling.
The result is a 4x4-component DCT, so full-resolution sampling adds
essentially nothing: measured against the full-resolution hash, mean
per-channel deviation of the decoded 24x24 preview is ~7.5/255 at a 32px
sample, ~4.5/255 at 64px, ~2.5/255 at 128px, and no better at 256px. Peak
memory for the frame above drops from 224 MB to 6 MB.
This removes the ceiling for every caller rather than moving it, which is
all that raising memory_limit would have done. Existing stored hashes are
not recomputed, so nothing already published changes appearance.
2. VideoThumbnail wraps the blurhash in its own try/catch, so a decorative
step can no longer skip the replication dispatch. Change 1 covers the
fatal; this covers any ordinary exception.
Verified on a live instance with S3 cloud storage: a 1920x1080 video that
previously stranded now generates a blurhash, uploads original and thumbnail
to the bucket, sets cdn_url/thumbnail_url/replicated_at, and removes the local
copies. Existing images re-hash to visually identical previews.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2 months ago
|
|
|
// The loop below allocates one PHP array per pixel, which costs a few hundred
|
|
|
|
|
// bytes each once the hashtable is counted: a 720x1280 frame measured at 224 MB
|
|
|
|
|
// peak, i.e. ~255 bytes per pixel, which puts 1920x1080 near half a gigabyte
|
|
|
|
|
// (#2652 reports over a gigabyte on an older PHP). Image thumbnails are capped
|
|
|
|
|
// at 640x640 and run under Image::__construct()'s ini_set('memory_limit',
|
|
|
|
|
// '1024M'), so they stay inside it. Video thumbnails come straight out of
|
|
|
|
|
// FFmpeg at source resolution with no
|
|
|
|
|
// such raise, and blow memory_limit outright — a PHP fatal, which is not an
|
|
|
|
|
// \Exception, so it kills the worker instead of being caught (pixelfed#2652).
|
|
|
|
|
//
|
|
|
|
|
// The output is a 4x4-component DCT, so sampling the source at full resolution
|
|
|
|
|
// buys almost nothing. Downscaling first removes the ceiling for every caller
|
|
|
|
|
// rather than moving it, which is all raising memory_limit would have done.
|
|
|
|
|
//
|
|
|
|
|
// 128px on the long edge measured as the point of diminishing returns: against
|
|
|
|
|
// the full-resolution hash, mean per-channel deviation of the decoded 24x24
|
|
|
|
|
// preview is ~7.5/255 at a 32px sample, ~4.5/255 at 64px, ~2.5/255 at 128px,
|
|
|
|
|
// and no better at 256px. At 128px a 1920x1080 frame samples 9,216 pixels
|
|
|
|
|
// instead of 2,073,600.
|
|
|
|
|
$sampleMax = 128;
|
|
|
|
|
if ($width > $sampleMax || $height > $sampleMax) {
|
|
|
|
|
$scale = $sampleMax / max($width, $height);
|
|
|
|
|
$sampleWidth = max(1, (int) round($width * $scale));
|
|
|
|
|
$sampleHeight = max(1, (int) round($height * $scale));
|
|
|
|
|
|
|
|
|
|
$resized = imagescale($image, $sampleWidth, $sampleHeight);
|
|
|
|
|
if ($resized !== false) {
|
|
|
|
|
imagedestroy($image);
|
|
|
|
|
$image = $resized;
|
|
|
|
|
$width = $sampleWidth;
|
|
|
|
|
$height = $sampleHeight;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
$pixels = [];
|
|
|
|
|
for ($y = 0; $y < $height; $y++) {
|
|
|
|
|
$row = [];
|
|
|
|
|
for ($x = 0; $x < $width; $x++) {
|
|
|
|
|
$index = imagecolorat($image, $x, $y);
|
|
|
|
|
$colors = imagecolorsforindex($image, $index);
|
|
|
|
|
|
|
|
|
|
$row[] = [$colors['red'], $colors['green'], $colors['blue']];
|
|
|
|
|
}
|
|
|
|
|
$pixels[] = $row;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
imagedestroy($image);
|
|
|
|
|
|
|
|
|
|
$components_x = 4;
|
|
|
|
|
$components_y = 4;
|
|
|
|
|
$blurhash = BlurhashEngine::encode($pixels, $components_x, $components_y);
|
|
|
|
|
if (strlen($blurhash) > 191) {
|
|
|
|
|
return self::DEFAULT_HASH;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return $blurhash;
|
|
|
|
|
}
|
|
|
|
|
}
|