HackerTrans
TopNewTrendsCommentsPastAskShowJobs

null-phnix

no profile record

Submissions

[untitled]

1 points·by null-phnix·2 bulan yang lalu·0 comments

[untitled]

1 points·by null-phnix·2 bulan yang lalu·0 comments

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

1 points·by null-phnix·4 bulan yang lalu·0 comments

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

6 points·by null-phnix·4 bulan yang lalu·0 comments

comments

null-phnix
·2 bulan yang lalu·discuss
[flagged]
null-phnix
·2 bulan yang lalu·discuss
i mean porbly
null-phnix
·2 bulan yang lalu·discuss
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 bulan yang lalu·discuss
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 bulan yang lalu·discuss
[dead]
null-phnix
·4 bulan yang lalu·discuss
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 bulan yang lalu·discuss
[dead]