Az mplayerrel meg képes vagy olyan antiszabványokat is előállítani, amit semmi más nem lesz képes lejátszani. Egy hatalmas szabadságot ad, mint a linuksz… amivel azonban élni kell tudni.
Így akár egy rossz összeállítás is lehet a gong. Nem tudom… ebből nem derül ki semmi.

Értem. Mindenki máshonnan közelíti meg a dolgot.

Itt a teljes kód: Most direkt megENTEReztem! Hogy ne kelljen scroolozni.

Ez egy változókkal teli dologból kreálódik.
Ha az egyik változó helyett a másikat választom, akkor mp3 lesz a hang:

Esetleg nem is xvid-et hanem divx-et használnék:

De ahogy tovább olvasom a neten fellelhető infókat, ebből az lesz világos számomra, hogy ogg hangot (vorbis) csak ogm videóval lehet probléma nélkül összeházasítani?
Azt meg ugye semmi a világon le nem játssza.

Hogy hangot is vegyen fel azt külön, másképpen adom meg neki. A script elején van egy

a végén meg egy

parancs.

Azt is megkérdezném, hogy melyik lenne a jobb, a processzor terhelést figyelembe véve. A crop vagy a scale inkább?

No, akkor itt van máris az a probléma, amit említettem.
Az avi nem támogatja többek között a vorbist, de a változó bitrátát 2 G-nál nagyobb méretet 900 M-nál nagyobb hangot, b kockákat stb. (ugyan az mplayer némi trükk árán képes lejátszani és/vagy rögzíteni, de azt semmilyen szabvány szabványos lejátszó nem lesz képes lejátszani).

Igen valószínű, hogy az a multimédia lejátszó, ami lejátsza a vorbist, az az ogm-t is. De létrehozhatsz quicktime, vagy matroska multiplexet. Számos előnye lesz: pl. a vorbis támogatása, változó bitrátájú* audió és/vagy videó támogatása, felírat, több audió, kép egy multiplexben. Viszont rosszabb a multiprocesszoros támogatás (legalábbis egy stream-en belül).

* ugyanolyan vizuális élményhez az egyszerű képkockáknál kevesebb bit kell, amíg a bonyolultaknál több, így kisebb lesz a méret és/vagy jobb minőségű a kép és hang.

A scale és crop teljesen mást csinálnak.
A scale méretez, a crop levágja a kép egyes részeit, vagy kisebb képet vág ki (csinál) a nagyobból, ha úgy tetszik.
Nyílván egy scale opciónak nagyobb a cpu igénye, mivel a crop csak kihagy pontokat: mondjuk a ciklusban egy szorzás (sor) és összeadás (oszlop) a memória terület elérésénél. Amíg a scale-nél minden egyes képpontot, sőt jobb minőség esetén a környezetét is meg kell vizsgálni és azok birtokában új képpontokat kell számolni.
A crop alkalmazása (értelmesen) akkor indokolt, ha egy pl. pal jelen továbbított pl. 16:9-es képből akarjuk levágni a fekete csíkokat. A cél az, hogy a vége is szabványos maradjon.
A szélen lévő kis hibákat inkább fekete csíkkal érdemes kitölteni és nem levágni, mert akkor rosszul kezelhető méret lesz a végén: pl., ha nem 8, 16, 32, 64 számokkal osztható lesz a méret (mindkét oldal) – attól függően, hogy milyen méretű egységeket használ a program (nyílván nagyobb méretnél, „újabb” cpu-nál érdemes nagyobb számot használni a gyorsulás miatt – minden további művelet kódolás vagy lejátszás esetén) – akkor jelentősen megnőhet a cpu terhelés, mert egy optimalizált algoritmus helyett (ahol nincs maradék), figyelni kell arra, hogy hol és mennyi a maradék.
Amúgy a crop műveletet használnám mindig először, mivel utána a scale műveletet kevesebb képponton kell végrehajtani.

Amúgy én mindenesetre egy jó minőségű mpeg2-be (audió mindegy, mert bírja a cpu) venném fel, a legtöbb minőség optimalizáló algoritmussal és utána (immáron nem valós módban) tenném át változó bitrátájú h264-be, mert talán az a legjobb.
Amúgy valószínűleg szabványos H.264/MPEG-4 AVC-be menteném, mert azt az összes hd kompatibilis (ill. azon kívül számos) eszköz/sw támogatja. (És nyalván azért nem valós módban, mert a kódolás időben – főleg az optimalizálós paraméterekkel – finoman szólva necces. :))