DEV Community: jiahui dong

Reimagining Video Creation with AI & GPU Acceleration

jiahui dong — Thu, 17 Sep 2026 09:03:35 +0000

This article was first published on my site: https://resume.tensorview.cc/blog/ai-video-creation-engine.html
FastAPI + GPU / NVENC: business logic decoupled from render

I built a distributed AI video splitting and synthesis backend. FastAPI handles logic on CPU nodes while encode/decode rides NVIDIA GPUs via FFmpeg CUDA (NVENC) — about 8–10× faster than CPU-only rendering.

Mini-program “AI Original”: split, scenes, voiceover, one-tap synthesize.

Key features

Heterogeneous compute: logic decoupled from GPU render for concurrent jobs.
AI workflow: DeepSeek rewrite plus Edge-TTS voiceover.
Storage: local cache + Qiniu OSS with LRU cleanup.
Pro codecs: lossless 4K splitting and real-time multi-track mix.

AI script UI: DeepSeek create/rewrite with Edge-TTS voice pick.

History: synthesis status, preview, and download.

Closing

Whether you run a short-video matrix or automated content pipelines, this stack is built for faster synthesis. Always happy to talk optimization or A/V automation.

Original post: https://resume.tensorview.cc/blog/ai-video-creation-engine.html

Architecting High-Performance Multi-Camera Streaming with RGA Hardware Acceleration

jiahui dong — Thu, 17 Sep 2026 09:02:48 +0000

This article was first published on my site: https://resume.tensorview.cc/blog/rk3588-rga-multi-camera.html
RGA + DMA zero-copy for three high-res camera streams

In a recent RK3588 Embedded Linux project I owned the vision capture path: three high-resolution streams (coaxial, USB, wireless) previewed at once. CPU soft conversion would choke the UI thread under that throughput.

Legacy CPU soft-decode path: heavy memory traffic fights the UI thread.

The architectural decision

I designed around the on-SoC RGA from day one. A DMA path feeds raw YUV from contiguous buffers into RGA for YUV→RGB and scaling, skipping extra CPU cache churn.

RGA hardware path: CPU only configures; pixels stay on DMA.

Technical challenges

Strict alignment: posix_memalign 4K page-aligned pools keep DMA stable and avoid tearing / faults.
Heterogeneous sources: a unified buffer layer configures RGA from V4L2 metadata (UYVY vs YUYV, MIPI vs USB).

Live preview UI: switch coaxial / FOV / RX with hardware controls in one panel.

Outcome

All three cameras preview smoothly with negligible CPU on the video path, leaving headroom for business logic and UI. Hardware-aware design still wins in embedded.

Original post: https://resume.tensorview.cc/blog/rk3588-rga-multi-camera.html

Embedded Linux I2C Debugging: How a Register Dump Saved Me from an Invisible Timing Trap

jiahui dong — Thu, 17 Sep 2026 08:56:56 +0000

This article was first published on my site: https://resume.tensorview.cc/blog/i2c-trise-ack-trap.html
CCR looked flawless. TRISE was the real trap.

Recently I worked on a layout where the host MCU needed more GPIOs, so we hung an I2C expander. Standard architecture — until intermittent EIO (-5) errors and missing slave ACKs showed up.

Instead of guessing at the driver, I took a structured path: scope the bus and dump physical I2C registers at the moment of failure.

The Illusion

The Clock Control Register (CCR) was calculated correctly for 100 kHz Standard Mode. On paper the baud rate looked flawless.

The Symptom

The oscilloscope showed a slight trailing edge on the SCL rise. The register snapshot at failure captured SR1.AF = 1 (Acknowledge Failure).

The Root Cause

TRISE (maximum rise time) was set too low. The I2C state machine jumped the gun — sampling before SCL had reached a valid high (Vih).

The Fix

I recomputed TRISE from PCLK and the I2C spec, updated Device Tree / driver init, and the bus stayed clean across a 10,000-cycle stress test.

Key Takeaway

High-level abstractions often mask physical reality. When a driver throws a generic error, dump the hardware registers. Registers do not lie.

Original post: https://resume.tensorview.cc/blog/i2c-trise-ack-trap.html

Six Months in Taobao Outsource Groups: The Flow and the Traps

jiahui dong — Thu, 17 Sep 2026 08:56:10 +0000

This article was first published on my site: https://resume.tensorview.cc/blog/taobao-outsource-group-half-year.html
Only what I lived through. Personal sharing — not a rant against anyone or the industry, just a sigh after walking through it. I don’t live off this path. Project details later.

Up front: this is a personal note, not a get-rich guide, and not a hit piece on any firm or the whole outsource scene. I’ll unpack the Taobao shop → WeChat order-group path I walked, then the awkward bits I hit as a developer and what I saw on the client side, plus a short contrast with other channels.

1. What the flow looks like

On my side, the pipeline was roughly five steps.

Join the group: Message Taobao outsource shops and ask if they need developers. Usually yes — they pull you into a WeChat group where orders are posted.
Orders get posted: Posters I met were mostly company customer-service staff (e.g. from a Suzhou firm). They mentioned ¥500 commission per finished order; I never saw the exact split.
Requirements: CS usually already sits with the client in a group (sometimes with other clients too). They talk requirements, forward the brief to the developer group, and interested developers DM CS with a quote.
Build: Developer, client, and CS move into a smaller group. After that CS mostly steps back; the developer talks with the client and builds in parallel.
Acceptance & pay: After acceptance, developers often wait until month-end for a batch payout. Clients frequently paid the middleman in full at order time — a big structural advantage for the agency.

2. Where it gets awkward for developers

From the developer seat, these stuck with me the most.

1. Usually no pay until the work is truly done

Before real completion and acceptance, you often see no money at all. If the client later adds scope or changes their mind, you frequently have to keep going — or the payout stays held.

When conflict shows up, CS talks to both sides: tells the client “this may not have been clear — add budget or pause”; tells the developer “please tweak a bit more,” sometimes mentioning a little extra pay. That “extra” rarely matches what the middleman already took.

With no cash in hand, you have little leverage. The middleman carries little risk: if you can’t finish, they can rehire with the same money. You ate the sunk time.

Why isn’t scope locked in one shot? What I saw: clients don’t know the domain and invent asks later; nobody foresaw every edge case, and developers can’t know every industry; or communication turns sour and every change drains you.

2. Developer take-home is low; the middle cut is thick

Multiple agencies often post in the same groups, so developers compete hard and take-home rates stay low. Two firms I ran into marked up a lot: one roughly 2× the developer quote to the client; another as high as 7–8×.

They don’t always care how polished the work is. If the client can accept it, rough edges may be fine — they know the developer take-home is already small.

One of mine: a “transfer station” job. I quoted ~¥300; the client paid 5000+ for the code work. Full web stack plus server deploy. ¥300 can look okay until endless UI and feature churn — even on an open-source base — wears you down.

I ran 2–3 jobs in parallel with AI help, so as a side income it looked okay: a couple of deliveries every 1–2 weeks. Cost: high energy, limited skill growth, almost no lasting passive income, and few repeats.

3. Even after friending clients, repeats were rare

I added almost every client and did plenty of extra fixes, yet almost none returned via this Taobao-group path. Boss Zhipin and friend referrals brought more repeats. The CS-mediated experience may be part of it — if it feels mediocre, people don’t come back the same way.

3. Clients can lose out too

Same transfer-station case: competition kept my quote around ¥300, while the agency charged the client about ¥5000 — most of it middleman margin.

What surprised me more: the client rented that company’s server, didn’t keep the account, and fully handed the project off. ~¥3000/year on a crowded shared box that felt sluggish — enough money to self-host — yet they paid without digging in.

So the picture I saw is twisted: developer prices get crushed while most money stays in the middle. Many “developers” listed on Taobao are ad-hoc outsourcers — not much of a hard guarantee.

4. Stopping here for now

By comparison, other channels felt better: forums like V2EX or EleDuck where you take jobs yourself, or Boss Zhipin — basically anything except specialized middleman agencies. And always take a deposit and agree on staged delivery up front: projects run steadier, and you keep negotiating room while building. Lock the payment milestones before you start.

Personal experience and a sigh — not a verdict on the industry. What projects I shipped and how I scheduled them — later. If you pass through similar groups, the three questions I wish I’d clarified earlier: when money arrives, how big the cut is, and how scope gets locked to cut rework.

Original post: https://resume.tensorview.cc/blog/taobao-outsource-group-half-year.html

Outsourcing Part 2: AI Side Jobs on the Web — Where Money and Pain Come From

jiahui dong — Thu, 17 Sep 2026 08:48:44 +0000

This article was first published on my site: https://resume.tensorview.cc/blog/outsource-ai-side-hustle-part-2.html
Sequel to part 1. What web/mini-program gigs I actually shipped, how I used AI to move fast, and two jobs that drained me. Personal notes — not a playbook, not a rant.

Part 1 mapped Taobao middleman groups and cuts. This one is the doing: what the jobs looked like, rough income, which clients were fine, and which ones left me with one rule — don’t take that kind of job again.

1. What I actually built

Most were compact full-stack web jobs: software download sites, API relay/proxy stations, Reddit-like forums, WordPress trade sites, tutoring-school landing pages. Mini programs too — e.g. Coze-backed Q&A, and a construction-vehicle monitoring app.

AI wrote most of the code. My setup was plain: a monthly AI Pro plan bought on Xianyu, plus Cursor — enough quota to push simple gigs through a month. My job was scope, edges, and getting to acceptance — not typing every line from scratch.

2. Rough income

In a normal month of these simpler jobs, an extra ¥3–4k side income felt common. With luck — first-hand work, thin middle cut — ¥8k in a month is possible. High variance; don’t budget on the ceiling.

Think of it as side-hustle leverage: talk, ship, collect — stack other gigs and you might approach full-time income. That needs decent jobs. Taobao-agency handoffs crush the rate; I covered that in part 1.

3. Two jobs that really hurt

Not every job was painful. Some shipped, got accepted, and felt clean. Two stuck with me hard enough to write down.

1. A two-day HTML site that stretched nearly two months

One client wanted an app download site. Objectively a one-to-two-day static page. It ran nearly two months — not because the page was hard, but because their app wasn’t ready, and each build meant another Qiniu upload from me. Easy work, calendar owned by them; effective rate tanked and it felt awful.

Lesson: if delivery depends on the client’s own product cadence, lock how many update rounds, how time is billed, and what happens when they slip — or you’re their unpaid upload clerk.

2. Rush job + a crawling server: never take “must ship in a week”

Another was a relay/transfer station with a one-week deadline. That taught me: skip rush jobs when you can. They can ping by the hour; WeChat opens to a wall of messages, and their anxiety owns your calendar.

Worse: we were on the agency’s server, painfully slow. Build on GitHub, upload, deploy — each step crawled; a tiny tweak could eat half a day before you saw it live. The client kept inventing tiny changes, rushed me daily, barely pushed the middleman — who still took the fat cut. In that setup the developer loses twice, and it barely makes sense.

4. Smooth jobs still cost attention

Plenty of jobs were fine: clear enough scope, ship, accept. Even then, many clients know neither tech nor product — so you still eat empty talk and shifting asks. Light work, heavy mental overhead.

As a true side hustle — not another full-time stress layer — it can feel okay: fingers, voice, ship. Stack other gigs and you might near full-time income. Source still matters: prefer first-hand, thin-cut work. Taobao middleman boards stay a bad deal long-term.

5. Rules I’m keeping

Skip pure rush jobs: a one-week hard deadline plus hourly pings usually means scope creep and no evenings.
Don’t bind to an unfinished client product forever: cap or bill upload/release rounds up front.
Avoid agency server + agency cut together: bad env, thin pay, half-day deploys per tweak.
AI speeds coding; you still set boundaries: Cursor writes code — it won’t stop a client’s change loop.
Prefer first-hand channels: side work can be pleasant — not inside the thickest cut forever.

Closing

Still personal. Web gigs plus AI can add real cashflow; whether it feels good hangs on where the job comes from, how loose the deadline is, and whether the env lets you iterate fast. For the pipeline and cuts, see part 1. If more traps are worth writing down, there’ll be a part 3.

Original post: https://resume.tensorview.cc/blog/outsource-ai-side-hustle-part-2.html

How I Ship a Controlled Download Site: HTML + Private Object Storage + VPS

jiahui dong — Thu, 17 Sep 2026 08:48:43 +0000

This article was first published on my site: https://resume.tensorview.cc/blog/secure-download-site-flask-qiniu.html
This is the real flow I used — front-end page, private object-storage URLs, then a VPS. Screenshots are from an anonymized demo brand.

Your outline is right: page → object storage → wire uploads → rent a VPS → git and run. What usually fails in freelance delivery is not “can you write HTML,” but the edges: where secrets live, how links expire, chat-app cache, and the reverse proxy. Below is build, then deploy, plus the traps I hit.

Demo download page (desktop): brand nav, Windows button, feature cards.

1. Lock acceptance before you code

Agree what “done” means before coding. Otherwise you become their unpaid upload clerk every time the app binary changes. At minimum, put these acceptance checks in the quote.

Can download: PC and Android each get a package; the button gives clear feedback.
Can expire: signed URLs time out (often 24h) and stop working.
No secrets in the browser: keys only in server env/config.
Chat cache does not stick: opening in WeChat/Line-like in-apps shows the latest page, not last week’s copy.
Re-upload rounds: how many free binary updates; extras billed per push.

2. Build: the front-end pages

First deliverable is a download-center lookalike: download, FAQ, support. The download page switches desktop/mobile; FAQ locks install steps with screenshots; support lists regional contacts. Technically: HTML/CSS plus a little JS. The backend only mints download URLs.

Download button: POST for a URL, then navigate; 5s cooldown stops double-taps.
Asset busting: version query on CSS/JS/images so clients see CSS updates.
Anonymize for portfolio: swap company name, ICP, real support contacts before blogging screenshots.

Same page on the mobile tab: QR + Android button.

Narrow viewport: brand + nav stack for phone acceptance checks.

3. Build: object storage (Qiniu in this case)

Do not host installers as naked files on the VPS — bandwidth and leak control both suffer. Put binaries in a private object bucket; the backend SDK mints time-limited signed URLs. This case used Qiniu; overseas, the same pattern maps to S3 or R2.

Bucket: create a private space; bind a download CDN domain.
Keys: create Access/Secret keys for the server only — never commit, never ship to JS.
Object keys: agree paths like exe/app-windows.exe and exe/app-android.apk; same names front and back.
Optional CDN locks: timestamp hotlink protection / per-IP rate limits on top of signed URLs.

4. Build: upload binaries and wire the API

After uploading to the right keys, the backend (Flask here) exposes POST /api/download with type=pc|android. It reads client IP, applies a short rate window, calls the private URL API, and returns { success, url }. The front-end navigates to that URL. GET /api/health helps smoke-test deploys.

Smoke test: curl the API — expect a long URL with e= and token=; opening it should start the download.
Rate limit: e.g. 2 requests / 5s per IP; over limit → 429 + wait_time for the UI.
Config: prefer env vars; commit examples only, never real secrets.

5. Deploy: rent a VPS

A small VPS is enough (1C2G often fine for this guide site). Ubuntu LTS, open 80/443, SSH keys only. Point DNS A records at the public IP. If the client owns the domain, they add the record; otherwise accept on IP / temp domain first.

6. Deploy: git, run, reverse-proxy

One chain: git clone/pull → venv → pip install → env vars → python app.py for dev, gunicorn bound to 127.0.0.1:5000 in prod. Nginx in front: static files + /api reverse-proxy. Finish with certbot HTTPS.

systemd: enable on boot and restart on failure — fewer midnight WeChat pings.
Logs: keep gunicorn/nginx error paths; first ask if it is 502 or 429.
Permissions: service user needs read on the app tree; tighten secret file modes.

FAQ page: screenshot-backed install steps cut repeat support.

Support page (demo data): regional mail placeholders — swap for client contacts in production.

7. Details that bite in production

In-app cache: Cache-Control: no-store on HTML; append _t= timestamps. Small detail, big for WeChat-like clients.
Wrong object key: bucket has exe/foo.exe but code says foo.exe → Document not found. Match the console path.
Domain vs CDN: site domain and file CDN domain can differ; renew certs before expiry.
Written checklist: health URL, download URL, expired-link failure, in-app screenshot — send it to the client.

8. End-to-end flow (quote appendix)

Build: three pages → private bucket + CDN → upload binaries → Flask mint API wired to buttons. Deploy: VPS → git → venv → env → gunicorn + Nginx + HTTPS → accept in-app and expired-link cases. Clear edges and screenshotable checks make fixed-price gigs viable — if re-upload rounds are priced.

Screenshots are anonymized demos, not a real client brand. Treat this as a checklist if you take similar gigs — same road as my Taobao-group and AI side-job notes, different slice.

Original post: https://resume.tensorview.cc/blog/secure-download-site-flask-qiniu.html