|
86
|
1 Nos, akkor leirom, hogyan is működik ez az egész.
|
|
|
2
|
|
|
3 A fő modulok:
|
|
|
4
|
|
861
|
5 1. streamer.c: ez az input layer, azaz ez olvassa a filet, VCD-t vagy stdin-t.
|
|
544
|
6 amit tudnia kell: megfelelő sectoronkenti bufferelés, seek, skip funkciók,
|
|
86
|
7 byte-onkénti ill. tetszőleges méretű blockonkénti olvasás.
|
|
|
8 Egy stream (input device/file) leírására a stream_t struktura szolgál.
|
|
|
9
|
|
|
10 2. demuxer.c: ez végzi az input szétszedését audio és video csatornákra,
|
|
861
|
11 és a kiválasztott csatornák bufferelt package-enkénti olvasását.
|
|
86
|
12 A demuxer.c inkább csak egy framework, ami közös minden input
|
|
|
13 formátumra, és az egyes formátumokhoz (mpeg-es,mpeg-ps, avi, avi-ni, asf)
|
|
|
14 külön parser van, ezek a demux_*.c fileokban vannak.
|
|
|
15 A hozza tartozo struktura a demuxer_t. osszesen egy demuxer van.
|
|
|
16
|
|
544
|
17 2.a. demux_packet_t, azaz dp.
|
|
86
|
18 ez egy darab chunk-ot (avi) vagy packet-et (asf,mpg) tartalmaz.
|
|
|
19 memoriaban ezek lancolt listaban vannak, mivel kulonbozo meretuek.
|
|
|
20
|
|
861
|
21 2.b. demuxer stream, azaz ds.
|
|
|
22 struct: demux_stream_t
|
|
544
|
23 minden egyes csatornahoz (a/v) tartozik egy ilyen.
|
|
|
24 ez tartalmazza a stream-hez tartozo packeteket (lasd. 2.a.)
|
|
861
|
25 egyelore demuxer-enkent 3 ilyen lehet:
|
|
|
26 - hang (d_audio)
|
|
|
27 - kep (d_video)
|
|
|
28 - DVD felirat (d_dvdsub)
|
|
544
|
29
|
|
|
30 2.c. stream header. 2 fele van (egyelore): sh_audio_t es sh_video_t
|
|
|
31 ez tartalmaz minden, a dekodolashoz szukseges parametert, igy az input
|
|
|
32 es output buffereket, kivalasztott codecet, fps/framerate stb adatokat.
|
|
|
33 Annyi van belole, ahany stream van a fileban tarolva. Lesz minimum egy
|
|
|
34 a videohoz, ha van hang akkor ahhoz is, de ha tobb audio/video stream
|
|
|
35 is van, akkor mindegyikhez lesz egy ilyen struct.
|
|
|
36 Ezeket avi/asf eseten a header alapjan tolti fel a header beolvaso,
|
|
|
37 mpeg eseten pedig a demux_mpg.c fogja letrehozni ha egy uj streamet
|
|
|
38 talal. Uj stream eseten ====> Found audio/video stream: <id> jelenik meg.
|
|
|
39
|
|
|
40 A kivalasztott stream header es a hozza tartozo demuxer stream kolcsonosen
|
|
|
41 hivatkoznak egymasra (ds->sh es sh->ds) az egyszerubb hasznalat miatt.
|
|
|
42 (igy a funkciotol fuggoen eleg vagy csak a ds vagy csak az sh atadasa)
|
|
|
43
|
|
|
44 Pelda: van egy .asf fileunk, abban 6 db stream, ebbol 1 audio es 5 video.
|
|
|
45 A header beolvasasakor letre fog jonni 6 db sh struct, 1 audio es 5 video.
|
|
861
|
46 Amikor elkezdi olvasni a packeteket, az elso talalt audio es video
|
|
|
47 packethez tartozo streamet
|
|
544
|
48 kivalasztja, es ezekre allitja be a d_audio es d_video sh pointereit.
|
|
|
49 Igy kesobbiekben mar csak ezeket a streameket olvassa, a tobbit nem.
|
|
|
50 Persze ha az user masik streameket szeretne kivalasztani, akkor
|
|
|
51 force-olhatja a -aid es -vid kapcsolokkal.
|
|
|
52 Jo pelda erre a DVD, ahol nem mindig az angol szinkron hang az elso
|
|
|
53 megtalalt stream, es igy random minden vob mas nyelven szolalhat meg :)
|
|
|
54 Ilyenkor kell pl. az -aid 128 kaocsolot hasznalni.
|
|
|
55
|
|
86
|
56 hogy is muxik ez a beolvasosdi?
|
|
|
57 - meghivodik a demuxer.c/demux_read_data(), megkapja melyik ds-bol
|
|
|
58 (audio vagy video), mennyi byteot es hova (memoriacim) szeretnenk
|
|
|
59 beolvasni. ezt hivogatjak gyakorlatilag a codec-ek.
|
|
861
|
60 - ez megnezi,hogy az adott ds bufferében van-e valami, ha igen akkor
|
|
86
|
61 onnan olvas amennyit kell. ha nincs/nincs eleg, akkor meghivja
|
|
|
62 a ds_fill_buffer()-t ami:
|
|
|
63 - megnezi hogy az adott ds-ben vannak-e bufferelve csomagok (dp-k)
|
|
|
64 ha igen, akkor a legregebbit atrakja a bufferbe es olvas tovabb.
|
|
|
65 ha ures a lancolt lista, akkor meghivja a demux_fill_buffer()-t:
|
|
861
|
66 - ez az input formatumnak megfelelo parser-t meghivja ami olvassa
|
|
86
|
67 tovabb a filet, es a talalt csomagokat rakja be a megfelelo bufferbe.
|
|
861
|
68 na ha mondjuk audio csomagot szeretnenk, de csak egy rakat video csomag
|
|
86
|
69 van, akkor jon elobb-utobb a DEMUXER: Too many (%d in %d bytes) audio
|
|
|
70 packets in the buffer... hibauzenet.
|
|
|
71
|
|
|
72 Eddig kb tiszta ugy, ezt akarom majd atrakni kulon lib-be.
|
|
|
73
|
|
|
74 na nezzuk tovabb:
|
|
|
75
|
|
|
76 3. mplayer.c - igen, o a fonok :)
|
|
|
77 az idozites eleg erdekesen van megoldva, foleg azert mert minden
|
|
|
78 fileformatumnal maskepp kell/celszeru, es neha tobbfele keppen is lehet.
|
|
861
|
79
|
|
86
|
80 van egy a_frame es egy v_frame nevu float valtozo, ez tarolja az epp
|
|
|
81 lathato/hallhato a/v poziciojat masodpercben.
|
|
861
|
82
|
|
|
83 A lejatszo ciklus felepitese:
|
|
|
84 while(not EOF) {
|
|
|
85 fill audio buffer (read & decode audio) + increase a_frame
|
|
|
86 read & decode a single video frame + increase v_frame
|
|
|
87 sleep (wait until a_frame>=v_frame)
|
|
|
88 display the frame
|
|
|
89 apply A-V PTS correction to a_frame
|
|
|
90 check for keys -> pause,seek,...
|
|
|
91 }
|
|
|
92
|
|
86
|
93 amikor lejatszik (hang/kep) akkor a lejatszott valami idotartamaval
|
|
861
|
94 noveli a megfelelo valtozot:
|
|
|
95 - audional ez a lejatszott byteok / sh_audio->o_bps
|
|
|
96 megj: i_bps = tomoritett byteok szama egy masodpercnyi hanghoz
|
|
|
97 o_bps = tomoritetlen byteok szama egy masodpercnyi hanghoz
|
|
|
98 (ez utobbi == bps*samplerate*channels)
|
|
|
99 - videonal ez altalaban az sh_video->frametime.
|
|
|
100 Ez altalaban == 1.0/fps, persze meg kell jegyeznem hogy videonal nem
|
|
|
101 igazan szamit az fps, asf-nel pl. nincs is olyan, ahelyett duration
|
|
|
102 van es framenkent valtozhat.
|
|
86
|
103 mpeg2-nel pedig repeat_count van ami 1-2.5 idotartamban elnyujtja
|
|
|
104 a framet... avi-nal van talan egyedul fix fps, meg mpeg1-nel.
|
|
|
105
|
|
|
106 Na most ez addig nagyon szepen mukodik, amig a hang es kep tokeletes
|
|
|
107 szinkronban van, mivel igy vegulis a hang szol, az adja az idozitest,
|
|
|
108 es amikor eltelt egy framenyi ido akkor kirakja a kovetkezo framet.
|
|
|
109 de mi van ha valamiert az input fileban csuszik a ketto?
|
|
|
110 Akkor jon be a PTS correction. az input demuxer-ek olvassak a csomagokkal
|
|
|
111 egyutt a hozzajuk tartozo PTS-t (presentation timestamp) is, ami alapjan
|
|
|
112 eszreveheto ha el van csuszva a ketto. ilyenkor egy megadott maximalis
|
|
87
|
113 hataron (lasd -mc opcio) belul kepes az mplayer korrigalni az a_frame
|
|
86
|
114 erteket. a korrekciok osszege van a c_total-ban.
|
|
|
115
|
|
|
116 persze ez meg nem minden szinkron ugyben, van meg nemi gaz.
|
|
|
117 pl. az hogy a hangkartya eleg rendesen kesleltet, ezt az mplayernek
|
|
861
|
118 korrigalnia kell! Az osszes audio kesleltetes masodpercben ezek osszege:
|
|
|
119 - az utolso timestamp (PTS) ota beolvasott byteok:
|
|
|
120 t1 = d_audio->pts_bytes/sh_audio->i_bps
|
|
|
121 - Win32/ACM eseten az audio input bufferben tarolt byteok:
|
|
|
122 t2 = a_in_buffer_len/sh_audio->i_bps
|
|
|
123 - az audio out bufferben tarolt tomoritetlen byteok:
|
|
|
124 t3 = a_buffer_len/sh_audio->o_bps
|
|
|
125 - a hangkartya buffereben (vagy DMA bufferben) tarolt, meg nem
|
|
|
126 lejatszott byteok:
|
|
|
127 t4 = get_audio_delay()/sh_audio->o_bps
|
|
86
|
128
|
|
861
|
129 Ezekbol kiszamolhato egeszen pontosan, hogy az epp hallhato hanghoz
|
|
|
130 milyen PTS tartozik, majd ezt osszevetve a video-hoz tartozo PTS-el
|
|
|
131 meg is kapjuk az A-V eltereset!
|
|
86
|
132
|
|
|
133 avi-nal sem egyszeru az elet. ott a 'hivatalos' idozitesi mod a
|
|
87
|
134 BPS-alapu, azaz a headerben le van tarolva hany tomoritett audio
|
|
86
|
135 byte tartozik egy masodpercnyi (fps darab) kephez.
|
|
|
136 ez persze nem mindig mukodik... miert is mukodne :)
|
|
87
|
137 ezert en megcsinaltam hogy az mpeg-nel hasznalatos sectoronkenti
|
|
86
|
138 PTS erteket emulalom avi-ra is, azaz az AVI parser minden beolvasott
|
|
|
139 chunk-nal szamol egy kamu PTS-t a framek tipusa alapjan. es ez
|
|
|
140 alapjan idozitek. es van amikor ez mukodik jobban.
|
|
|
141 persze itt meg bejatszik az is, hogy AVI-nal altalaban elore letarolnak
|
|
|
142 egy nagyobb adag hangot, es csak utana kezdodik a kep. ezt persze
|
|
|
143 bele kell szamolni a kesleltetesbe, ez az Initial PTS delay.
|
|
|
144 ilyen persze 2 is van, az egyik a headerben le is van irva, es
|
|
|
145 nem nagyon hasznlajak :) a masik sehol nincs leirva de hasznaljak, ezt
|
|
|
146 csak merni lehet...
|
|
861
|
147
|
|
|
148 3.a. audio playback:
|
|
|
149 par szo az audio lejatszasrol:
|
|
|
150 az egeszben nem maga a lejatszas a nehez, hanem:
|
|
|
151 1. hogy tudjuk mikor lehet irni a bufferbe, blocking nelkul
|
|
|
152 2. hogy tudjuk, mennyit jatszott mar le abbol amit a bufferbe irtunk
|
|
|
153 Az 1. az audio dekodolashoz kell, valamint hogy a buffert mindig teli
|
|
|
154 allapotban tudjuk tartani (igy sose fog megakadni a hang).
|
|
|
155 A 2. pedig a korrekt idoziteshez szukseges, ugyanis nemely hangkartya
|
|
|
156 akar 3-7 masodpercet is kesleltet, ami azert nem elhanyagolhato!
|
|
|
157 Ezek megvalositasara az OSS tobbfele lehetoseget is kinal:
|
|
|
158 - ioctl(SNDCTL_DSP_GETODELAY): megmondja hany lejatszatlan byte
|
|
|
159 varakozik a hangkartya bufferjeben -> idoziteshez kivallo,
|
|
|
160 de nem minden driver tamogatja :(
|
|
|
161 - ioctl(SNDCTL_DSP_GETOSPACE): megmondja mennyit irhatunk a kartya
|
|
|
162 bufferebe blocking nelkul. ha a driver nem tudja a GETODELAY-t,
|
|
|
163 akkor ezt hasznalhatjuk arra is, hogy megtudjuk a kesleltetest.
|
|
|
164 - select(): meg kene mondja, hogy irhatunk-e a kartya bufferebe
|
|
|
165 blocking nelkul. azt, hogy emnnyit irhatunk, nem mondja meg :(
|
|
|
166 valamint sok driverrel egyaltalan nem, vagy rosszul mukodik :((
|
|
|
167 csak akkor hasznalom, ha egyik fenti ioctl() sem mukodik.
|
|
|
168
|
|
86
|
169 4. codecek. ezek kulonbozo lib-ek szanaszet mindenfelol.
|
|
|
170 mint pl. libac3, libmpeg2, xa/*, alaw.c, opendivx/*, loader, mp3lib.
|
|
|
171 az mplayer.c hivogatja oket amikor egy egy darab hangot vagy framet
|
|
544
|
172 kell lejatszani (lasd 3. pont elejen).
|
|
86
|
173 ezek pedig hivjak a megfelelo demuxert hogy megkapjak a tomoritett
|
|
|
174 adatokat (lasd 2. pont).
|
|
544
|
175 parameterkent a megfelelo stream headert (sh_audio/sh_video) kell
|
|
|
176 atadni, ez elvileg tartalmaz minden infot ami szukseges a
|
|
|
177 dekodolashoz (tobbek kozott a demuxert is: sh->ds).
|
|
|
178 A codecek szeparalasa folyamatban van, az audio mar el van kulonitve
|
|
|
179 (lasd. dec_audio.c), a videon meg dolgozunk. Cel, hogy ne az mplayer.c
|
|
|
180 kelljen tudja milyen codecek vannak es hogy kell oket hasznalni, hanem
|
|
|
181 egy kozos init/decode audio/video functiont kelljen csak meghivnia.
|
|
86
|
182
|
|
544
|
183 5. libvo: ez vegzi a kep kirakasat.
|
|
|
184
|
|
|
185 Az img_format.h-ban definialva vannak konstansok a kulonbozo pixel-
|
|
|
186 formatumokhoz, ezeket kotelezo hasznalni.
|
|
|
187
|
|
|
188 1-1 vo driver a kovetkezoket kell kotelezoen implementalja:
|
|
|
189
|
|
|
190 query_format() - lekerdezi hogy egy adott pixelformat tamogatott-e.
|
|
|
191 return value: flags:
|
|
|
192 0x1 - supported (by hardware or with conversion)
|
|
|
193 0x2 - supported (by hardware, without conversion)
|
|
|
194 0x4 - sub/osd supported (has draw_alpha)
|
|
|
195 FONTOS: minden vo driver kotelezo tamogassa az YV12 formatumot, es
|
|
|
196 egyiket (vagy mindkettot) a BGR15 es BGR24 kozul, ha kell, konvertalassal.
|
|
|
197 Ha ezeket nem tamogatja, akkor nem fog minden codec-kel mukodni!
|
|
|
198 Ennek az az oka, hogy az mpeg codecek csak YV12-t tudnak eloallitani,
|
|
|
199 a regebbi Win32 DLL codecek pedig csak 15 es 24bpp-t tudnak.
|
|
|
200 Van egy gyors MMX-es 15->16bpp konvertalo, igy az nem okoz kulonosebb
|
|
|
201 sebessegcsokkenest!
|
|
|
202
|
|
|
203 A BPP tablazat, ha a driver nem tud bpp-t valtani:
|
|
|
204 jelenlegi bpp: ezeket kell elfogadni:
|
|
|
205 15 15
|
|
|
206 16 15,16
|
|
|
207 24 24
|
|
|
208 24,32 24,32
|
|
|
209
|
|
|
210 Ha tud bpp-t valtani (pl. DGA 2, fbdev, svgalib) akkor ha lehet, be kell
|
|
|
211 valtani a kert bpp-re. Ha azt a hardver nem tamogatja, akkor a legkozelebbi
|
|
|
212 modra (15 eseten 16-ra, 24 eseten 32-re) kell valtani es konvertalni!
|
|
|
213
|
|
|
214 init() - ez hivodik meg a legelso frame kirakasa elott - bufferek foglalasa
|
|
|
215 stb a celja.
|
|
861
|
216 van egy flags parameter is (regen fullscreen volt a neve):
|
|
|
217 0x01 - fullscreen (-fs)
|
|
|
218 0x02 - vidmode switch (-vm)
|
|
|
219 0x04 - scaling enabled (-zoom)
|
|
|
220 0x08 - flip image (upside-down)
|
|
544
|
221
|
|
|
222 draw_slice(): ez planar YV12 kepet rak ki (3 db plane, egy teljes
|
|
|
223 meretu ami a fenyerot (Y) tartalmazza, es 2 negyedakkora, ami a
|
|
|
224 szin (U,V) infot). ezt hasznaljak az mpeg codecek (libmpeg2,opendivx).
|
|
86
|
225 ez mar tud olyat hogy nem az egesz kep kirakasa, hanem csak kis
|
|
|
226 reszletek updatelese: ilyenkor a sarkanak es a darabka meretenek
|
|
|
227 megadasaval lehet csinalni.
|
|
544
|
228
|
|
|
229 draw_frame(): ez a regebbi interface, ez csak komplett framet rak ki,
|
|
|
230 es csak packed formatumot (YUY2 stb, RGB/BGR) tud.
|
|
86
|
231 ezt hasznaljak a win32 codecek (divx,indeo stb).
|
|
|
232
|
|
544
|
233 draw_alpha(): ez rakja ki a subtitle-t es az OSD-t.
|
|
|
234 hasznalata kicsit cseles, mivel ez nem a libvo API resze, hanem egy
|
|
|
235 callback jellegu cucc. a flip_page() kell meghivja a vo_draw_text()-et
|
|
|
236 ugy, hogy parameterkent atadja a kepernyo mereteit es a pixelformatumnak
|
|
|
237 megfelelo draw_alpha() implementaciot (function pointer).
|
|
|
238 Ezutan a vo_draw_text() vegigmegy a kirajzolando karaktereken, es egyenkent
|
|
|
239 meghivja minden karakterre a draw_alpha()-t.
|
|
|
240 Segitseg keppen az osd.c-ben meg van irva a draw_alpha mindenfele
|
|
|
241 pixelformatumhoz, ha lehet ezt hasznald!
|
|
|
242
|
|
|
243 flip_page(): ez meghivodik minden frame utan, ez kell tenylegesen
|
|
|
244 megjelenitse a buffert. double buffering eseten ez lesz a 'swapbuffers'.
|
|
|
245
|
|
971
|
246 6. libao2: ez vezerli a hang lejatszast
|
|
544
|
247
|
|
971
|
248 A libvo-hoz (lasd 5.) hasonloan itt is kulonbozo driverek vannak, amik
|
|
|
249 egy kozos API-t (interface) valositanak meg:
|
|
|
250
|
|
|
251 static int control(int cmd,int arg);
|
|
|
252 Ez egy altalanos celu fuggveny, a driverfuggo es egyeb specialis parameterek
|
|
|
253 olvasasara/beallitasara. Egyelore nem nagyon hasznalt.
|
|
544
|
254
|
|
971
|
255 static int init(int rate,int channels,int format,int flags);
|
|
|
256 Driver initje, ilyenkor kell megnyitni a devicet, beallitani samplerate,
|
|
|
257 channels, sample format parametereket.
|
|
|
258 Sample format: altalaban AFMT_S16_LE vagy AFMT_U8, tovabbi definiciokert
|
|
|
259 lasd. dec_audio.c ill. linux/soundcard.h fileok!
|
|
|
260
|
|
|
261 static void uninit();
|
|
|
262 talald ki.
|
|
|
263 na jo, segitek: lezarja a devicet, kilepeskor (meg nem) hivodik meg.
|
|
|
264
|
|
|
265 static void reset();
|
|
|
266 reseteli a devicet. egesz pontosan a bufferek torlesere szolgal,
|
|
|
267 tehat hogy a reset() utan mar ne szoljon tovabb az amit elotte kapott.
|
|
|
268 (pause ill. seek eseten hivodik meg)
|
|
|
269
|
|
|
270 static int get_space();
|
|
|
271 vissza kell adja hogy hany byte irhato az audio bufferbe anelkul hogy
|
|
|
272 blockolna (varakoztatna a hivo processt). amennyiben a buffer (majdnem)
|
|
|
273 tele van, 0-t kell visszaadni!
|
|
|
274 ha sosem ad vissza 0-at akkor nem fog mukodni az MPlayer!
|
|
|
275
|
|
|
276 static int play(void* data,int len,int flags);
|
|
|
277 lejatszik egy adag hangot, amit a data cimu memoriateruleten kap, es len
|
|
|
278 a merete. a flags meg nem hasznalt. az adatokat at kell masolnia, mert a
|
|
|
279 hivas utan felulirodhatnak! nem kell feltetlen minden byetot felhasznalni,
|
|
|
280 hanem azt kell visszaadnia mennyit hasznalt fel (masolt a bufferbe).
|
|
|
281
|
|
|
282 static int get_delay();
|
|
|
283 vissza kell adja hogy hany byte varakozik az audio bufferben. lehetoleg
|
|
|
284 minel pontosabban, mert ettol fugg az egesz idozites!
|
|
|
285 legrosszabb esetben adja vissza a buffer meretet.
|
|
|
286
|
|
|
287 !!! Mivel a kep a hanghoz (hangkartyahoz) van szinkronizalva, igy nagyon
|
|
986
|
288 !!! fontos hogy a get_space ill. get_delay fuggvenyek korrektul legyenek megirva!
|
|
971
|
289
|
