Ang Time Base ay ang yunit ng oras na binibilang ng isang stream. Sa halip na mag-imbak ng timestamp sa segundo, ang isang media file ay nagbibilang sa mga tick ng sarili nitong orasan, at ang time base ang nagsasabi kung gaano katagal ang isang tick. Isinusulat ito bilang isang bahagi (fraction) ng isang segundo.
Aling mga file ang naglalaman nito at saan nagmula ang halaga
Makikita mo ang time base sa bawat hiwalay na stream sa loob ng mga media file - ang larawan, tunog at anumang subtitle sa MP4, MOV, MKV, WebM, AVI at MPEG transport streams, pati na rin sa mga standalone na audio file. Bawat stream ay may sarili nitong time base, kaya ang audio at video sa isang file ay kadalasang nagbibilang sa magkaibang yunit.
Ang halaga ay pinipili ng encoder o ng programang bumuo ng file. May ilang container format na nangangailangan ng partikular na time base at nakapirmi na ito; kung bukas ang pagpipilian sa format, ang programang sumusulat ng file ang pipili ng angkop sa nilalaman, at maaaring nakalagay lang sa file ang default ng programang iyon.
Kung ano ang itsura ng value
Ito ay laging isang fraction, at ang bilang sa ibaba ay ang bilang ng ticks bawat segundo:
1/1000- isang millisecond bawat tick, karaniwang pagpipilian sa mga Matroska at WebM file1/90000- matagal nang ginagamit sa MPEG transport streams1/48000- madalas binibilang sa samples ang mga audio stream, kaya tumutugma ang time base sa sampling rate1/12800- halagang madalas makita sa mga video stream sa MP4 files
Para gawing segundo ang isang timestamp, imultiplika ito sa fraction. Ang presentation timestamp na 12800 sa isang stream na may time base na 1/12800 ay eksaktong isang segundo sa loob; sa time base na 1/1000, ang timestamp na 3500 ay tatlo at kalahating segundo sa loob. Ito ang dahilan kung bakit mukhang napakalalaki ng raw timestamps sa isang ulat - bilang ng ticks ang mga ito, hindi segundo. Maaaring magpakita rin ang mas lumang mga app ng hiwalay na Codec Time Base na hanay kasabay nito.
Bakit ito mahalaga
Lahat ng nangyayari sa isang media file ay nasa buo at di-basag na bilang ng ticks, kaya ang time base ang nagtatakda ng pinakapinong timing na kayang ipahayag ng stream. Kung ang isang frame o sample ay pumuwesto sa pagitan ng dalawang tick, kailangan i-round ang timestamp nito, at naiipon ang mga error sa pag-round.
Totoong problema ito sa mga video frame rate na hindi buumbilang. Sa broadcast rate na 30000 frame sa bawat 1001 segundo, ang isang frame ay tumatagal nang bahagyang lampas sa 33 milliseconds pero hindi eksaktong buumbilang nito, kaya hindi kayang ipuwesto nang eksakto ng millisecond na time base ang anumang frame. Ang time base na may mas maraming ticks bawat segundo - mas malaking bilang sa ilalim ng fraction - ay kayang pumuwesto nang eksakto sa bawat hangganan ng frame, kaya mas gusto ng mga encoder ang mga halagang gaya ng 1/12800 o 1/90000 kaysa simpleng milliseconds.
Lumalabas ang mga epekto nito bilang mga pagkakamali sa timing, hindi bilang anumang makikita mo sa isang frame lang: dahan-dahang paglayo ng tunog sa tamang sabay sa larawan, hindi pantay na pagitan ng mga frame, isang cut o seek na pumapaling nang kaunti. Kapag pinagsama ang mga file na ang mga stream ay nagbibilang sa magkaibang time base, kailangang i-rescale lahat ng timestamp, at ang conversion na iyon ay klasikong pinagmumulan ng mga bug sa synchronisation. Wala itong direktang epekto sa kalidad ng larawan o tunog, at wala rin itong anumang personal na impormasyon.