[Mplayer-felhasznalok] RAW RGB AVI lejatszas. (harmadik
Arpi
arpi at thot.banki.hu
Wed May 29 21:51:45 CEST 2002
Hi,
> > > AVI az DIB-ek sorozata.
> > Az latod lehet. Meg kene neznem DIB/BMP doxokat...
>
> http://www.wotsit.org-on van jó.
az a site meg letezik? :))
> > > > a kerdes inkabb az, hogy hol van ez az avi-ban tarolva???
> > > Implicit van tarolva. Az AVI tartalmazza a kepkocka meretet.
> > > Ezutan raengeded a CODEC-et ;) amely DIB-kent ertelmezi es jol kiszamolj
> a
> > > a sorhosszat.
>
> A kép dimenzió nem csak a kodek magánügye (ezt nem neked mondom .rpi). Az
> mplayer a tömörített frame-et kiveszi az adat chunkból, odaadja a
> kodeknek. Ezután viszont fogadnia kell a kodektól az adatot, és ekkor
> szüksége van a dimenzió és align információkra. Nameg persze
> megjelenítésnél is.
ez nem egeszen igaz, legalabbis ugy 2 honapja az mplayernel mar nem.
ui. a codec hivja meg a video filter layert atadva neki egy mpi strukturat,
ami tartalmazza a kitomoritett kepet, annak adataival (w/h, stride,
colorspace stb).
> > tehat igen, a biCompression az 0, tehat uncompressed.
> > nemtom az a cvid mit keres ott, de az ugyse szamit.
>
> A cvid jó azon a helyen. Az AVI file-ban sok stream helyezkedhet el, a
mar miert lenne jo? nem cinepak-al van tomoritve, ergo a cinepak
fourcc-jenek semmi keresnivaloja az aviban.
> streamek különféle kodekekkel lehetnek tömörítve. A Main AVI headerben
> (LIST 'hdrl' (avih)) található, hogy hány stream van a fileban. Utána
> következik minden streamhez egy header (LIST 'strl' (strh, strf)). Az strh
> AVIStreamHeader típusú header:
>
> typedef struct {
> FOURCC fccType;
> FOURCC fccHandler;
> ...
> };
>
> Az fccType a stream típusa ('vids' kép streamnél, 'auds' hang streamnél).
> Az fccHandler: "The fccHandler field contains a four-character code
> describing the installable compressor or decompressor used with the data."
igen, ez idaig az elmelet
ami szep es jo, de mint mar megszokhattuk, m$ nem szokta ezt betartani, es
most sem tesz kivetelt
> Ez tehát egy FOURCC, ami alapján a rendszer megállapítja, hogy pontosan
> melyik kodekkel kell kitömörítenie az adott streamet. Az mplayer is ez
> alapján dönt (gondolom, vagy inkább biztos vagyok benne, de nem méztem meg
mar regota nem, mivel nem csak ennel a filenal tartalmaz hulyeseget
> a kódot), hogy milyen dekódert használjon a streamhez. Ez nem lehet 0
> értékû, ezért 'cvid'.
lehet 0, sot altalaban 0
> A "tömörítetlenségre" utaló 0, az már nem FOURCC. Minden Stream headernek
de, epphogy az a fourcc. legalabbis az mondja meg hogy mikeppen van
tomoritve, es ettol fugg hogy melyik codec kell hozza. es meglepo modon a
windoz is ebbol tudja, a system.ini-ben levo osszerendeles alapjan...
> chunknak (LIST 'strl') a második része az 'strf' már a stream típustól és
> a kodektõl függõ információ. Videó streameknél ez egy BITMAPINFO
> struktúra. Ennek az elsõ fele a BITMAPINFOHEADER struktúra:
>
> typedef struct tagBITMAPINFOHEADER{ // bmih
> DWORD biSize;
> LONG biWidth;
> LONG biHeight;
> WORD biPlanes;
> WORD biBitCount
> DWORD biCompression;
> DWORD biSizeImage;
> LONG biXPelsPerMeter;
> LONG biYPelsPerMeter;
> DWORD biClrUsed;
> DWORD biClrImportant;
> } BITMAPINFOHEADER;
>
> Ebben az esetben a biCompression mezõ értéke BI_RGB, amit a WINGDI.H file
> definiál:
>
> /* constants for the biCompression field */
> #define BI_RGB 0L
> #define BI_RLE8 1L
> #define BI_RLE4 2L
> #define BI_BITFIELDS 3L
>
> Tehát ezért 0. "Normális" tömörített videófájlok esetén itt ugyanaz áll,
> mint a FOURCC helyén (pl.: DIV3). Hogy ne legyen feneketlen az amit
eddig stimmel
> beszélek (bár .rpi te tutire érted) az alábbit a riffwalk nevû Win3.1-es
> programmal készítettem (ez az akkori Video for Windows SDK része volt, ma
> már nincs ilyen, pedig elég hasznos) egy DivX 3.11-es aviról:
mplayer -v egyszerubb :)
> Stream Type : vids
> Stream Handler: DIV3
> Compression : DIV3
> Csak a teljesség kedvéért írom le, bocs .rpi, hogy csépelem a szót. A
> 'movi' LIST-ben van a lényeg, ott van a "film", ezek audió és videó data
> chunkok meghatározott sorrendben (sorrendet jól el is lehet bénázni, ha
> nem jól osztják el), az audió és videó frame-eket tárolják. Az idx1 a film
> végén található összefoglalás arról, hogy a 'movi' részben milyen data
> chunkok vannak, ezek milyen típusúak, és pontosan hol vannak.
magyarul ez az index.
> megj.: az AVI formátumban egyébként érdekes, hogy a fõ header-be minden
> elõzetes bevezetés nélkül már ott van a képdimenzió. Mi történik, ha több
> video stream is van a fájlban, és nem ugyanolyan méretûek (bár ez elég
> elborult dolog lenne)?
semmi, ha ennyire fujod kivulrol az avi spec-et, akkor tudnod kene azt is,
hogy az avi spec nem enged meg egynel tobb video streamet. a fileformatum
igen, de az mar mas kerdes :)
amugy en meg nem lattam olyan avi-t amibe tobb video lett volna
> Az egész rizsának a konklúziója az, hogy akkor valamilyen módon a
> codecs.conf-ba bele kéne a cvid-et vezetni, hogy az annak megfelelõ
> kodeknek, és azt a kodeket tartalmazó dll-nek adódjon át.
benne van.
a problema csak az, hogy a cvid az a cinepak codec fourcc-je, es nem fogja
meg ha a fejed tetejere allsz sem 'dekodolni' a tomoritetlen kepet.
imho a file amivel szopsz, egyszeruen szarul van enkodolva, valosiznu
cinepak-bol lett konvertalva uncompressedre, es a konverter elfelejtette
kinullazni azt a mezot...
> Persze érdekes kérdés a tömörítetlen DIB esete. Itt legfeljebb egy olyan
> wrapper kodek szükséges, ami az mplayer által várt, szintén tömörítetlen
> formátumra konvertálja a framet. Gondolok itt a color space típusra (YUV,
> RGB, BGR, ...), vagy hogy a BMP az down-up és nem up-down, stb..
ez a vd_raw.c
> A ((width*bitdepth/8)+3)&~3 képlet elõször gyanúsnak tûnt, de tényleg jó.
> Talán még annyit, hogy a 8-al való osztás egy 3-as lefele shiftelésnek
> felel meg. Bár valószínû, hogy ezt a compiler észreveszi, ha -Ox-el fordul
> a kód.
azer ne nezzel mar ennyire hulyenek, jo?
amugy -O nelkul is, a gcc-t se nezd ennyire hulyenek
> Amire még vigyázni kellene, az az align. Mégpedig ha már fölkészülünk
> tömörítetlen lejátszásra, akkor lehet, hogy kéne fogadni az RLE tömörített
vd_msrle.c
> DIB streamet is. Az viszont nem DWORD, hanem WORD boundary-re alignolt (?
azt nem tudom
> ha jól olvastam a doksikat, de nem biztos). Nem tömörített esetben
> egyébként a monkróm és a 16 színû bmp-knél/DIB-eknél is DWORD alignolás
> van. Most próbáltam ki.
jo
> ui: ha kell a riffwalk, akkor oda tudom adni. Jól használható esetleg
> userek által uploadolt hibás avi-k elsõ megnézésére: hogy a file
> struktúrával minden rendben van-e:
koszi, de mivel az mplayer -v is tud ilyet, inkabb maradok a linuxos
megoldasnal
> Hint: -f2 will dump and verify the indexes of AVI files.
mplayer -v -v
A'rpi / Astral & ESP-team
--
Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu
More information about the MPlayer-felhasznalok
mailing list