Na-update Oktubre 10, 2026

Aling MP4 ang pipiliin mula sa X post

Ilang MP4 rendition ang inilalathala ng X para sa parehong video. Madalas pareho ang resolution at magkaiba ang bitrate, kaya hindi laging ang pinakamataas na row ang gusto mo.

I-paste ang link ng post at makukuha mo ang mga rendition ng video ayon sa pagkakalista ng X, pinakamataas na resolution muna. Ang ayos na iyon ay panimulang punto, hindi hatol: ang resolution ay laki lang ng frame, at ang dalawang file sa parehong laki ng frame ay maaaring magkaiba nang husto sa dami ng data na bumubuo sa bawat segundo ng larawan.

Ano ang binabasa ng resolver

Hindi ito nangangailangan ng login sa X. Hinihingi ng resolver sa pampublikong syndication endpoint ng X (cdn.syndication.twimg.com/tweet-result) ang post, gamit ang kaparehong signed token scheme na ginagamit ng embedded timeline. Dala ng tugon ang teksto ng post, ang author nito, at videos array na may bawat MP4 rendition na itinatago ng X para dito.

Mga video at GIF lang ang tinatago. Sa X, ang animated GIF ay ibinibigay bilang MP4 file, kaya ang GIF post ay nagda-download bilang video na walang tunog — na eksaktong itinago ng platform. Ang mga post kung saan live broadcast lang ang tanging video, o kung walang muxed MP4 na ibinabalik ang X, ay sumasagot ng no_video.

Paano binubuo ang mga label

• Kung pinapangalanan ng URL ng file ang laki ng frame (…/1280x720/…), ang label ay ang laki na iyon.
• Kung hindi, ang label ay ang bitrate na binilog sa kbps.
• Kung wala ang dalawa, ang row ay MP4 lang.
• Ang mga row ay pinagsunod-sunod ayon sa lapad, pinakamalapad muna — hindi ayon sa bitrate.

Mahalaga ang huling punto. Ang mga rendition ng X ay hindi makinis na ladder: ang isang post ay maaaring may 1280-pixel na file sa mababang bitrate at 720-pixel na file sa mas mataas na bitrate. Ang mas malapad na file ay mas malaki sa screen; ang mas maliit ay maaaring mas magandang tingnan sa paggalaw, dahil mas maraming bit ang ginagastos sa bawat pixel.

Isang gawang paghahambing

Isang praktikal na tuntunin: piliin ang pinakamalapad na row maliban kung mukha itong malabo kumpara sa susunod na mas mababa. Kapag hindi sigurado, mag-download ng dalawa at ihambing ang laki ng file — ang file na doble ang bigat sa kalahating laki ng frame ay ginagastos ang mga bit nito sa paggalaw at detalye.

Bakit navigation ang download, hindi progress bar

Nasa video.twimg.com ang mga video file, na hindi nagpapadala ng CORS header para sa ganitong uri ng request. Kaya hindi mababasa ng page ang mga byte gamit ang script, kaya binubuksan ng button ng download ang CDN link nang direkta at ang browser mo ang nagse-save ng file. Ang upside, walang dumadaan sa site na ito; ang downside, walang percentage counter.

Ano ang hindi mada-download

Ang mga protected account, na-delete na post at age-restricted na post ay nagbabalik ng error, dahil itinatago mismo ng X ang mga ito sa mga anonymous na mambabasa. Hindi kailanman nagsi-sign in ang resolver at hindi nito nilalampasan iyon. Hindi rin mai-paste nang mag-isa ang mga video.twimg.com URL — nagsisimula ang resolver sa link ng post, dahil ang post payload lang ang nagpapangalan ng mga rendition.

Ang maikling bersyon

• Ang mga row ay pinagsunod-sunod ayon sa lapad ng frame, hindi ayon sa quality.
• Maaaring pareho ang resolution ng dalawang rendition at magkaiba ang bitrate; ang mas mabigat na file ay kadalasang mas magandang tingnan.
• Dumarating ang mga GIF post bilang MP4 file, dahil iyon ang itinago ng X.
• Mga pampublikong post lang — nananatiling nakatago ang protected at na-delete.
• Walang nakaimbak o ni-re-encode; direktang galing sa CDN ng X ang file.