[Mplayer-felhasznalok] RAW RGB AVI lejatszas. (harmadik

[Arpi]

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