- Hivatalosan is bemutatta a Google a Pixel 6a-t
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- Friss koncepciót hoz a Nothing Phone (3)
- Xiaomi 15 Ultra - kamera, telefon
- Íme az új Android Auto!
- Samsung Galaxy S25 Ultra - titán keret, acélos teljesítmény
- Xiaomi 15 - kicsi telefon nagy energiával
- iPhone topik
- Azonnali mobilos kérdések órája
- Yettel topik
Aktív témák
-
Sipi
addikt
No, hosszú idő után eljött a nagy pillanat... Végre van időm, hogy különféle kódolással próbálkozzak. Úgyhogy gyorsan bele is futottam jópár kérdésbe, melyekre nem találtam választ.
A lényeg a következő: léteznek olyan beállítások, amelyekről nem tudom eldönteni, hogy a két fő kódolási eljárás (bitrátát fixálom, s a quantizerek változnak, vagy quantizert fixálom, s a bitráta változhat) közül melyikben alkalmazható.
1. kérdés: a per-macroblock quantizerek állítgatása (luminance és darkness masking, temporary és ... complexity masking) fix bitráta vagy fix quantizer esetén értelmes? (Uff, magyarul melyik esetben lehet a fentieket állítgatni?)
2. Ehhez köthetően a per-macroblock kvantálás miatt elcsúszó average quantizert megadott értékre korrigáló Normalize Adaptive Quantization (naq) opció melyik fenti esetben használható?
3. A luminance/chrominance értékekre vonatkozó single coefficient elimination treshold melyik esetben használható?
4. A minimum/maximum macroblock quantizer melyik fenti esetben használható?
5. Megéri-e H.263 helyett MPEG quantizert használni? Mennyiben jobb/más?
6. A quantizer compression pontosan mit csinál? A neve alapján tömöríti a quantizereket, de egyes helyeken azt olvastam, ez arra jó, hogy a low- és high detail frame-ek között a biteket jobban csoportosítsa át. És melyik esetben lehet ezt (is) használni? Fix bitráta vagy fix quantizer?
Köszönettel:
Sipi -
DcsabaS
senior tag
Kedves Sipi!
''Gyűjtögetem a filmeket - és a legtöbb, amit megszerzek, gusztustalanul rossz minőségű. És még enyhén fogalmaztam. Div3-ban blokkosodva kódolt, elmosódott, nézhetetlen vackokkal van tele a Net.''
Ez pontosan így van. (Ha valaki jót akar, magának kell csinálnia.)
''Merthogy két egyforma film nem létezik, nem lehet úgy kódolni, hogy na, beállítom egy csúszkán a maximális minőséget, és hajrá.''
Ez is igaz. Sajnos az emberek többsége nem is látja azokat a képhibákat (vagy nem törődik velük), amik ellen kellene küzdeni, így aztán beletanulni sem hajlandó a szakmába.
''Volt egy kis vita az MPlayer listáján, ahol többen kérték, hogy legyen néhány előre beállított választási lehetőség, pl. jó-nagyon jó-szuper minőség. ...''
Ez valóban szinte alkalmazhatatlan módszer, ugyanis a forrás minő(tlen)sége rendkívül változatos, márpedig döntően ez határozza meg, hogy mit kell tennünk a tulajdonképpeni kódolás előtt, és hogyan célszerű kódolnunk.
***********
Kedves marcee!
A kikockásodás (mint már volt szó róla) főképpen annak az eredménye, hogy túl nagy kvantálással dolgozik az adott helyen a codec. Éspedig azért, mert a codec nem eléggé jól ítéli meg, hogy mekkora sávszélességet érdemes felhasználni az adott helyen, és mert mi megengedtük neki (a max. quantizer túl nagy). (Habár, igazából, igenis jól ítéli meg, csak éppen a post-filter nem elég jó hozzá...)
Ami a megfelelő beállításokat illeti, el kell mondjam, hogy egy tipikus DVD filmnél legalább egy nagyságrenddel egyszerűbb a helyzet, mintha kameráról, vagy videóról származó jelet tömörítenénk, ott ugyanis külön meg kell birkózni a megfelelő deinterlace-eléssel, PAL színszűréssel, croppolással, antialiasing szűréssel, átméretezéssel, zajszűréssel, kontraszt, színegyensúly, telítettség és fényerő beállítással és artifact mentesítéssel, stb. - nagyjából ebben a sorrendben.
Csak ezután jöhet a DivX-be tömörítés, mindig 2 menetben, és azután, hogy jól szemügyre vettük a tömörítendő anyagot arra nézve, hogy mekkora az effektív felbontás, mennyire zajos (még mindig), mennyire mozgalmas, milyen hosszú, milyen hangot lesz célszerű hozzá készíteni, mekkora lehet a kész video, milyen gépen fogják lejátszani, stb.
Maradva a konkrét kérdésednél:
Ha egy filmnél van egy gyorsan mozgó jelenet, ahol kifogynánk a sávszélességből, akkor először is 2-menetes kódolást célszerű használni, mert akkor ide a codec maga is több key frame-et tesz le (akár mindegyik frame ilyen lesz), másodszor le kell csökkenteni a kvantálási maximumot a nekünk megfelelő méretűre. Mint már írtam, a DivX5-ös codec gyári default-ja (12) tűrhetetlenül magas, mert arra vezet, hogy még a legjobb 2-3 lemezes kódolásoknál is lesznek majd helyek, ahol a codec tényleg kihasználja a 12-es maximumot, és ezzel láthatóvá teszi a kockákat. Minőséginek szánt kódolásokhoz a maximumot 6-ra kell csökkenteni.
Megjegyzem, hogy LEHETNE olyan post filtert csinálni a DivX-hez, amely szinte tökéletesen eltüntetné lejátszáskor a szóbanforgó kockákat. Sajnos a jelenlegi post filter nem ilyen, gondolom főleg azért, mert még így is túlságosan erős CPU kell a lejátszáshoz. -
marcee
addikt
Nekem is lenne néhány kérdésem:
Én GordianKnot+DivX5+VirtualDub-ot használok a saját minőségi céljaim elérésére, nem nagyon szoktam az alapbeállításokkal játszani, a minőségjavító funkciókat bekapcsolom, a megfelelő felbontást ki tudom választani...stb, de ez nem mindig jön össze (pl Az Élet Szép. Egész jól néz ki DVD-n, de a 2CD-s Divx mégis homályos lett 640x352-ben).
Ill. a fő problémám az hogy nagyon megtetszettek a Xvid filmek, a ripper csapatok munkáiból szinte nem találkozni ''kikockásodás''-sal, holott az ugyanő általuk nyomott divx3-as filmek elég sok kívánnivalót, hagynak maguk után, de a szinek a legkirályabbak.
Kipróbáltam egy filmemen (Sikoly, 106min) a 2-pass, 640x272-es felbontást Xvid+VirtualDub alapbeállításokon és azt kellett tapasztalnom, hogy semmivel sem lett jobb mint a DivX5-ös próbálkozásom (azt tudom hogy ez a hossz és felbontás valahol a minőségi kódolás alsó határa, de így legalább nem nagyítóval kell keresni a különbséget). (576x240-ben már nagyon szép lett, de gondolom a divx5 is az lett volna)
Szóval az lenne a kérdés, hogy ha az xvid sem alapból jó, akkor mi az amit egy profi máshogy állít be, ill. tudsz-e valami xvid-re kihegyezett encoder-t?
Ill. az említett profi rippek, ha kifogynak a sávszélességből, akkor homályosak és nem pixelesek lesznek: ezt hogyan lehet elérni (t.i. jobban ''tetszik'') -
Sipi
addikt
Gyűjtögetem a filmeket - és a legtöbb, amit megszerzek, gusztustalanul rossz minőségű. És még enyhén fogalmaztam. Div3-ban blokkosodva kódolt, elmosódott, nézhetetlen vackokkal van tele a Net.
Ezért minél több információt szeretnék összegyűjteni, hogy hogyan lehet jó minőségű DivX-kódolású filmet létrehozni, mikre kell ügyelni. Merthogy két egyforma film nem létezik, nem lehet úgy kódolni, hogy na, beállítom egy csúszkán a maximális minőséget, és hajrá. De nem mindig volt egyértelmű, hogy a sok paraméter mikor mit is csinál.
Volt egy kis vita az MPlayer listáján, ahol többen kérték, hogy legyen néhány előre beállított választási lehetőség, pl. jó-nagyon jó-szuper minőség. Leírták, ez miért lehetetlen - azóta eléggé rosszallóan tekintek a ''Rippeld le SmartRipperrel, aztán kódold be xy programmal, a legjobb minőség presettel'' típusú javaslatokra.
Köszönöm, most már van esélyem elindulni - neki merek állni saját rippek létrehozásának, TV-műsor felvételének, etc. Ki tudja, egyszer talán orvosi célokra készített full PAL felbontású DivX-eket is merek majd készíteni...:)
Sipi -
Sipi
addikt
Újabb köszönet! Jól kezdődik a napom...:)
Írtad, hogy DivX esetében a színmélységben kvantálás a kodek belügye. A lavcodec-ben találtam pár paramétert, ami viszont lehet, hogy ezzel függ össze.
- vlelim (-1000-1000) single coefficient elimination threshold for luminance
- vcelim (-1000-1000) single coefficient elimination threshold for chrominance
- lumi_mask(0.0-1.0) luminance masking
- dark_mask(0.0-1.0) darkness masking
A leírás szerint a luminance/chrominance értékeket befolyásolja, az utóbbi kettő főleg blokkosodás ellen jó.
Most már mintha kezdeném érteni a dolgokat. Csak ne lenne még ezen kívül kb. 30 paraméter...:P
Sipi -
DcsabaS
senior tag
''A hangot miért a 2. menetben célszerű tömöríteni?''
Az első menetben még felesleges, ugyanis amikor a 2. menetben tömörítjük, akkor egyúttal a mixelés is elvégezhető.
''Ha így csinálod, VBR is nyugodtan mehet, hiszen mindenképpen fix méretű file-t kapsz. Ha viszont nem akarom később darabolni, akkor nyugodtan használhatom?''
Ha később nem akarod darabolni a videót, nem akarsz kimásolni valakinek egy rövidke részletet, akkor használhatsz VBR hangot is. (De minthogy úgyis a videó a döntő a méretek szempontjából, nem sokat nyersz azzal, ha a hangot CBR helyett VBR kódolással csinálod. Csak a kellemetlenség van vele, beleértve azt is, hogy az ilyen file-t a lassúbb gépek nehezebben tudják lejátszani megfelelő szinkronnal.)
''Kézzel be lehet tenni keyframe-et az ominózus helyekre (képváltásokhoz), vagy ezt teljesen automatikusan végzi a kodek''
Az 5-ös DivX ezt automatikusan és nagyon jól elvégzi a 2-menetes kódolásnál. A konfigurációs file-ok editálásával módosíthatsz is rajta (de nincs értelme). A codec nagyon pontosan érzékeli, hogy hol érdemes elhelyezni új key frame-et. A kay frame-ek maximális távolságának default értéke 300, amit én 250-re szoktam állítani, így a legnyugisabb esetekben is max. 10 másodpercenként jön egy új. (Ha mondjuk a CD valahol megsérül, és ezért szemetet olvas be a lejátszó, akkor legkésőbb 10 másodperc múlva újra jó lesz a kép.)
Feleslegesen nem érdemes szaporítani a key frame-ek számát, ez ugyanis a látható képminőséget nem javítja, ellenben a file méretét növeli. Van azonban olyan eset, amikor mégis sűríteni célszerű őket. Ha ugyanis az a célod, hogy egy archívált anyagból majdan innen-onnan kiemelj képeket, akkor azt könnyebb az egyes key frame-eknél megtenni. Tehát ha a távolságuk csak max 25, akkor 1 másodperces felbontásban emelhetsz majd ki képet, illetve állíthatod meg egy pillanatra a videó lejátszót. -
Sipi
addikt
Azannya, köszönöm!!! Ez kimerítő válasz volt!
A hangot miért a 2. menetben célszerű tömöríteni? Elvileg - a szinkronon kívül - nincs köze a videóhoz, tehát ha először tömörítem, utána szimplán kihagyhatom a tömörítési folyamatból. Így viszont lesz egy fix méretű 100 megás hangom, így egy 700 megás CD esetén marad 600 megám a videóra.
Ha így csinálod, VBR is nyugodtan mehet, hiszen mindenképpen fix méretű file-t kapsz. Ha viszont nem akarom később darabolni, akkor nyugodtan használhatom?
Kézzel be lehet tenni keyframe-et az ominózus helyekre (képváltásokhoz), vagy ezt teljesen automatikusan végzi a kodek, én csak egy teljes filmre érvényes beállítást tudok eszközölni? (Pl. sűrítem a számukat, minden 1/100-dik másodpercben legyen egy.)
(GMC: azt hiszem, MPlayerben ez lehet a vm4. 4 motion vector per macroblock.)
Köszönöm!
Sipi -
DcsabaS
senior tag
''Pontosan mi az a quantizer? (Ha tudnám, a következő kérdésem is meg lenne válaszolva: miért nincs értelme, ha quant=1, miért jó a 2, és miért lesz egyre csúnyább, ha nő?)''
A DivX kódolásnál többféle kvantálás is előfordul. A kvantálás általában azt jelenti, hogy valamit, ami folytonos (vagy közelítőleg annak vehető), diszkrét értékekkel helyettesítünk. (A digitalizálás ennek speciális esete.) Lehet kvantálni színmélységben, de ezt közvetlenül nem tudjuk befolyásolni, mondhatni a DivX codec belügye. Lehet a kép síkjában is, ami azt jelenti, hogy a codec ekkora négyzet alakú tartományokra bontja szét a képet. Értelemszerűen annál nagyobb lehet a tömörítés, minél nagyobbak a tartományok, ámde annál rosszabb is lesz a felbontás és artifact-ként láthatóvá válhatnak a ''rettegett'' négyzetek. Egyazon képen belül is változhat (az egymás követők között meg pláne), hogy milyen kicsi négyzetekig célszerű elmenni. A DivX codec az általunk megadott minimális/maximális méretek között keresi az optimumot, de nem mindig sikerül neki úgy. Tipikusan az van, hogy sötét, és folyamatosan változó árnyalatú, de nem struktúrált felületeken nagyon láthatókká válhatnak a négyzetek. Ha a maximum quantizert kisebbre állítjuk, akkor a négyzetek és a kontrasztjuk is kisebb lesz, vagyis nem lesz olyan kiábrándító a kép.
''Ezek szerint: ha konstans bitrátát (vbitrate=xxx), vagyis változó kvantálást használok, értelme van a min és max kvantálás megadásának.''
Mindenképpen van értelme, ugyanis a képek belsejében is a határok közötti, de akár többféle kvantálással dolgozik a codec.
''Ezzel egyensúlyozhatok a nagyobb méret (kicsi min) és a rosszabb minőség (max nagy) között.''
Igen. Ha muszáj erősen tömöríteni, akkor kénytelenek vagyunk növelni a maximális megengedett kvantálási méretet - de ez rontja a minőséget.
''Ha pedig konstans kvantálást (vqscale=xxx), ezeknek nincs értelme - ekkor a vrc_maxrate és vrc_minrate nyer értelmet?''
A régi DivX codec-ekeknél tényleg volt olyan kódolás, amikor a kvantálás mérete határozott volt. Az 5-ös codec viszont mindig többféle kvantálást használ (hacsak nem állítod a minimumot és a maximumot azonosra), ami jobb módszer, csak nehezebben megjósolható a file végső mérete - hacsak nem 2-menetes a kódolás.
Egyebek:
Windows (VirtualDub) alatt mindent kézben lehet tartani, zseniális filterek vannak. Linux alatt meg szerintem neked kell majd megcsinálnod (bár lehet, hogy éppen ezt akarod).
A hangot a 2. menetben célszerű tömöríteni. A mérete pontosan meghatározott, hacsak nem VBR-t használsz, ami viszont balfékség lenne, ugyanis az ilyen videókat utána nem lehet korrektül darabolni (hiszen ide-oda csúszkál a hang pozíciója).
''A key frame-ekkel érdemes variálni? Mit lehet vele elérni?''
De még mennyire! A filmekben számos helyen van kameraváltás, és minden ilyen helyre key frame-et kell tenni, különben dupla sávszélességnél is OCSMÁNYAK lesznek az átmenetek. (A DivX5 a 2-menetes kódolásnál szinte az összes képváltást lefüleli.)
''Mit jelent a Bidirectional Encoding, QP és Gmc?''
Részletesen is megismerhetők a www.divx.com-on, mindenesetre a tömör lényeg:
BDE: a codec nemcsak a korábbi frame-ekből tud számolni a későbbiekre, hanem fordítva is. (Ez a tapasztalatok szerint majd 30 százalékos nyereségre vezet.)
QP: Negyed pixeles pontossággal számolja ki az egyes tartományok színét, és úgy keresi az optimumot. (Ennek relatíve kicsi a haszna.)
GMC: Az egész képre kiterjedően nagy pontossággal határozza meg, hogy az egyes makroblokkok hová mozdulnak. (Olyankor jelent nagy nyereséget, ha sok mozgás van, és a kép mégsem elmosódott. Sajnos lejátszásnál túl nagy plusz terhet jelent.)
ATi TV kártya (SuSe) Linux alatt: egy munkatársamnak épp mostanra sikerült beüzemelnie a 2 hónapja vett kártyát (Miro PCTV Pro jellegű), miután letöltött valahonnan egy leges-legújabb drivert. -
Den
veterán
Egy duronon lesz. De most nem fogok gui-t telepíteni egyáltalán, induláskor rögtön a html oldal fog megnyílni valamilyen progival és az lesz a kezelőfelület. Ezt az optimalizációt megnézem, de hihetetlenül láma vagyok linuxban úgyhogy első körben örülök ha egyáltalán működni fog :)
-
Sipi
addikt
Most a Linuxosok meg fognak kövezni, de a Red Hatnek, Mandrake-nek, SuSe-nak pont ez a baja. Nem túl gyorsak. A legtöbb, ami adható, hogy i686-osra (tehát Pentiumra) optimalizálják, de Neked gondolom AthlonXP-d van, ami azért jóval többet tudna... Ráadásul vagy túlságosan windows-os, vagy rengeteg opció van benne, amivel ugyan finomhangolhatod, de képtelenség őket megjegyezni.
Ha forrásból fordítasz, nem csak az adott processzorra, hanem az adott architektúrára is optimalizálhatsz. (Mármint hogy egy AthlonXP és egy sima Pentium között nem csak MHz-beli különbség, nem csak processzoron belüli különbség, hanem alaplapi különbség is van.)
Sipi -
-
Sipi
addikt
Ezek szerint még Linuxot is telepítened kell... Ha szeretsz ''buzerálni'', elmélyedni a dolgokban, szereted a kezedben tartani a gépet, esetleg ajánlhatom a Gentoo Linuxot. Minden programot forráskódból letölt, lefordít és telepít. Emiatt élő Internet-kapcsolat kell neki. Nagyon jó a dokumentációja. Nekem olyan érzésem van vele, mintha szoftveresen moddoltam volna a gépemet...:)
Sipi -
Sipi
addikt
Igen, így tökéletesen menni fog, ha előtte belőtted az alkalmazásokat. Gondolok itt pl. arra, hogy az mplayer-ben beállítottad, az infratávirányító melyik gombja mit csinál. Utána pedig link egy parancsfile-ra, amiben csak annyi van, hogy ''mplayer -tv on:driver=v4l:device=/dev/video0: ...''.
Egyébként érdemes megnézned a [L]http://www.mythtv.org/[/L] és a [L]http://sourceforge.net/projects/freevo/[/L] címet. Mindkettő multimédiás boxot varázsol a gépből. Nekem a freevo-t sosem sikerült beüzemelnem, a MythTV-t majdnem, de ott a gagyi videokártyám a ludas. Az utóbbi trükkös cucc: mindenképpen meg KELL neki adni egy országot, s ennek megfelelően letölti a Netről, hogy ott milyen TV-adók vannak, és azokon milyen műsor megy. Ezt utána menüsen nézni tudod, beállíthatod, hogy melyiket vegye fel, stb. Képeket, zenéket is böngészhetsz vele. Tetszik - csak kár, hogy nem megy...:)
Sipi -
Den
veterán
Az a problema hogy nem értek a linuxhoz. Inkább leírom mit akarok. :)
Szal összedobtam egy gépet, ilyen házi multimédia centrumnak, de a családtagjaimnak gondot okoz a kezelése, mihez melyik alkalmazás mit hogy kell beáállítani...
Ezért gondoltam hogy úgy csinálom meg hogy csinálok egy html lapot, amin linkként rajta lesz minden funkció minden lehetséges beálítással és abból választanak. A linknél meg az adott alkalmazás lenne megadva paramterekkel.
Jól értem akkor hogy ezt meg lehet csinálni? -
Sipi
addikt
Itt úgy érted, hogy állandó bitrátát véve alapul, a quant maxot veszem fel 6-ra, ugye? A minimum meg, gondolom, 2.
Én három menetben szoktam kódolni, az elsőben csak a hangot tömöríted be, így ha a méret a lényeg, nagyon pontosan meg lehet adni, mennyi legyen a bitrate. A következő menetben megvizsgálja a videót, utána kódolja.
A key frame-ekkel érdemes variálni? Mit lehet vele elérni? (Azon kívül, hogy összedűtöm az egész video-folyamot...:))
Mit jelent a Bidirectional Encoding, QP és Gmc?
Köszi! A végén csak kikupálódok...:)
Sipi -
Sipi
addikt
Igen, igazad van, végül is nem mplayer-gond. Amiket írtál, jók, de én Linux alatt akarok kódolni, az mplayer-rel, azért gondoltam erre. No meg azért is, mert az mplayer-es doksikban sok olyan okosság van, amit elolvasva megtudtam pár dolgot magáról a DivX-be való tömörítésről. A VirtualDub és hasonló programokat annak idején megnéztem, de egyrészt nem ad annyi beállítási lehetőséget, mint az mplayer (bár lehet, hogy ma már nem így van), másrészt az mplayer-doksikkal összehasonlítva: az utóbbiak alapján magáról az mpeg-szabványokról, tömörítésekről tudtam meg sokmindent, és mivel az mplayer opciói a szabványban leírt dolgokat valósítják meg, könnyen kezelni tudtam (egy részüket:))). A Windows alatti kódolókkal az a bajom, hogy adnak opciókat, de azok többnyire egyes emberek által kitalált, ömlesztett funkciók, amelyekről nem tudom, micsodák. Pl. a vqmin/vqmax párosról már tudom, micsoda, mit érhetek el vele. A legtöbb wines opcióról ugyanezt nem tudom elmondani, mert legfeljebb annyit tudtam meg róluk, hogy ha bekapcsolom/nagyobbra tolom a csúszkát, jobb minőséget kapok. De ez - mplayer olvasgatás után - tuti, hogy nem így van, minden film más és más eset. Sokat kell próbálgatni.
Püff neki, hosszú lett. Félig aludtam közben, remélem, nem írtam csúnyákat...:)
Sipi -
Sipi
addikt
Pontosabban: az mplayert lehet GUI-val is használni, de az nem tud annyit, mint parancssorból.:)
Ha a kerneled kezeli a tunert, az mplayer/mencoder is, mert a standard v4l interfészt használja.
(Én a GeForce2 GTS-emre SVSH-csatlakozóval dugott ASUS TVüBoxomat használom, a rivatv driverével. Nem olyan jó a minősége, mint Win alatt, de itt legalább működik a felvétel.)
Az ATI-hoz nem igazán tudok hozzászólni, nekem sosem volt olyanom. Attól is függ, milyen ATI (Radeon, Rage, vagy valami mai). Nézd meg a Gatos drivert ([L]http://gatos.sourceforge.net/[/L], ez bizonyos ATI kártyákon kezeli a TV-Int is.
Az mplayerhez írtak egy vidix video drivert, ami Ati, Matrox kártyákhoz biztosít olyan drivert, amivel esetenként sokkal jobban játszik le videókat.
Elvileg minden Linuxos program indítható paraméterezve, vagy van egy konfig állománya, amiben minden paraméter leírható. A XawTV-nek pl., ami egy egész jó (bár nem túl szép) TV-néző alkalmazás, a configjában minden paraméter beállítható - így, ha máshogy akarod parancssorból hívni, csinálsz x konfigot, és a xawtv-t más-más konfig file-lal hívod meg.
Sipi -
Sipi
addikt
Pontosabban: az mplayert lehet GUI-val is használni, de az nem tud annyit, mint parancssorból.:)
Ha a kerneled kezeli a tunert, az mplayer/mencoder is, mert a standard v4l interfészt használja.
(Én a GeForce2 GTS-emre SVSH-csatlakozóval dugott ASUS TVüBoxomat használom, a rivatv driverével. Nem olyan jó a minősége, mint Win alatt, de itt legalább működik a felvétel.)
Az ATI-hoz nem igazán tudok hozzászólni, nekem sosem volt olyanom. Attól is függ, milyen ATI (Radeon, Rage, vagy valami mai). Nézd meg a Gatos drivert ([L][/L]
Úgy tudom mplayert nem csak graifkus felülettel lehet futtatni, hanem karakteresen és indításkor felparaméterezve. Ez érdekelne, és hogy ez esetleg kezel-e tv tunert is, illetve van-e olyan linuxos program ami kezel tunert (ati-t) és paraméterezve indítható? -
Sipi
addikt
Köszönöm! Ez már az lett volna...:) Nem tudtam, hogy jól értelmeztem-e a doksikat. De akkor juhé, idáig minden stimmt.
Pontosan mi az a quantizer? (Ha tudnám, a következő kérdésem is meg lenne válaszolva: miért nincs értelme, ha quant=1, miért jó a 2, és miért lesz egyre csúnyább, ha nő?)
Ezek szerint: ha konstans bitrátát (vbitrate=xxx), vagyis változó kvantálást használok, értelme van a min és max kvantálás megadásának. Ezzel egyensúlyozhatok a nagyobb méret (kicsi min) és a rosszabb minőség (max nagy) között. Ha pedig konstans kvantálást (vqscale=xxx), ezeknek nincs értelme - ekkor a vrc_maxrate és vrc_minrate nyer értelmet?
A vqdiff (maximum quantizer difference between I or P frames) melyik esetben használható?
A vratetol (filesize tolerance in kbit) melyik esetben használható?
A naq (normalize adaptive quantization) opció melyik esetben nyer értelmet? A leírás szerint a makroblokkokon belüli kvantáláshoz való, értem, mit csinál, csak azt nem, hogy a makroblokkokon belüli műveleteket (lumi_mask, dark_mask, stb.) állandó bitráta vagy állandó kvantálás esetében lehet-e használni.
Azt hiszem, csak ennyi...:)
Még egyszer kösz!
Sipi -
Sipi
addikt
Köszönöm! Ez már az lett volna...:) Nem tudtam, hogy jól értelmeztem-e a doksikat. De akkor juhé, idáig minden stimmt.
Pontosan mi az a quantizer? (Ha tudnám, a következő kérdésem is meg lenne válaszolva: miért nincs értelme, ha quant=1, miért jó a 2, és miért lesz egyre csúnyább, ha nő?)
Ezek szerint: ha konstans bitrátát (vbitrate=xxx), vagyis változó kvantálást használok, értelme van a min és max kvantálás megadásának. Ezzel egyensúlyozhatok a nagyobb méret (kicsi min) és a rosszabb minőség (max nagy) között. Ha pedig konstans kvantálást (vqscale=xxx), ezeknek nincs értelme - ekkor a vrc_maxrate és vrc_minrate nyer értelmet?
A vqdiff (maximum quantizer difference between I or P frames) melyik esetben használható?
A vratetol (filesize tolerance in kbit) melyik esetben használható?
A naq (normalize adaptive quantization) opció melyik esetben nyer értelmet? A leírás szerint a makroblokkokon belüli kvantáláshoz való, értem, mit csinál, csak azt nem, hogy a makroblokkokon belüli műveleteket (lumi_mask, dark_mask, stb.) állandó bitráta vagy állandó kvantálás esetében lehet-e használni.
Azt hiszem, csak ennyi...:)
Még egyszer kösz!
Sipi -
Den
veterán
Én voiszont neked tennék fel kérdést.
Úgy tudom mplayert nem csak graifkus felülettel lehet futtatni, hanem karakteresen és indításkor felparaméterezve. Ez érdekelne, és hogy ez esetleg kezel-e tv tunert is, illetve van-e olyan linuxos program ami kezel tunert (ati-t) és paraméterezve indítható? -
DcsabaS
senior tag
Na ha jól értelek, akkor nem is az MPLayer-rel van gondod, hanem azzal, hogy milyen stratégiával érdemes DivX-be kódolni. Nos tehát:
1.) 2-menetes kódolást célszerű használni, mert ilyenkor a DivX codec okosabban tudja elosztani a sávszélességet, és pontosabban tudja elhelyezni a kay frame-eket.
2.) A DivX codec a kvantálás méretével képes játszani (és ezzel az előírt méretű file-t produkálni), DE a gyári default 12-es maximum TÚL NAGY. (Főleg ez vezet a sötét és homogén részek kockásodásához.) 8-nál nagyobbra szinte sosem érdemes választani. 512x384 pixeles felbontásnál egy 1.5 órás filmhez 6 a legmegfelelőbb, hosszabb filmhez meg a 7, vagy a 8.
3.) Célszerű használni egy segédprogramot (DivX Bitrate Calculator), amibe be lehet írni a film hosszát, a CD méretét és hogy mekkora sávszélességet akarunk hagyni a hangnak. Ebből már adódik, hogy mekkora sávszélességet kell beállítanunk a DivX codec-ben.
4.) Kódolásnál az MPEG-4 Tools-nál a Bidirectional Encoding-ot feltétlenül célszerű használni, a QP-t és a Gmc-t csak akkor, ha elég erős lesz a lejátszásra szánt gép (mint már írtam).
5.) Kódoláshoz a VirtualDub-ot célszerű használni, mert ott nagy rakás filtert is használhatunk, pl. olyanokat, amelyek kiszűrik a rendkívül sávszélesség-igényes zajokat. -
Sipi
addikt
Kicsit értelmesebben: két lehetőségem van. Az egyik, hogy a bitrátát adom meg, ekkor megadom, hogy a kodek mennyi bitet használhat adott frame tömörítéséhez, és majd eldönti, hogy milyen kvantálási értékekkel tudja ezt elérni. A másik pedig az, hogy megadom, fixen ennyi legyen a kvantálási érték (mi ez magyarul? - quantizer), ekkor a minőség állandó, de változni fog a bitráta, ergo ismeretlen a végleges file-hossz.
Sipi -
Sipi
addikt
No, aki tudja, szóljon...:)
Szóval, MPlayerrel DVD-DivX átalakítás. A doksikat, levlistákat, stb. böngészgetve kezd összeállni a kép, de még van sok homályos pont.
Alapvetően a következők jöttek le: ha MPEG4-be akarok tömöríteni, két választásom van: 1.) hosszúságra optimalizálom az anyagot (pl. 2 CD-s rip), ekkor a kvantálás változó lesz, vagyis a minőség is, vagy 2.) állandó kvantálást állítok be, de ekkor a kész anyag mérete nem jósolható meg előre. Van egy harmadik út is: 2- vagy többmenetes tömörítésnél az első menetben állandó kvantálást állítok be, ekkor a minőség rulez, a másodikban pedig állandó bitrátát, ekkor a hosszát tudom szabályozni.
Jól látom, vagy sem? Ha igen, jön a többi kérdés...:)
Sipi
Aktív témák
Hirdetés
- Sea of Thieves Premium Edition és Egyéb Játékkulcsok.
- 27%-OS ÁFÁS SZÁMLA I Jogtiszta Microsoft digitális és fizikai termékek I DIGITALKEYZ.COM
- Számlás!Steam,EA,Epic és egyébb játékok Pc-re vagy XBox!
- Microsoft licencek KIVÉTELES ÁRON AZONNAL - UTALÁSSAL IS AUTOMATIKUS KÉZBESÍTÉS - Windows és Office
- Windows 10/11 Home/Pro , Office 2024 kulcsok
- Készpénzes számítógép PC félkonfig alkatrész hardver felvásárlás személyesen / postával korrekt áron
- Apple iPhone SE 2020 64GB, Yettel függő, 1 Év Garanciával
- Csere-Beszámítás! Sapphire Pure RX 7700XT 12GB GDDR6 Videokártya! Bemutató Darab!
- PlayStation Plus Premium előfizetések
- Apple iPhone 13 . 128GB , Kártyafüggetlen , 100% akku
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest