mpv/DOCS/tech/tech-hun.txt

Nos, akkor le<6C>rom, hogyan is m<>k<EFBFBD>dik ez az eg<65>sz.

A f<> modulok:

1. streamer.c: ez az input layer, azaz ez olvassa a filet, VCD-t vagy stdin-t.
   amit tudnia kell: megfelel<65> sectoronk<6E>nti bufferel<65>s, seek, skip funkci<63>k,
	 byte-onk<6E>nti ill. tetsz<73>leges m<>ret<65> blockonk<6E>nti olvas<61>s.
	 Egy stream (input device/file) le<6C>r<EFBFBD>s<EFBFBD>ra a stream_t strukt<6B>ra szolg<6C>l.

2. demuxer.c: ez v<>gzi az input sz<73>tszed<65>s<EFBFBD>t audio <20>s video csatorn<72>kra,
   <20>s a kiv<69>lasztott csatorn<72>k bufferelt package-enk<6E>nti olvas<61>s<EFBFBD>t.
	 A demuxer.c ink<6E>bb csak egy framework, ami k<>z<EFBFBD>s minden input
	 form<72>tumra, <20>s az egyes form<72>tumokhoz (mpeg-es, mpeg-ps, avi, avi-ni,
	 asf) k<>l<EFBFBD>n parser van, ezek a demux_*.c file-okban vannak.
	 A hozz<7A> tartoz<6F> strukt<6B>ra a demuxer_t. <20>sszesen egy demuxer van.

2.a. demux_packet_t, azaz dp.
   ez egy darab chunk-ot (avi) vagy packet-et (asf, mpg) tartalmaz.
	 mem<65>ri<72>ban ezek l<>ncolt list<73>ban vannak, mivel k<>l<EFBFBD>nb<6E>z<EFBFBD> m<>ret<65>ek.

2.b. demuxer stream, azaz ds.
   struct: demux_stream_t
   minden egyes csatorn<72>hoz (a/v) tartozik egy ilyen.
	 ez tartalmazza a stream-hez tartoz<6F> packeteket (l<>sd. 2.a.)
	 egyel<65>re demuxer-enk<6E>nt 3 ilyen lehet:
	 - hang (d_audio)
	 - k<>p  (d_video)
	 - DVD felirat (d_dvdsub)

2.c. stream header. 2 f<>le van (egyel<65>re): sh_audio_t <20>s sh_video_t
   ez tartalmaz minden, a dek<65>dol<6F>shoz sz<73>ks<6B>ges param<61>tert, <20>gy az input
   <20>s output buffereket, kiv<69>lasztott codecet, fps/framerate stb adatokat.
   Annyi van bel<65>le, ah<61>ny stream van a file-ban t<>rolva. Lesz minimum egy
   a videohoz, ha van hang akkor ahhoz is, de ha t<>bb audio/video stream
   is van, akkor mindegyikhez lesz egy ilyen struct.
   Ezeket avi/asf eset<65>n a header alapj<70>n t<>lti fel a header beolvas<61>,
   mpeg eset<65>n pedig a demux_mpg.c fogja l<>trehozni, ha egy <20>j streamet
   tal<61>l. <20>j stream eset<65>n ====> Found audio/video stream: <id>  jelenik meg.

   A kiv<69>lasztott stream header <20>s a hozz<7A> tartoz<6F> demuxer stream k<>lcs<63>n<EFBFBD>sen
   hivatkoznak egym<79>sra (ds->sh <20>s sh->ds) az egyszer<65>bb haszn<7A>lat v<>gett.
   (<28>gy a funkci<63>t<EFBFBD>l f<>gg<67>en el<65>g vagy csak a ds vagy csak az sh <20>tad<61>sa)

   P<>lda: van egy .asf file-unk, abban 6 db stream, ebb<62>l 1 audio <20>s 5 video.
   A header beolvas<61>sakor l<>tre fog j<>nni 6 db sh struct, 1 audio <20>s 5 video.
   Amikor elkezdi olvasni a packeteket, az els<6C> tal<61>lt audio <20>s video
   packethez tartoz<6F> streamet kivalasztja, es ezekre allitja be a d_audio
   <20>s d_video sh pointereit.
   <20>gy a k<>s<EFBFBD>bbiekben m<>r csak ezeket a streameket olvassa, a t<>bbit nem.
   Persze, ha a user m<>sik streameket szeretne kiv<69>lasztani, akkor
   force-olhatja az -aid <20>s -vid kapcsol<6F>kkal.
   J<> pelda erre a DVD, ahol nem mindig az angol szinkron hang az els<6C>
   megtal<61>lt stream, <20>s <20>gy random minden vob m<>s nyelven sz<73>lalhat meg :)
   Ilyenkor kell pl. az -aid 128 kapcsol<6F>t haszn<7A>lni.

  hogy is m<>xik ez a beolvas<61>sdi?
	 - megh<67>v<EFBFBD>dik a demuxer.c/demux_read_data(), megkapja melyik ds-b<>l
	   (audio vagy video), mennyi byte-ot <20>s hova (mem<65>riac<61>m) szeretn<74>nk
		 beolvasni. Ezt h<>vogatj<74>k gyakorlatilag a codec-ek.
	 - ez megn<67>zi, hogy az adott ds buffer<65>ben van-e valami, ha igen akkor
	   onnan olvas, amennyit kell. Ha nincs/nincs el<65>g, akkor megh<67>vja
		 a ds_fill_buffer()-t ami:
	 - megn<67>zi, hogy az adott ds-ben vannak-e bufferelve csomagok (dp-k)
	   ha igen, akkor a legr<67>gebbit <20>trakja a bufferbe <20>s olvas tov<6F>bb. Ha
		 <20>res a l<>ncolt lista, akkor megh<67>vja a demux_fill_buffer()-t:
	 - ez az input form<72>tumnak megfelel<65> parser-t h<>vja meg, ami tov<6F>bbol-
	   vassa a file-t, <20>s a tal<61>lt csomagokat berakja a megfelel<65> bufferbe.
		 Na, ha mondjuk audio csomagot szeretn<74>nk, de csak egy rakat
		 video csomag van, akkor j<>n el<65>bb-ut<75>bb a DEMUXER: Too many
		 (%d in %d bytes) audio packets in the buffer... hiba<62>zenet.

Eddig kb. tiszta <20>gy, ezt akarom majd <20>trakni k<>l<EFBFBD>n lib-be.

na n<>zzuk tov<6F>bb:

3. mplayer.c - igen, <20> a f<>n<EFBFBD>k :)

    F<> feladata a k<>l<EFBFBD>nb<6E>z<EFBFBD> modulok <20>sszekapcsol<6F>sa, illetve az A-V
    szinkron biztos<6F>t<EFBFBD>sa.

    Az adott stream aktu<74>lis poz<6F>ci<63>ja a megfelelo stream header
    (sh_audio / sh_video) timer field-ben van.
    (R<>gen ez volt az a_frame <20>s egy v_frame nev<65> float v<>ltoz<6F>)

	 A lej<65>tsz<73> ciklus fel<65>p<EFBFBD>t<EFBFBD>se:
	 while(not EOF) {
	     fill audio buffer (read & decode audio) + increase a_frame
	     read & decode a single video frame + increase v_frame
	     sleep  (wait until a_frame>=v_frame)
	     display the frame
	     apply A-V PTS correction to a_frame
	     check for keys -> pause,seek,...
	 }

	 amikor lej<65>tszik (hang/k<>p) akkor a lej<65>tszott valami id<69>tartam<61>val
	 n<>veli a megfelel<65> v<>ltoz<6F>t:
	 - audion<6F>l ez a lej<65>tszott byte-ok / sh_audio->o_bps
	 megj.: i_bps = t<>m<EFBFBD>r<EFBFBD>tett byte-ok sz<73>ma egy m<>sodpercnyi hanghoz
	        o_bps = t<>m<EFBFBD>r<EFBFBD>tetlen byte-ok sz<73>ma egy m<>sodpercnyi hanghoz
	            (ez ut<75>bbi == bps*samplerate*channels)
	 - videon<6F>l ez <20>ltal<61>ban az sh_video->frametime.
	 Ez <20>ltal<61>ban == 1.0/fps, persze meg kell jegyeznem, hogy videon<6F>l nem
	 igaz<61>n sz<73>m<EFBFBD>t az fps, asf-n<>l pl. nincs is olyan, ahelyett duration
	 van <20>s frame-enk<6E>nt v<>ltozhat.
	 mpeg2-n<>l pedig repeat_count van, ami 1-2.5 id<69>tartamban elny<6E>jtja
	 a frame-et... avi-n<>l van tal<61>n egyed<65>l fix fps, meg mpeg1-n<>l.

	 Na most ez addig nagyon sz<73>pen m<>k<EFBFBD>dik, am<61>g a hang <20>s k<>p t<>k<EFBFBD>letes
	 szinkronban van, mivel <20>gy v<>g<EFBFBD>lis a hang sz<73>l, az adja az id<69>z<EFBFBD>t<EFBFBD>st,
	 <20>s amikor eltelt egy frame-nyi id<69>, akkor kirakja a k<>vetkez<65> frame-et.
	 De mi van, ha valami<6D>rt az input file-ban cs<63>szik a kett<74>?
	 Akkor j<>n be a PTS correction. Az input demuxer-ek olvass<73>k a
	 csomagokkal egy<67>tt a hozz<7A>juk tartoz<6F> PTS-t (presentation timestamp)
	 is, ami alapj<70>n <20>szrevehet<65>, ha el van cs<63>szva a kett<74>. Ilyenkor egy
	 megadott maxim<69>lis hat<61>ron (l<>sd -mc opci<63>) bel<65>l k<>pes az mplayer
	 korrigalni az a_frame <20>rt<72>k<EFBFBD>t. A korrekci<63>k <20>sszege van a c_total-ban.

	 Persze ez m<>g nem minden szinkron <20>gyben, van m<>g n<>mi g<>z. Pl. az,
	 hogy a hangk<67>rtya el<65>g rendesen k<>sleltet, ezt az mplayernek korrig<69>lnia
	 kell! Az <20>sszes audio k<>sleltet<65>s m<>sodpercben ezek <20>sszege:
	 - az utols<6C> timestamp (PTS) <20>ta beolvasott byte-ok:
	   t1 = d_audio->pts_bytes/sh_audio->i_bps
	 - Win32/ACM eset<65>n az audio input bufferben t<>rolt byte-ok:
	   t2 = a_in_buffer_len/sh_audio->i_bps
	 - az audio out bufferben t<>rolt t<>m<EFBFBD>r<EFBFBD>tetlen byte-ok:
	   t3 = a_buffer_len/sh_audio->o_bps
	 - a hangk<67>rtya buffer<65>ben (vagy DMA bufferben) t<>rolt, m<>g nem
	   lej<65>tszott byte-ok:
	   t4 = get_audio_delay()/sh_audio->o_bps

	 Ezekb<6B>l kisz<73>molhat<61> eg<65>szen pontosan, hogy az <20>pp hallhat<61> hanghoz
	 milyen PTS tartozik, majd ezt <20>sszevetve a video-hoz tartozo PTS-el
	 meg is kapjuk az A-V elt<6C>r<EFBFBD>s<EFBFBD>t!

	 Avi-n<>l sem egyszer<65> az <20>let. Ott a 'hivatalos' id<69>z<EFBFBD>t<EFBFBD>si m<>d a
	 BPS-alap<61>, azaz a headerben le van t<>rolva, h<>ny t<>m<EFBFBD>r<EFBFBD>tett audio
	 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<61>nyp<79>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<65>s<EFBFBD>g csak az interleaved fileokn<6B>l haszn<7A>lhat<61>: a
	 chunk-ok sorrendj<64>b<EFBFBD>l sz<73>molhat<61> egy timestamp (PTS) <20>rt<72>k.
	 A video chunkok PTS-e egyszer<65>: chunk sz<73>ma * fps
	 Az audio pedig az el<65>tte lev<65> video chunk-<2D>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<73> az audio lej<65>tsz<73>sr<73>l:
	 az eg<65>szben nem maga a lej<65>tsz<73>s a neh<65>z, hanem:
	 1. hogy tudjuk, mikor lehet <20>rni a bufferbe, blocking n<>lk<6C>l
	 2. hogy tudjuk, mennyit j<>tszott m<>r le abb<62>l, amit a bufferbe <20>rtunk
	 Az 1. az audio dek<65>dol<6F>shoz kell, valamint hogy a buffert mindig teli
	 <20>llapotban tudjuk tartani (<28>gy sose fog megakadni a hang).
	 A 2. pedig a korrekt id<69>z<EFBFBD>t<EFBFBD>shez sz<73>ks<6B>ges, ugyanis n<>mely hangk<67>rtya
	 ak<61>r 3-7 m<>sodpercet is k<>sleltet, ami az<61>rt nem elhanyagolhat<61>!
	 Ezek megval<61>s<EFBFBD>t<EFBFBD>s<EFBFBD>ra az OSS t<>bbf<62>le lehet<65>s<EFBFBD>get is k<>n<EFBFBD>l:
	 - ioctl(SNDCTL_DSP_GETODELAY): megmondja, h<>ny lej<65>tszatlan byte
	   v<>rakozik a hangk<67>rtya buffer<65>ben -> id<69>z<EFBFBD>t<EFBFBD>shez kiv<69>l<EFBFBD>,
	   de nem minden driver t<>mogatja :(
	 - ioctl(SNDCTL_DSP_GETOSPACE): megmondja, mennyit <20>rhatunk a k<>rtya
	   buffer<65>be blocking n<>lk<6C>l. Ha a driver nem tudja a GETODELAY-t,
	   akkor ezt hasznalhatjuk arra is, hogy megtudjuk a k<>sleltet<65>st.
	 - select(): meg k<>ne mondja, hogy <20>rhatunk-e a k<>rtya buffer<65>be
	   blocking n<>lk<6C>l. Azt, hogy mennyit <20>rhatunk, nem mondja meg :(
	   valamint sok driverrel egy<67>ltal<61>n nem, vagy rosszul m<>k<EFBFBD>dik :((
	   csak akkor haszn<7A>lom, ha egyik fenti ioctl() sem m<>k<EFBFBD>dik.

4. codecek. ezek k<>l<EFBFBD>nb<6E>z<EFBFBD> lib-ek szanasz<73>t mindenfel<65>l.
   mint pl. libac3, libmpeg2, xa/*, alaw.c, opendivx/*, loader, mp3lib.
   
   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<61>s<EFBFBD>t.

  Az img_format.h-ban defini<6E>lva vannak konstansok a k<>l<EFBFBD>nb<6E>z<EFBFBD> pixel-
  form<72>tumokhoz, ezeket k<>telez<65> haszn<7A>lni.

  1-1 vo drivernek a k<>vetkez<65>ket kell k<>telez<65>en implement<6E>lnia:

  query_format()  - lek<65>rdezi, hogy egy adott pixelformat t<>mogatott-e.
                    return value:  flags:
		       0x1 - supported (by hardware or with conversion)
		       0x2 - supported (by hardware, without conversion)
		       0x4 - sub/osd supported (has draw_alpha)
  FONTOS: minden vo drivernek k<>telez<65> t<>mogatnia az YV12 form<72>tumot, <20>s
  egyiket (vagy mindkett<74>t) a BGR15 <20>s BGR24 k<>z<EFBFBD>l, ha kell, konvert<72>l<EFBFBD>ssal.
  Ha ezeket nem t<>mogatja, akkor nem fog minden codec-kel m<>k<EFBFBD>dni!
  Ennek az az oka, hogy az mpeg codecek csak YV12-t tudnak el<65><6C>ll<6C>tani,
  a r<>gebbi Win32 DLL codecek pedig csak 15 <20>s 24bpp-t tudnak.
  Van egy gyors MMX-es 15->16bpp konvert<72>l<EFBFBD>, <20>gy az nem okoz k<>l<EFBFBD>n<EFBFBD>sebb
  sebess<73>gcs<63>kken<65>st!

  A BPP t<>bl<62>zat, ha a driver nem tud bpp-t v<>ltani:
      jelenlegi bpp:    ezeket kell elfogadni:
           15                    15
	   16                    15,16
	   24                    24
	   24,32                 24,32

  Ha tud bpp-t v<>ltani (pl. DGA 2, fbdev, svgalib) akkor, ha lehet, be kell
  v<>ltani a k<>rt bpp-re. Ha azt a hardver nem t<>mogatja, akkor a legk<67>zelebbi
  m<>dra (15 eset<65>n 16-ra, 24 eset<65>n 32-re) kell v<>ltani <20>s konvert<72>lni!

  init() - ez h<>v<EFBFBD>dik meg a legels<6C> frame kirak<61>sa el<65>tt - bufferek foglal<61>sa
           stb a c<>lja.
	   van egy flags param<61>ter is (r<>gen fullscreen volt a neve):
	   0x01 - fullscreen (-fs)
	   0x02 - vidmode switch (-vm)
	   0x04 - scaling enabled (-zoom)
	   0x08 - flip image (upside-down)

  draw_slice(): ez planar YV12 k<>pet rak ki (3 db plane, egy teljes
	 m<>ret<65>, ami a f<>nyer<65>t (Y) tartalmazza, <20>s 2 negyedakkora, ami a
	 sz<73>n (U,V) inf<6E>t). ezt haszn<7A>lj<6C>k az mpeg codecek (libmpeg2, opendivx).
	 ez m<>r tud olyat, hogy nem az eg<65>sz k<>p kirak<61>sa, hanem csak kis
	 r<>szletek update-el<65>se: ilyenkor a sark<72>nak <20>s a darabka m<>ret<65>nek
	 megad<61>s<EFBFBD>val lehet haszn<7A>lni.

  draw_frame(): ez a r<>gebbi interface, ez csak komplett frame-et rak ki,
	 <20>s csak packed form<72>tumot (YUY2 stb, RGB/BGR) tud.
	 ezt haszn<7A>lj<6C>k a win32 codecek (divx, indeo stb).

  draw_alpha(): ez rakja ki a subtitle-t <20>s az OSD-t.
	 haszn<7A>lata kicsit cseles, mivel ez nem a libvo API r<>sze, hanem egy
	 callback jelleg<65> cucc. a flip_page() kell megh<67>vja a vo_draw_text()-et
	 <20>gy, hogy param<61>terk<72>nt <20>tadja a k<>perny<6E> m<>reteit <20>s a pixel-
	 form<72>tumnak megfelel<65> draw_alpha() implement<6E>ci<63>t (function pointer).
	 Ezut<75>n a vo_draw_text() v<>gigmegy a kirajzoland<6E> karaktereken, <20>s
	 egyenk<6E>nt megh<67>vja minden karakterre a draw_alpha()-t.
	 Seg<65>ts<74>g k<>ppen az osd.c-ben meg van <20>rva a draw_alpha mindenf<6E>le
	 pixelform<72>tumhoz, ha lehet ezt haszn<7A>ld!

  flip_page(): ez megh<67>v<EFBFBD>dik minden frame ut<75>n, ennek kell t<>nylegesen meg-
	 jelen<65>teni a buffert. double buffering eset<65>n ez lesz a 'swapbuffers'.

6. libao2: ez vez<65>rli a hang lej<65>tsz<73>st

  A libvo-hoz (l<>sd 5.) hasonl<6E>an itt is k<>l<EFBFBD>nb<6E>z<EFBFBD> driverek vannak, amik
  egy k<>z<EFBFBD>s API-t (interface) val<61>s<EFBFBD>tanak meg:

static int control(int cmd,int arg);
  Ez egy <20>ltal<61>nos c<>l<EFBFBD> f<>ggv<67>ny, a driverf<72>gg<67> <20>s egy<67>b speci<63>lis param<61>terek
  olvas<61>s<EFBFBD>ra/be<62>ll<6C>t<EFBFBD>s<EFBFBD>ra. Egyel<65>re nem nagyon haszn<7A>lt.

static int init(int rate,int channels,int format,int flags);
  Driver initje, ilyenkor kell megnyitni a device-t, be<62>ll<6C>tani samplerate,
  channels, sample format param<61>tereket.
  Sample format: <20>ltal<61>ban AFMT_S16_LE vagy AFMT_U8, tov<6F>bbi defin<69>ci<63>k<EFBFBD>rt
  l<>sd. dec_audio.c ill. linux/soundcard.h file-okat!

static void uninit();
  Tal<61>ld ki!
  Na j<>, seg<65>tek: lez<65>rja a device-t, kil<69>p<EFBFBD>skor (m<>g nem) h<>v<EFBFBD>dik meg.

static void reset();
  Reseteli a device-t. Eg<45>sz pontosan a bufferek t<>rl<72>s<EFBFBD>re szolg<6C>l,
  teh<65>t hogy a reset() ut<75>n m<>r ne sz<73>ljon tov<6F>bb az, amit el<65>tte kapott.
  (pause ill. seek eset<65>n h<>v<EFBFBD>dik meg)

static int get_space();
  Vissza kell adja, hogy h<>ny byte <20>rhat<61> az audio bufferbe an<61>lk<6C>l, hogy
  blockolna (v<>rakoztatn<74> a h<>v<EFBFBD> processt). Amennyiben a buffer (majdnem)
  tele van, 0-t kell visszaadni!
  Ha sosem ad vissza 0-t, akkor nem fog m<>k<EFBFBD>dni az MPlayer!

static int play(void* data,int len,int flags);
  Lej<65>tszik egy adag hangot, amit a data c<>m<EFBFBD> mem<65>riater<65>leten kap <20>s len
  a m<>rete. a flags m<>g nem haszn<7A>lt. Az adatokat <20>t kell m<>solnia, mert a
  h<>v<EFBFBD>s ut<75>n fel<65>l<EFBFBD>r<EFBFBD>dhatnak! Nem kell felt<6C>tlen minden byte-ot felhaszn<7A>lni,
  hanem azt kell visszaadnia, mennyit haszn<7A>lt fel (m<>solt a bufferbe).

static int get_delay();
  Visszaadja meddig fog tartani az <20>ppen az audio bufferben lev<65> adat
  lej<65>tsz<73>sa. Lehet<65>leg min<69>l pontosabban, mert ett<74>l f<>gg az eg<65>sz id<69>z<EFBFBD>t<EFBFBD>s! 
  Legrosszabb esetben adja vissza a maxim<69>lis id<69>z<EFBFBD>t<EFBFBD>st.

!!! Mivel a k<>p a hanghoz (hangk<67>rty<74>hoz) van szinkroniz<69>lva, <20>gy nagyon fontos,
!!! hogy a get_space ill. get_delay f<>ggv<67>nyek korrekt<6B>l legyenek meg<65>rva!

6.a Audio plugin-ek
  Rem<65>lem tudsz angolul.