HackerTrans
トップ新着トレンドコメント過去質問紹介求人

null-phnix

no profile record

投稿

[untitled]

1 ポイント·投稿者 null-phnix·2 か月前·0 コメント

[untitled]

1 ポイント·投稿者 null-phnix·2 か月前·0 コメント

Three things getting missed in the Anthropic/Dow supply chain risk story

1 ポイント·投稿者 null-phnix·4 か月前·0 コメント

Ask HN: How are you handling persistent memory across local Ollama sessions

6 ポイント·投稿者 null-phnix·4 か月前·0 コメント

コメント

null-phnix
·2 か月前·議論
[flagged]
null-phnix
·2 か月前·議論
i mean porbly
null-phnix
·2 か月前·議論
Location: Toronto, ON (Canada) Remote: Yes

Willing to relocate: Yes (Toronto-based, remote and open to relocate)

Technologies: Python, LangGraph, VLM/LLM integration, autonomous agents, browser automation, multi-agent orchestration, RAG pipelines, edge inference, scraping/crawling

Résumé/CV: phnix.dev

Email: [email protected]
null-phnix
·3 か月前·議論
Exactly. The cross-platform descriptor dance is one of those things that's invisible to people outside the pipeline but eats an absurd amount of dev time. You end up writing the same conversion logic three times for three platforms, each with its own failure modes and version quirks, and none of it has anything to do with the actual codec work.

Having Vulkan as the single surface for both the compute and the rendering side means one memory model, one synchronization story, one set of bugs to chase. That alone is worth the effort even before you get to the performance wins.
null-phnix
·4 か月前·議論
[dead]
null-phnix
·4 か月前·議論
A lot of the confusion in this thread feels like it comes from thinking in terms of web streaming rather than the workloads this post is targeting.

The article is pretty explicit that this is not about "make Twitch more efficient" or squeezing a bit more perf out of H.264. It is about mezzanine and archival formats that are already way beyond what a single CPU, even a decade old workstation CPU, handles comfortably in real time: 4K/6K/8K+ 16‑bit, FFv1-style lossless, ProRes RAW, huge DPX sequences, etc. People cutting multi‑camera timelines of that kind of material are already on the wrong side of the perf cliff and are often forced into very specific hardware or vendors.

What Vulkan compute buys you here is not "GPUs good, CPUs bad", it is the ability to keep the entire codec pipeline resident on the GPU once the bitstream is there, using the same device that is already doing color, compositing and FX, and to do it in a portable way. FFmpeg’s model is also important: all the hairy parts stay in software (parsing, threading, error handling), and only the hot pixel crunching is offloaded. That makes this much more maintainable than the usual fragile vendor API route and keeps a clean fallback path when hardware is not available.

From a practical angle, this is less about winning a benchmark over a good CPU encoder for 4K H.264, and more about changing what is feasible on commodity hardware: e.g., scrubbing multiple streams of 6K/8K ProRes or FFv1 on a consumer GPU instead of needing a fat workstation or dailies transcoded to lighter proxies. For people doing archival work or high end finishing on a budget, that is a real qualitative change, not just an incremental efficiency tweak.
null-phnix
·4 か月前·議論
[dead]