Mercurial > mplayer.hg
changeset 1484:14af3106c359
updated
author | arpi |
---|---|
date | Sat, 11 Aug 2001 17:05:35 +0000 |
parents | 515e80bfa5be |
children | b895f95e7657 |
files | DOCS/tech/tech-hun.txt |
diffstat | 1 files changed, 34 insertions(+), 29 deletions(-) [+] |
line wrap: on
line diff
--- a/DOCS/tech/tech-hun.txt Sat Aug 11 13:09:40 2001 +0000 +++ b/DOCS/tech/tech-hun.txt Sat Aug 11 17:05:35 2001 +0000 @@ -74,11 +74,13 @@ na nézzuk tovább: 3. mplayer.c - igen, ő a főnök :) - az időzítes élég érdekesen van megoldva, főleg azért mert minden file- - formátumnál másképp kell/célszerű, és néha többféle képpen is lehet. + + Fő feladata a különböző modulok összekapcsolása, illetve az A-V + szinkron biztosítása. - van egy a_frame és egy v_frame nevű float változó, ez tárolja az épp - látható/hallható a/v pozícióját másodpercben. + Az adott stream aktuális pozíciója a megfelelo stream header + (sh_audio / sh_video) timer field-ben van. + (Régen ez volt az a_frame és egy v_frame nevű float változó) A lejátszó ciklus felépítése: while(not EOF) { @@ -132,19 +134,29 @@ Avi-nál sem egyszerű az élet. Ott a 'hivatalos' időzítési mód a BPS-alapú, azaz a headerben le van tárolva, hány tömörített audio - byte tartozik egy másodpercnyi (fps darab) képhez. - ez persze nem mindig működik... miért is működne :) - Ezért én megcsináltam, hogy az mpeg-nél használatos sectoronkénti - PTS értéket emulálom avi-ra is, azaz az AVI parser minden beolvasott - chunk-nál számol egy kamu PTS-t a frame-ek típusa alapján, és ez - alapjan idozitek. És van amikor ez működik jobban. - Persze itt még bejátszik az is, hogy AVI-nál általában előre - letárolnak egy nagyobb adag hangot, és csak utána kezdődik a kép. - Ezt persze bele kell számolni a késleltetésbe, ez az Initial PTS delay. - Ilyen persze 2 is van, az egyik a headerben le is van írva, és - nem nagyon használják. :) A másik sehol nincs leírva, de használják, - ezt csak mérni lehet... - + byte vagy chunk tartozik egy másodpercnyi (fps darab) képhez. + Az AVI stream headerben van 2 fontos mezo, a dwSampleSize, es + a dwRate/dwScale aránypár: + - Ha a dwSampleSize 0, akkor VBR stream, tehat nem konstans a + bitrate. Ilyenkor 1 chunk tarol 1 sample-t, es a masodpercenkenti + chunkok szamat adja a dwRate/dwScale. + - Ha a dwSampleSize>0, akkor constant bitrate van, es az ido igy + szamolhato: time = (bytepos/dwSampleSize) / (dwRate/dwScale) + (tehat a sample sorszamat elosztjuk a samplerate-el) + Ilyenkor stream-kent kezelheto az audio, ami tetszolegesen + chunk-okra van darabolva, de lehet akar 1 db chunk is az egesz. + + A másik lehetőség csak az interleaved fileoknál használható: a + chunk-ok sorrendjéből számolható egy timestamp (PTS) érték. + A video chunkok PTS-e egyszerű: chunk száma * fps + Az audio pedig az előtte levő video chunk-éval azonos. + Ilyenkor viszont szamolni kell az ugynev. "audio preload"-al is, + azaz van egy fix kesleltetes az audio es video stream-ek kozott. + Ez altalaban 0.5-1.0 sec, de van amikor egeszen mas. + A pontos erteket regen mertuk, most a demux_avi.c kezeli le: + az elso video utani audio chunknal kiszamolja az A-V elterest, + es ezt veszi az audio preload mertekenek. + 3.a. audio playback: pár szó az audio lejátszásról: az egészben nem maga a lejátszás a nehéz, hanem: @@ -168,18 +180,11 @@ 4. codecek. ezek különböző lib-ek szanaszét mindenfelől. mint pl. libac3, libmpeg2, xa/*, alaw.c, opendivx/*, loader, mp3lib. - az mplayer.c hívogatja őket, amikor egy-egy darab hangot vagy frame-et - kell lejátszani (lásd 3. pont elején). - ezek pedig hívják a megfelelő demuxert, hogy megkapják a tömörített - adatokat (lásd 2. pont). - paraméterként a megfelelő stream headert (sh_audio/sh_video) kell - átadni, ez elvileg tartalmaz minden infót, ami szükséges a - dekódoláshoz (többek között a demuxert is: sh->ds). - A codecek szeparálasa folyamatban van, az audio már el van különítve - (lásd. dec_audio.c), a videon még dolgozunk. Cél, hogy ne az mplayer.c - kelljen tudja, milyen codecek vannak és hogy kell őket használni, hanem - egy közös init/decode audio/video functiont kelljen csak meghívnia. - + + Az mplayer.c nem kozvetlenul hivja oket, hanem a dec_audio.c es a + dec_video.c fileokon keresztul, igy az mplayer.c-nek nem kell semmit + sem tudnia a codecrol. + 5. libvo: ez végzi a kép kirakását. Az img_format.h-ban definiálva vannak konstansok a különböző pixel-