[MPlayer-translations] CVS: main/DOCS/xml/hu mencoder.xml,1.7,1.8
Mizda Gábor CVS
syncmail at mplayerhq.hu
Mon Jul 4 16:32:16 CEST 2005
CVS change done by Mizda Gábor CVS
Update of /cvsroot/mplayer/main/DOCS/xml/hu
In directory mail:/var2/tmp/cvs-serv22799
Modified Files:
mencoder.xml
Log Message:
synced with 1.73
Index: mencoder.xml
===================================================================
RCS file: /cvsroot/mplayer/main/DOCS/xml/hu/mencoder.xml,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- mencoder.xml 29 Jun 2005 08:47:22 -0000 1.7
+++ mencoder.xml 4 Jul 2005 14:32:13 -0000 1.8
@@ -1,5 +1,5 @@
<?xml version="1.0" encoding="iso-8859-2"?>
-<!-- synced with 1.72 -->
+<!-- synced with 1.73 -->
<chapter id="mencoder">
<title>Kódolás a <application>MEncoder</application>rel</title>
@@ -2083,31 +2083,43 @@
<application>MEncoder</application>ben a támogatását</link>.
</para>
-<sect2 id="menc-feat-x264-intro">
-<title>Milyen opciókat kell használhom a legjobb eredményhez?</title>
+<sect2 id="menc-feat-x264-encoding-options">
+<title>Az x264 kódolási opciói</title>
<para>
Kérlek kezd az olvasást az <application>MPlayer</application> man oldalának
<systemitem class="library">x264</systemitem> részével.
- Ez a rész a man oldal kiegészítésének lett szánva.
+ Ez a rész a man oldal kiegészítésének lett szánva. Itt csak rövid
+ tanácsokat találhatsz, hogy mely opciók érdekelhetik a letöbb embert.
+ A man oldal tömörebb, de ugyanakkor kimerítõbb is és esetenként
+ több technikai információval szolgál.
</para>
+<sect3 id="menc-feat-x264-encoding-options-intro">
+<title>Bevezetés</title>
+<para>Ez a leírás a kódolási opciók két fõ kategóriáját tárgyalja:</para>
+
<orderedlist>
-<title>Három fõ szempontot kell megfontolni, amikor kódolási opciókat
- választasz:</title>
- <listitem><para>A kódolási idõ vs. minõség kérdés</para></listitem>
- <listitem><para>Képkocka típusra vonatkozó döntések</para></listitem>
- <listitem><para>Ráta és kvantálási tulajdonságokkal kapcsolatos döntések</para></listitem>
+ <listitem><para>Opciók, melyekkel a kódolási idõ vs. minõség arány szabályozható
+ </para></listitem>
+ <listitem><para>Opciók, melyek a különbözõ egyéni érdekeknek és speciális igényeknek
+ próbálnak eleget tenni</para></listitem>
</orderedlist>
<para>
- Ez a leírás leginkább az elsõ kérdéssel foglalkozik.
- A másik két típus gyakran a személyes beállítottságtól és
- egyéni igényektõl függ.
+ Igazából csak te tudod, hogy mely opciók a legjobbak neked. Az elsõ
+ csoportba tartozó opcióknál könnyû dönteni: csak azt kell megfontolnod,
+ hogy a minõségi különbség megéri-e a sebességbeli különbséget. A másik
+ csoport már sokkal szubjektívebb és több szempontot kell figyelembe
+ venni. Tartsd észben, hogy az "egyéni érdekek és speciális igényeknek"
+ eleget tevõ opciók jelentõsen befolyásolják a sebességet vagy a minõséget,
+ de elsõsorban nem ezért használják õket. Az "egyéni érdekek" opciói közül
+ több olyan változásokat idézhet elõ, ami néhány embernek tetszhet, míg
+ másoknak nem.
</para>
<para>
- Mielõtt folytatnád, kérlek vedd figyelembe, hogy ez a leírás csak egy
+ Mielõtt folytatnád, meg kell értened, hogy ez a leírás csak egy
minõségi mércét használ: a globális PSNR-t.
A PSNR rövid leírása megtalálható
<ulink url="http://en.wikipedia.org/wiki/PSNR">a Wikipedia PSNR-rõl szóló cikkében</ulink>.
@@ -2122,45 +2134,56 @@
kódolást használsz.
Az opciók összehasonlításánál két fõ érv szól a kétlépéses
kódolás mellett.
- Az egyik, hogy a két lépés alkalmazása kb. 1dB PSNR-t jelent pluszba,
+ Az egyik, hogy a két lépés alkalmazása kb. 1dB PSNR-t jelent pluszban,
ami nagyon nagy különbség.
A másik, hogy az opciók tesztelésénél a direkt minõség-összehasonlítás
- az egy lépéses kódolásokkal bizonytalan, mert a bitráta gyakran
- jelentõsen változik a kódolások között.
- Nem minden esetben könnyû megmondani, hogy a minõség változás a
- megváltozott opciók miatt következett-e be vagy az elért bitráta
- különbségbõl adódik.
+ az egy lépéses kódolásokkal behoz egy zavaró tényezõt: a bitráta
+ gyakran jelentõsen változik a kódolások között.
+ Nem minden esetben könnyû megmondani, hogy a minõségi változás a
+ megváltozott opciók miatt következett-e be vagy a fõként véletlenül
+ elért bitráta különbségbõl adódik.
</para>
-<para>
- Azon opciók, amik segítségével a sebesség kárára javíthatod a minõséget,
- a <option>subq</option> és a <option>frameref</option> a legfontosabbak
- általában.
+</sect3>
+
+<sect3 id="menc-feat-x264-encoding-options-speedvsquality">
+<title>Elsõsorban a sebességet és a minõséget érintõ opciók</title>
+
+<itemizedlist>
+<listitem><para>
+ <emphasis role="bold">subq</emphasis>:
+ Azon opciók közül, amik segítségével a sebesség és minõség közötti arányt
+ befolyásolhatod, a <option>subq</option> és a <option>frameref</option>
+ (lásd lejjebb) a legfontosabbak általában.
Ha érdekel akár a sebesség, akár a minõség tuningolása, akkor ezt a
két opciót kell elõször megvizsgálnod.
-</para>
-
-<para>
Sebesség szempontjából a <option>frameref</option> és a
<option>subq</option> opciók elég erõteljes kölcsönhatásban
vannak.
A tapasztalatok szerint egy referencia kockával a
- <option>subq=5</option> kb. 35%-kal több idõt kíván, mint a
- <option>subq=1</option>.
+ <option>subq=5</option> (alapértelmezett érték) kb. 35%-kal több idõt
+ kíván, mint a <option>subq=1</option>.
6 referencia kockával az igény 60% fölé megy.
A <option>subq</option> hatása a PSNR-re elég egyenletes,
a referencia kockák számától függetlenül.
- Általában a <option>subq=5</option> 0.2-0.5 dB hasznot hoz a
- globális PSNR szempontjából a <option>subq=1</option>-hez képest.
+ Általában a <option>subq=5</option> 0.2-0.5 dB-vel magasabb
+ globális PSNR-t biztosít a <option>subq=1</option>-gyel összehasonlítva.
Ez már látható különbség.
</para>
-
-</sect2>
-
-<sect2 id="menc-feat-x264-encoding-options">
-<title>Az x264 kódolási opciói</title>
-
-<itemizedlist>
+<para>
+ A <option>subq=6</option> a leglassabb, legjobb minõséget nyújtó mód.
+ A <option>subq=5</option>-tel összehasonlítva általában 0.1-0.4 dB nyereséget
+ jelent a globális PSNR-ben, 25%-100% között változó sebességveszteség árán.
+ A <option>subq</option> egyéb értékeitõl eltérõen a <option>subq=6</option>
+ viselkedése nem függ olyan nagy mértékben a <option>frameref</option> és
+ a <option>me</option> opcióktól. A <option>subq=6</option> hatékonysága
+ inkább a használt B-kockák számától függ. Normális használat esetén ez
+ azt jelenti, hogy a <option>subq=6</option>-nak nagy hatása van mind a
+ sebességre, mint a minõségre az összetett, sok mozgást tartalmazó jelenetek
+ esetében, de sokkal kevesebb a kevés mozgást rögzítõ részeknél. Jegyezd
+ meg, hogy még mindig javasoljuk a <option>bframes</option> értékének
+ valamilyen nullától különbözõ értékre történõ állítását (lásd lejjebb).
+</para></listitem>
<listitem><para>
<emphasis role="bold">frameref</emphasis>:
A <option>frameref</option> alapértéke 1, de ez nem jelenti
@@ -2183,9 +2206,9 @@
a globális PSNR-t csekély 0.02dB-vel javítja a
<option>frameref=6</option>-hoz képest, 15%-20% sebességveszteség árán.
Az ilyen magas <option>frameref</option> értékeknél az egyedüli
- igazán jó dolog, amit mondhatunk, hogy a további növelés majdnem
- biztosan soha sem <emphasis role="bold">árt</emphasis> a
- PSNR-nek, de a minõségi javulás szinte alig mérhetõ és nem is észrevehetõ.
+ igazán jó dolog, amit mondhatunk, hogy a további növelés szinte
+ soha sem <emphasis role="bold">árt</emphasis> a PSNR-nek, de a minõségi
+ javulás szinte alig mérhetõ és nem is észrevehetõ.
</para>
<note><title>Megjegyzés:</title>
<para>
@@ -2255,8 +2278,8 @@
<listitem><para>
<emphasis role="bold">bframes</emphasis>:
- A B-kockák haszna megkérdõjelezhetõ a legtöbb, eddig használt codec
- esetében.
+ Ha kódoltál már más codec-kel, rájöhettél, hogy a B-kockák nem mindig
+ hasznosak.
A H.264-nél ez megváltozott: új technikák és blokk típusok lehetnek a
B-kockákban.
Általában még a naív B-kocka választó algoritmus is jelentõs
@@ -2282,7 +2305,7 @@
Megjegyzés: Ez alapértelmezetten be van kapcsolva.
</para>
<para>
- Ezzel az opcióval a kódoló egy egyszerû heurisztikát
+ Ezzel az opcióval a kódoló egy eléggé gyors döntési eljárást
fog használni a B-kockák számának csökkentésére az olyan
jelenetekben, amelyek nem profitálnak belõlük.
Használhatod a <option>b_bias</option>-t a kódoló
@@ -2313,8 +2336,7 @@
Az MPEG-4 ASP-ben az elsötétülés általában drága I-kockák
sorozatával kerül legjobban elkódolásra; a B-kockákban
használt súlyozott jóslással lehetséges ezek legalább
- részben a sokkal ésszerûbben-méretezett B-kockákkal
- történõ lecserélése.
+ részben a sokkal kisebb B-kockákkal történõ lecserélése.
A kódolási idõben jelentkezõ plusz ráfordítás minimális, mivel nem kell
külön döntéseket hozni.
Ellentétben azzal, amire pár ember gondol, a dekódoló CPU
@@ -2328,7 +2350,116 @@
x264encopts-hoz, ha arra számítasz, hogy sötétedések jelentõsen
befolyásolják a videódat.
</para></listitem>
+</itemizedlist>
+</sect3>
+<sect3 id="menc-feat-x264-encoding-options-misc-preferences">
+<title>Különbözõ igényekhez tartozó opciók</title>
+<itemizedlist>
+<listitem><para>
+ <emphasis role="bold">Két lépéses kódolás</emphasis>:
+ Fentebb azt javasoltuk, hogy mindig használj két lépéses kódolást,
+ azonban vannak indokok az elkerülése mellett is. Például ha élõ TV
+ adást mentesz és kódolsz valós idõben, kénytelen vagy egy lépést
+ használni. Az egy lépés nyilvánvalóan gyorsabb, mint a két lépéses;
+ ha teljesen ugyan azokkal az opciókat használod mind a két lépésben,
+ a két lépéses kódolás majdnem kétszer olyan lassú.
+</para>
+<para>
+ Mégis van pár nagyon jó indok a két lépéses kódolás használatára. Az
+ egyik, hogy az egy lépés rátakontollja nem pszichikai, így gyakran
+ ésszerûtlen döntéseket hoz, mert nem látja a nagy képet. Például tegyük
+ fel, hogy van egy két perces videód, mely két eltérõ félbõl áll. Az
+ elsõ fele nagyon gyors mozgású, 60 másodperces jelenet, ami magában
+ kb. 2500kbps-t igényel, hogy megfelelõen nézzen ki. Majd rögtön ez
+ után egy sokkal kisebb igényû 60 másodperces jelenet jön, ami 300
+ kbps-sel is jól néz ki. Tegyük fel, hogy 1400kbps-t kérsz, ami elméletileg
+ elég mind a két jelenethez. Az egy lépéses rátakontroll rengeteg "hibát"
+ ejt egy ilyen esetben. Mindenek elõtt az 1400kbps-t célozza meg mind a
+ két szegmensben. Az elsõ rész erõteljesen túl lesz kvantálva, emiatt
+ elfogadhatatlan és túlzottan blokkos képet kapsz. A második szegmens
+ pedig erõteljesen alul lesz kvantálva; tökéletesen néz ki, de az
+ ezzel járó bitráta többlet teljesen ésszerûtlen. Amit még nehezebb
+ elkerülni, az a két jelenet közötti átmenet problémája. A lassú mozgású
+ rész elsõ pár másodperce túlságosan túl lesz kvantálva, mert a
+ rátakontroll még a videó elsõ felébõl származó bitráta igényre számít.
+ Ez a túlkvantálási "hiba periódus" a kevés mozgást tartalmazó részt
+ szörnyen rosszá teszi, tulajdonképpen kevesebb, mint 300kbps-t fog
+ használni, ami a megfelelõ kinézethez kellene. Több lehetõség is van
+ az egy lépéses kódolás buktatóiból származó hibák csökkentésére, de
+ összességében mégis növelik a bitráta félrebecslésének esélyét.
+</para>
+<para>
+ A többlépéses rátakontrollnak több elõnye is van az egylépésessel
+ szemben. Az elsõ lépésbõl nyert statisztikai adatokból a kódoló egész
+ jó pontossággal meg tudja jósolni egy bármilyen adott kocka bármilyen
+ adott kvantálás melletti kódolásának "költségét" (bitekben). Ez a bitek
+ sokkal ésszerûbb, jobban megtervezett elosztását eredményezi a drága
+ (sok mozgású) és az olcsó (kevés mozgású) jelenetek között. Lásd a
+ <option>qcomp</option> opciót lejjebb néhány ötletért, hogy hogyan
+ tudod ezt a felosztást kedvedre változtatni.
+</para>
+<para>
+ Továbbá a két lépés nem tart kétszer annyi ideig, mint az egy. Az elsõ
+ lépés opcióit rá lehet hangolni a nagyobb sebességre és a gyengébb
+ minõségre. Ha jól választod meg az opciókat, egy nagyon gyors elsõ
+ lépésed lehet. Az eredmény minõsége a második lépésben kicsit alacsonyabb
+ lesz mert a méret becslés kevésbé pontos, de a minõségi különbség
+ normális esetben túl kicsi ahhoz, hogy észrevedd. Például próbáld meg a
+ <option>subq=1:frameref=1</option> opció hozzáadását a
+ <option>x264encopts</option> elsõ lépéséhez. Majd, a második lépésben
+ használj lassabb, jobb minõséget biztosító opciókat:
+ <option>subq=6:frameref=15:4x4mv:me=3</option>
+</para></listitem>
+<listitem><para>
+ <emphasis role="bold">Három lépéses kódolás</emphasis>?
+
+ Az x264 lehetõséget nyújt tetszõleges számú egymás utáni lépések
+ elvégzésére. Ha megadod a <option>pass=1</option> opciót az elsõ lépésben,
+ majd <option>pass=3</option>-at használsz az egyik következõ lépésben,
+ a következõ lépés beolvassa az elõzõ statisztikáját és megírja a sajátját.
+ Egy ezt követõ lépésnek már nagyon jó alapjai lesznek, nagyon pontos
+ döntéseket tud hozni a képkocka méretre vonatkozóan a választott kvantálás
+ mellett. A gyakorlatban az össz minõségi nyereség ebbõl közel van a
+ nullához és lehetséges, hogy egy harmadik lépés kissé még rontja is a
+ globális PSNR-t az elõzõ lépéshez képest. Az átlagos felhasználásban
+ a három lépés akkor segít, ha két lépéssel rossz bitráta jóslást kaptál
+ vagy ronda átmeneteket a jelenetek között. Ilyen dolog csak a nagyon
+ rövid klippeknél fordulhat elõ. Van még pár speciális eset is, amikor
+ a három (vagy több) lépés jól jöhet a haladó felhasználóknak, de a
+ rövidítés végett ezeket az eseteket nem tárgyaljuk ebben a leírásban.
+
+</para></listitem>
+<listitem><para>
+ <emphasis role="bold">qcomp</emphasis>:
+ A <option>qcomp</option> a "drága", sok mozgást és az "olcsó", kevés
+ mozgást tartalmazó jelenetekhez használt bitek arányát szabályozza.
+ Extrém esetben a <option>qcomp=0</option> az igazi konstans bitrátát
+ célozza meg. Ezzel a sok mozgású részek borzasztóan fognak kinézni, míg
+ a kevés mozgást tartalmazó részek valószínûleg tökéletesen fognak kinézni,
+ de a hasonló kinézethez szükséges bitráta többszörösét fogják felhasználni.
+ A másik extrém véglet a <option>qcomp=1</option> majdnem konstans
+ kvantálási paramétert ér el (QP). A konstans QP nem néz ki rosszul, de a
+ legtöbb ember úgy gondolja, hogy ésszerûbb egy kis bitrátát feláldozni a
+ roppant drága jeleneteknél (ahol a minõségromlás nem olyan észrevehetõ)
+ és felhasználni õket a kitûnõ minõségben is könnyebben kódolható
+ jeleneteknél. A <option>qcomp</option> alapértelmezett értéke 0.6, ami
+ eléggé alacsony sok ember ízléséhez képest (0.7-0.8 a leggyakrabban
+ használt).
+</para></listitem>
+<listitem><para>
+ <emphasis role="bold">keyint</emphasis>:
+ A <option>keyint</option> kizárólag a a fájlon belüli keresést rontja a
+ kódolási hatékonyság javára. Alapértelmezésként a <option>keyint</option>
+ 250-re van állítva. Egy 25fps-es anyagnál ez garantálja a 10 másodpercen
+ belüli pontossággal történõ ugrást. Ha úgy gondolod, hogy fontos és hasznos
+ lenne az 5 másodperces pontosság, állítsd be a <option>keyint=125</option>
+ értéket; ez egy kissé rontja a minõséget/bitrátát. Ha csak a minõség
+ érdekel és a kereshetõség nem, beállíthatod magasabb értékre (észben tartva
+ azt, hogy egyre csökkenõ hasznot hoz, mely végül szinte észrevehetetlenül
+ kicsi vagy akár nulla lesz). A videó folyam még így is fog tartalmazni
+ kereshetõ pontokat, amíg van benne jelenet váltás.
+</para></listitem>
<listitem><para>
<emphasis role="bold">deblockalpha, deblockbeta</emphasis>:
Ez a rész egy kicsit vitatható lesz.
@@ -2395,6 +2526,7 @@
szûrõvel való pepecseléssel.
</para></listitem>
</itemizedlist>
+</sect3>
</sect2>
</sect1>
@@ -2411,7 +2543,7 @@
Ez a leírás fõként hasonló információkat szeretne nyújtani, mint az
x264 kódolási leírás.
Ezért, kérlek kezdd azzal, hogy elolvasod azon leírásnak az
- <link linkend="menc-feat-x264-intro">elsõ részét</link>.
+ <link linkend="menc-feat-x264-encoding-options-intro">elsõ részét</link>.
</para>
More information about the MPlayer-translations
mailing list