git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@1485 b3059339-0415-0410-9bf9-f77b7e298cf2
This commit is contained in:
arpi 2001-08-11 17:05:35 +00:00
parent 56cb8a2d3a
commit 5a09680795
1 changed files with 34 additions and 29 deletions

View File

@ -74,11 +74,13 @@ Eddig kb. tiszta
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.
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.
Fő feladata a különböző modulok összekapcsolása, illetve az A-V
szinkron biztosítása.
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 @@ na n
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 @@ na n
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-