MPlayer-translations
Threads by month
- ----- 2026 -----
- April
- March
- February
- January
- ----- 2025 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2024 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2023 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2022 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2021 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2020 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2019 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2018 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2017 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2016 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2015 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2014 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2013 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2012 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2011 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2010 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2009 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2008 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2007 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2006 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2005 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2004 -----
- December
May 2005
- 4 participants
- 105 discussions
CVS change done by Sebastian Kraemer CVS
Update of /cvsroot/mplayer/main/DOCS/man/de
In directory mail:/var2/tmp/cvs-serv31334/DOCS/man/de
Modified Files:
mplayer.1
Log Message:
German man page review part III
added missing option '-loadidx'
Index: mplayer.1
===================================================================
RCS file: /cvsroot/mplayer/main/DOCS/man/de/mplayer.1,v
retrieving revision 1.152
retrieving revision 1.153
diff -u -r1.152 -r1.153
--- mplayer.1 14 May 2005 12:44:30 -0000 1.152
+++ mplayer.1 14 May 2005 14:16:12 -0000 1.153
@@ -498,7 +498,7 @@
Ändert dynamisch das Qualitätslevel des Postprocessings, je nachdem, wieviel
CPU-Zeit gerade frei ist.
Das angegebene Level ist das maximal verwendete Level.
-Normalerweise kannst du eine große Nummer wählen.
+Normalerweise kannst du eine große Zahl wählen.
Um dieses Feature zu benutzen, muss \-vf [s]pp ohne Parameter aufgerufen
werden.
.
@@ -786,12 +786,11 @@
.
.TP
.B \-a52drc <Level>
-Gibt die Höhe der Dynamic Range Compression für den AC3 Audio Stream an.
+Gibt das Level der Dynamic Range Compression für den AC3 Audiostream an.
<Level> ist ein Fließkommawert im Bereich von 0 bis 1, wobei 0 keine Kompression
-und 1 (der Standardwert) volle Kompression bedeutet (laute Passagen werden leiser
-und umgekehrt).
+und 1 volle Kompression bedeutet (laute Passagen werden leiser und umgekehrt).
Diese Option zeigt nur Wirkung, wenn im AC3 Stream die Range Compression
-Information vorhanden ist.
+Information vorhanden ist (Standard: 1).
.
.TP
.B \-aid <ID> (siehe auch \-alang)
@@ -808,15 +807,15 @@
Verschiedene Containerformate verwenden unterschiedliche Ländercodes.
DVDs benutzen den zweibuchstabigen ISO 639-1 Sprachcode, Matroska und NUT
benutzen den dreibuchstabigen ISO 639-2 Sprachcode, während OGM einen
-beliebigen Bezeichner verwendet.
-MPlayer gibt alle vorhandenen Sprachen aus, wenn er im
-Verbose-Modus (\-v) gestartet wird.
+formlosen Bezeichner verwendet.
+MPlayer gibt alle vorhandenen Sprachen aus, wenn er im ausführlichen Modus
+(\-v) gestartet wird.
.sp 1
.I BEISPIEL:
.PD 0
.RSs
.IPs "mplayer dvd://1 \-alang hu,en"
-Wählt die ungarische Sprachspur einer DVD und wählt die Englische, wenn
+Wählt die ungarische Sprachspur einer DVD und wählt die englische, wenn
ungarisch nicht verfügbar ist.
.IPs "mplayer \-alang jpn example.mkv"
Spielt eine Matroskadatei auf japanisch ab.
@@ -824,7 +823,7 @@
.PD 1
.
.TP
-.B \-audio-demuxer <Nummer> (nur mit \-audiofile)
+.B \-audio-demuxer <Nummer> (nur bei \-audiofile)
Erzwingt den Audiodemuxertyp für \-audiofile.
Gib die Demuxer-ID an wie in libmpdemux/\:demuxer.h definiert.
\-audio-demuxer 17 erzwingt das Abspielen als MP3.
@@ -836,14 +835,14 @@
.
.TP
.B \-audiofile-cache <kByte>
-Aktiviert das Cachen des von \-audiofile benutzten Streams;
-benutzt dafür die angegebene Menge Speicher.
+Aktiviert das Cachen des von \-audiofile benutzten Streams; benutzt dafür die
+angegebene Menge Speicher.
.
.TP
-.B \-bandwidth <Wert> (nur im Netzwerk)
+.B \-bandwidth <Wert> (nur bei Netzwerk)
Gibt die maximal zu benutzende Bandbreite für Netzwerkstreaming an (bei
Servern, die Streams in verschiedenen Bitraten senden können).
-Nützlich, wenn du Live\-Streams über eine langsame Verbindung ansehen
+Nützlich, wenn du Live-Streams über eine langsame Verbindung ansehen
möchtest.
.
.TP
@@ -854,7 +853,7 @@
.
.TP
.B \-cache-min <Prozent>
-Die Wiedergabe startet, wenn der Cache bis zu <Prozent> des Gesamten gefüllt
+Die Wiedergabe startet, wenn der Cache bis zu <Prozent> der Gesamtgröße gefüllt
ist.
.TP
.
@@ -868,7 +867,7 @@
Diese Option kann benutzt werden, um die CD-Audio-Auslesefeatures von
MPlayer zu verfeinern.
sp 1
-Vorhandene Optionen sind diese:
+Vorhandene Optionen sind folgende:
.RSs
.IPs speed=<Wert>
Setzt die CD-Umdrehungsgeschwindigkeit.
@@ -895,34 +894,35 @@
zu erkennen.
.IPs toc-offset=<Wert>
Addiere <Wert> Sektoren zu den ermittelten Werten bei der Adressierung
-der Spuren. Kann negativ sein.
+der Spuren.
+Kann negativ sein.
.IPs (no)skip
Akzeptiere (niemals) nicht perfekte Datenrekonstruktion.
.RE
.
.TP
-.B \-cdrom-device <Pfad zum Gerät>
+.B \-cdrom-device <Pfad\ zum\ Gerät>
Gibt das CD-ROM-Gerät an (Standard: /dev/\:cdrom).
.
.TP
.B \-channels <Anzahl>
Ändere die Anzahl der wiederzugebenden Kanäle (Standard: 2).
Wenn die Anzahl der Ausgabekanäle größer als die Anzahl der Eingangskanäle ist,
-dann werden leere Kanäle unter Zuhilfenahme des channels Audiofilter erzeugt
-(es sei denn, es wird von Mono zu Stereo erweitert - dann wird der Mono-Kanal
+dann werden leere Kanäle unter Zuhilfenahme des Audiofilters channels erzeugt
+(es sei denn, es wird von Mono zu Stereo erweitert \- dann wird der Mono-Kanal
auf beiden Kanälen wiederholt).
-Das Routing wird das Standard-Routing für den channels Filter sein.
+Das Routing wird das Standard-Routing für den Filter channels sein.
Wenn die Anzahl der Eingangskanäle größer als die Anzahl der Ausgabekanäle ist,
dann hängt das Ergebnis vom Audiodecoder (\-afm) ab.
MPlayer weist den Decoder an, den Ton in so viele Kanäle zu decodieren,
wie angegeben wurde.
-Jetzt liegt es am Decoder, diese Anforderung zu erfüllen.
+Dann liegt es am Decoder, diese Anforderung zu erfüllen.
Wenn der Decoder mehr Kanäle als angefordert ausgibt, so werden die
überschüssigen Kanäle abgeschnitten.
Das ist normalerweise nur dann wichtig, wenn Videos mit AC3-Audio abgespielt
-werden (wie z.B.\& DVDs).
+werden (wie z.B.\& bei DVDs).
In diesem Fall decodiert normalerweise die liba52 den Ton und sorgt für
-einen korrekten Downmix des Audios auf die geforderte Anzahl von Kanälen.
+einen korrekten Downmix des Audios auf die geforderte Anzahl Kanäle.
.br
.I ANMERKUNG:
.br
@@ -943,20 +943,19 @@
.PD 1
.
.TP
-.B \-chapter <Kapitel\-ID>[\-<Kapitel\-ID\ des\ letzten\ Kapitels>] (nur bei DVD)
-Gibt das Kapitel an, ab dem abgespielt werden soll. Optional kann angegeben
-werden, nach welchem Kapitel mit dem Abspielen aufgehört werden soll
-(Standard: 1).
-Unten stehen Beispiele.
+.B \-chapter <Kapitel-ID>[\-<Kapitel-ID\ des\ letzten\ Kapitels>] (nur bei DVD)
+Gibt das Kapitel an, ab dem abgespielt werden soll.
+Optional kann angegeben werden, nach welchem Kapitel mit dem Abspielen
+aufgehört werden soll (Standard: 1).
.
.TP
-.B \-cookies (nur im Netzwerk)
+.B \-cookies (nur bei Netzwerk)
Sende Cookies bei HTTP-Anfragen.
.
.TP
-.B \-cookies-file <Dateiname) (nur im Netzwerk)
-Lies HTTP-Cookies aus dieser Datei und überspringe die Suche in den
-Standardverzeichnissen ~/.mozilla/ und ~/.netscape/.
+.B \-cookies-file <Dateiname>) (nur bei Netzwerk)
+Lies HTTP-Cookies aus <Dateiname> und überspringe die Suche in den
+Standardverzeichnissen (Standard: ~/.mozilla/ und ~/.netscape/).
Es wird angenommen, dass die Datei im Netscape-Format vorliegt.
.
.TP
@@ -972,16 +971,17 @@
.
.TP
.B \-dumpfile <Dateiname> (nur MPlayer)
-Gibt den Dateinamen an, in den MPlayer schreiben soll. Sollte in Verbindung
-mit \-dumpaudio / \-dumpvideo / \-dumpstream benutzt werden.
+Gibt den Dateinamen an, in den MPlayer schreiben soll.
+Sollte in Verbindung mit \-dumpaudio / \-dumpvideo / \-dumpstream benutzt
+werden.
.
.TP
.B \-dumpstream (nur MPlayer)
-Schreibt den unbehandelten Stream nach ./\:stream.dump. Nützlich, um DVD-
-oder Netzwerk-Streams zu rippen.
+Schreibt den unbehandelten Stream nach ./\:stream.dump.
+Nützlich, um DVD- oder Netzwerk-Streams zu rippen.
.
.TP
-.B \-dumpvideo (nur MPlayer)
+.B \-dumpvideo (nur bei MPlayer)
Schreibt den unbehandelten, komprimierten Videostream nach ./stream.dump
(nicht sehr nützlich).
.
@@ -989,13 +989,13 @@
.B \-dvbin <Optionen> (nur bei DVB)
Übergibt die folgenden Parameter an das DVB-Inputmodul und überschreibt dabei
die Standardeinstellungen:
-
+.sp 1
.PD 0
.RSs
.IPs card=<1\-4>
Benutze Karte 1\-4 (Standard: 1).
.IPs file=<Dateiname>
-Weist MPlayer an, die Liste der Kanäle aus <Datei> zu lesen (Standard:
+Weist MPlayer an, die Liste der Kanäle aus <Dateiname> zu lesen (Standard:
~/\:.mplayer/\:channels.conf.{sat,ter,cbl,atsc} (je nach Kartentyp)
oder ~/\:.mplayer/\:channels.conf als letzte Möglichkeit).
.RE
@@ -1005,58 +1005,59 @@
.B \-dvd-device <Pfad\ zum\ Gerät> (nur bei DVD)
Gibt das DVD-Gerät an (Standard: /dev/\:dvd).
Du kannst auch ein Verzeichnis angeben, das die zuvor direkt von DVD kopierten
-Dateien enthält (so wie mit vobcopy).
-Merke, dass die Benutzung von \-dumpstream normalerweise ein besserer Weg ist,
-DVD-Titel zu kopieren (siehe Beispiele).
+Dateien enthält (z.B.\& von vobcopy).
+Beachte, dass die Benutzung von \-dumpstream normalerweise ein besserer Weg
+ist, DVD-Titel zu kopieren (siehe Beispiele).
.
.TP
.B \-dvdangle <Winkel-ID> (nur bei DVD)
Einige DVDs beinhalten Szenen, die aus verschiedenen Perspektiven/\:Winkeln
betrachtet werden können.
-Mit dieser Option kannst du MPlayer sagen, welche Perspektive er wiedergeben
-soll (Standard: 1).
+Mit dieser Option kannst du MPlayer bestimmen, welche Perspektive er
+wiedergeben soll (Standard: 1).
.
.TP
.B \-edl <Dateiname> (nur bei EDL)
Aktiviert EDL-Aktionen (Edit Decision List) während der Wiedergabe.
Teile des Videos werden entsprechend den Einträgen der angegebenen
Datei übersprungen und Teile des Audios stummgeschaltet.
-Siehe DOCS/\:de/\:documentation.html#edl, dort stehen Details, wie du dieses
+Siehe DOCS/\:de/\:documentation.html#edl für Details, wie du dieses
Feature benutzen kannst.
.
.TP
.B \-forceidx
Erzwingt Indexgenerierung.
-Nützlich für Dateien mit defektem Index (A/\:V-Desynchronisation etc.).
+Nützlich für Dateien mit defektem Index (A/\:V-Desynchronisation etc).
Das ermöglicht das Spulen in Dateien, in denen dies vorher nicht möglich war.
Mit MEncoder kann der Index permanent repariert werden (siehe Dokumentation).
.br
.I ANMERKUNG:
Diese Option funktioniert nur, wenn das zugrunde liegende Medium Spulen
-unterstützt (z.B.\& nicht bei Standardeingabe, Pipe usw.)
+unterstützt (z.B.\& nicht bei Standardeingabe, Pipe etc)
.
.TP
.B \-fps <Fließkommazahl>
Überschreibt die Videobildrate.
-Nützlich, falls dieser Wert falsch ist oder im Header fehlt.
+Nützlich, falls dieser Wert falsch ist oder fehlt.
.
.TP
.B \-frames <Anzahl>
-Nur die ersten <Anzahl> Bilder werden wiedergegeben/encodiert.
-Beendet sich danach.
+Nur die ersten <Anzahl> Bilder werden wiedergegeben/\:encodiert.
+Danach wird MPlayer beendet.
.
.TP
-.B \-hr\-mp3\-seek (nur bei .MP3)
-Hi\-res mp3-Spulen.
+.B \-hr-mp3-seek (nur bei .MP3)
+Hi-res mp3-Spulen.
Standardmäßig ist diese Option an, wenn ein externes MP3 abgespielt wird,
-da MPlayer an die exakte Position spulen muss, um die A/\:V-Sync zu erhalten.
+da MPlayer an die exakte Position spulen muss, um die A/\:V-Syncronisation
+beizubehalten.
Kann langsam sein, vor allem dann, wenn zurückgespult wird, da dann erst
zum Anfang gespult wird, um die genaue Stelle zu finden.
.
.TP
.B \-idx (siehe auch \-forceidx)
-Erstellt den Index neu, wenn bei einem AVI kein Index gefunden wurde,
-und ermöglicht somit Spulen.
+Erstellt den Index neu, wenn kein Index gefunden wurde, und ermöglicht somit
+Spulen.
Nützlich bei defekten/\:unvollständigen Downloads oder bei schlecht
erstellten Dateien.
.br
@@ -1070,46 +1071,60 @@
Für IPv4-Verbindungen wird er aber benutzt.
.
.TP
+.B \-loadidx <Index-Datei>
+Die Datei, von der die von \-saveidx gespeicherten Indexdaten für das Video
+gelesen werden.
+Dieser Index wird zum Spulen benutzt, dabei wird der im AVI enthaltene Index
+überschrieben.
+MPlayer wird nicht verhindern, dass du einen Index einer anderen AVI-Datei
+benutzt, aber dies wird sicherlich zu ungewünschten Resultaten führen.
+.br
+.I ANMERKUNG:
+Diese Option ist veraltet, da MPlayer nun Unterstützung für OpenDML hat.
+.
+.TP
.B \-mc <Sekunden/\:Bild>
-Maximale A/\:V-Sync-Anpassung pro Bild (in Sekunden).
+maximale A/\:V-Synchronisationsanpassung pro Bild (in Sekunden)
.
.TP
-.B \-mf <option1:option2:...>
+.B \-mf <Option1:Option2:...>
Wird benutzt, wenn mehrere PNG- oder JPEG-Dateien decodiert werden.
.sp 1
-Die verfügbaren Optionen lauten:
+Verfügbare Optionen sind folgende:
.sp 1
.PD 0
.RSs
.IPs w=<Wert>
-Ausgabebreite (automatische Erkennung)
+Ausgabebreite (Standard: automatische Erkennung)
.IPs h=<Wert>
-Ausgabehöhe (automatische Erkennung)
+Ausgabehöhe (Standard: automatische Erkennung)
.IPs fps=<Wert>
Frames pro Sekunde bei der Ausgabe (Standard: 25)
.IPs type=<Wert>
-Typ der Quelldateien (mögliche Typen sind jpeg, png, tga, sgi)
+Typ der Quelldateien (mögliche Typen sind: jpeg, png, tga, sgi)
.RE
.PD 1
.
.TP
-.B \-ni (nur bei .AVI)
-Erzwingt die Benutzung des nicht\-interleaved-AVI-Parsers (was die
-Wiedergabe einiger schlecht erstellter AVIs ermöglicht).
+.B \-ni (nur bei AVI)
+Erzwingt die Benutzung des nicht-interleaved-AVI-Parsers (was die Wiedergabe
+einiger schlecht erstellter AVIs ermöglicht).
.
.TP
-.B \-nobps (nur bei .AVI)
-Benutze nicht die durchschnittlichen Bytes/\:Sekunde für A\-V-Sync (AVI).
+.B \-nobps (nur bei AVI)
+Benutze nicht den durchschnittlichen Bytes/\:Sekunde-Wert für die
+A/\:V-Synchronisation.
Hilft bei einigen AVIs mit defektem Header.
.
.TP
.B \-noextbased
Deaktiviert die auf Dateinamenserweiterungen basierende Demultiplexerauswahl.
Wenn der Dateityp (und damit der Demultiplexer) nicht zweifelsfrei
-festgestellt werden kann (z.B. wenn die Datei keinen Dateikopf besitzt
-oder dieser nicht eindeutig genug ist), dann wird normalerweise ein
+festgestellt werden kann (z.B. wenn die Datei keinen Header besitzt
+oder dieser nicht zuverlässig genug ist), dann wird normalerweise ein
Demultiplexer anhand der Dateiendung gewählt.
-Die inhaltsbasierende Demultiplexerauswahl wird immer vorgenommen.
+Die inhaltsbasierende Demultiplexerauswahl wird bei Problemen immer
+vorgenommen.
.
.TP
.B \-passwd <Passwort> (siehe auch \-user) (nur bei Netzwerk)
@@ -1126,26 +1141,26 @@
Greift automatisch auf IPv4-Verbindungen zurück.
.
.TP
-.B \-rawaudio <option1:option2:...>
+.B \-rawaudio <Option1:Option2:...>
Mit dieser Option können raw-Audiodateien abgespielt werden.
Sie kann auch verwendet werden, um Audio-CDs abzuspielen, die nicht mit 44KHz
16Bit stereo aufgenommen wurden.
Zum Abspielen von RAW-AC3-Streams benutze \-rawaudio on:format=0x2000.
.sp 1
-Verfügbare Optionen:
+Verfügbare Optionen sind folgende:
.sp 1
.PD 0
.RSs
.IPs on\ \ \
-benutzt den nur-Audio-Demuxer
+Benutze den Raw-Audio-Demuxer.
.IPs channels=<Wert>
Anzahl der Kanäle
.IPs rate=<Wert>
Rate in Samples pro Sekunde
.IPs samplesize=<Wert>
-Sample-Größe in Byte
+Sample-Größe in Bytes
.IPs format=<Wert>
-FourCC in Hexadezimal
+FourCC als Hexadezimalwert
.RE
.PD 1
.
2
3
CVS change done by Diego Biurrun CVS
Update of /cvsroot/mplayer/main/DOCS/man/de
In directory mail:/var2/tmp/cvs-serv7949/DOCS/man/de
Modified Files:
mplayer.1
Log Message:
whitespace cosmetics
Index: mplayer.1
===================================================================
RCS file: /cvsroot/mplayer/main/DOCS/man/de/mplayer.1,v
retrieving revision 1.158
retrieving revision 1.159
diff -u -r1.158 -r1.159
--- mplayer.1 31 May 2005 20:27:59 -0000 1.158
+++ mplayer.1 31 May 2005 20:31:00 -0000 1.159
@@ -1,12 +1,12 @@
.\" MPlayer (C) 2000-2005 MPlayer Team
.\" Diese Man-Page wurde/wird von Gabucino, Diego Biurrun, Jonas Jermann,
.\" Moritz Bunkus und Sebastian Krämer gepflegt.
-.\"
+.\"
.\" Gib dies ein, um eine HTML-Version der Man-Page zu erhalten:
.\" cat mplayer.1 | sed s/SS\ 20/SS\ 4/ | groff -man -Thtml - > manpage.html
.\" Gib dies ein, um eine Textversion der Man-Page zu erhalten:
.\" groff -m man -Tascii mplayer.1 | col -bx > manpage.txt
-.\"
+.\"
.
.\" --------------------------------------------------------------------------
.\" Macrodefinitionen
@@ -452,7 +452,7 @@
.B \-quiet \ \
Konsolenausgaben werden weniger ausführlich; insbesondere wird damit die
Statuszeile (z.B.\& A: 0.7 V: 0.6 A-V: 0.068 ...) nicht angezeigt.
-Besonders nützlich ist dies bei langsamen Terminals oder fehlerhaften, die
+Besonders nützlich ist dies bei langsamen Terminals oder fehlerhaften, die
Zeilenvorschübe nicht richtig verarbeiten (z.B.\& \\r).
.
.TP
@@ -534,14 +534,14 @@
.B \-colorkey <Nummer>
Ändert den Farbwert auf einen RGB-Wert deiner Wahl.
0x000000 ist schwarz und 0xffffff ist weiß.
-Wird nur von folgenden Videoausgabetreibern unterstützt: cvidix, fbdev,
+Wird nur von folgenden Videoausgabetreibern unterstützt: cvidix, fbdev,
svga, vesa, winvidix, xmga, xvidix, xover, xv (siehe \-vo xv:ck), xvmc
(siehe \-vo xv:ck) und directx.
.
.TP
.B \-nocolorkey
Schaltet die Wahl des Farbwertes ab.
-Wird nur von folgenden Videoausgabetreibern unterstützt: cvidix, fbdev,
+Wird nur von folgenden Videoausgabetreibern unterstützt: cvidix, fbdev,
svga, vesa, winvidix, xmga, xvidix, xover, xv (siehe \-vo xv:ck), xvmc
(siehe \-vo xv:ck) und directx.
.
@@ -573,7 +573,7 @@
Erzwingt dasselbe Videosystem für mehrere Dateien (einmalige Initialisierung
für alle Dateien).
Dementsprechend wird für alle Dateien nur ein Fenster geöffnet.
-Momentan funktionieren die folgenden Treiber mit \-fixed-vo: gl, gl2, mga,
+Momentan funktionieren die folgenden Treiber mit \-fixed-vo: gl, gl2, mga,
svga, x11, xmga, xv, xvidix und dfbmga.
.
.TP
@@ -1009,7 +1009,7 @@
.TP
.B \-dvdangle <Winkel-ID> (nur bei DVD)
Einige DVDs beinhalten Szenen, die aus verschiedenen Perspektiven/\:Winkeln
-betrachtet werden können.
+betrachtet werden können.
Mit dieser Option kannst du MPlayer vorschreiben, welche Perspektive er
wiedergeben soll (Standard: 1).
.
@@ -1191,8 +1191,8 @@
.TP
.B \-rtsp-stream-over-tcp (nur bei LIVE.COM)
Kann zusammen mit 'rtsp://'-URLs verwendet werden, um anzugeben, dass die
-daraus resultierenden eingehenden RTP- und RTCP-Pakete per TCP
-übertragen werden (mit der gleichen TCP-Verbindung wie RTSP).
+daraus resultierenden eingehenden RTP- und RTCP-Pakete per TCP
+übertragen werden (mit der gleichen TCP-Verbindung wie RTSP).
Diese Option kann hilfreich sein, wenn deine Internetverbindung eingehende
UDP-Pakete nicht durchlässt (siehe http://www.live.com/\:mplayer/)
.
@@ -1242,7 +1242,7 @@
.PD 1
.
.TP
-.B \-tskeepbroken
+.B \-tskeepbroken
Sorgt dafür, daß MPlayer solche TS-Pakete, die als unbrauchbar markiert wurden,
nicht ignoriert.
Diese Option wird manchmal gebraucht, um korrupte MPEG-TS-Dateien abzuspielen.
@@ -1299,14 +1299,14 @@
verfügbaren TV-Normen.
.IPs "normid=<ID> (nur bei V4L2)"
Setzt die TV-Norm auf die angegebene ID.
-Die TV-Norm hängt von der Videokarte ab.
+Die TV-Norm hängt von der Videokarte ab.
Siehe MPlayer-Output für eine Liste der verfügbaren TV-Normen.
.IPs channel=<Wert>
Setzt den Tuner auf Kanal <Wert>.
.IPs chanlist=<Wert>
Werte: europe-east, europe-west, us-bcast, us-cable, etc
.IPs channels=<Kanal>\-<Name>,<Kanal>\-<Name>,...
-Setzt Namen für Kanäle.
+Setzt Namen für Kanäle.
Benutze '_' anstelle von Leerzeichen bei Namen (oder spiel mit der
Shellquotierung rum ;-).
Die Sendernamen werden dann per OSD angezeigt, und die Slave-Kommandos
@@ -1315,7 +1315,7 @@
Kann nicht zusammen mit dem frequency\-Parameter benutzt werden.
.br
.I ANMERKUNG:
-Die Sendernummer wird dann die Position des Eintrags in
+Die Sendernummer wird dann die Position des Eintrags in
der 'channels'-Liste sein, wobei der erste Eintrag die 1 bekommt.
.br
.I BEISPIEL:
@@ -1365,7 +1365,7 @@
über ein externes Kabel von der TV-Karte zur Soundkarte auf (Standardwert
für MPlayer).
.IPs mjpeg
-Benutzte Hardware-MJPEG-Kompression (wenn dies die Karte unterstützt).
+Benutzte Hardware-MJPEG-Kompression (wenn dies die Karte unterstützt).
Bei dieser Option mußt du Breite und Höhe des Ausgabefensters nicht
angeben, denn MPlayer ermittelt diese Werte automatisch vom
Dezimierungswert (siehe unten).
@@ -1554,7 +1554,7 @@
.B \-slang <Sprachcode[,Sprachcode,...]> (siehe auch \-sid)
Gibt eine Prioritätenliste von zu benutzenden Untertitelsprachen an.
Verschiedene Containerformate verwenden unterschiedliche Sprachcodes.
-DVDs benutzen ISO 639-1-Sprachcodes mit zwei Buchstaben, Matroska verwendet
+DVDs benutzen ISO 639-1-Sprachcodes mit zwei Buchstaben, Matroska verwendet
ISO 639-2-Sprachcodes mit drei Buchstaben, während OGM einen formfreien
Bezeichner gebraucht.
Die verfügbaren Untertitelsprachen erhältst du bei der Verwendung
@@ -2101,7 +2101,7 @@
.IPs no75ire
Schaltet den 7.5 IRE-Ausgabemodus ab (Standard).
.IPs bw\ \ \
-TV-Ausgabe in Schwarz/\:Weiß
+TV-Ausgabe in Schwarz/\:Weiß
.IPs color
TV-Ausgabe in Farbe (Standard)
.IPs interlaced
@@ -2171,7 +2171,7 @@
Benutze diese Konfigurationsdatei an Stelle der Standarddatei /etc/\:fb.modes.
.
.TP
-.B \-fs (siehe auch \-zoom)
+.B \-fs (siehe auch \-zoom)
Vollbildwiedergabe (zentriert den Film und erstellt schwarze Balken rund um
das Bild).
Nicht jeder Videoausgabetreiber unterstützt dies.
@@ -3377,7 +3377,7 @@
.br
2: Ratenkontrolle (Rate Control)
.br
-4: Bitstream
+4: Bitstream
.br
8: Makroblock-Typ (MB type)
.br
@@ -3502,7 +3502,7 @@
.B \-pp <Qualität> (siehe auch \-vf pp)
Setzt das Postprocessing-Level der DLL.
Diese Option kann nicht mehr in Verbindung mit \-vf pp verwendet werden,
-sondern nur noch mit Win32-DirectShow-DLLs, die eigene interne
+sondern nur noch mit Win32-DirectShow-DLLs, die eigene interne
Postprocessing-Routinen mitbringen.
Der gültige Wertebereich für \-pp variiert je nach Codec, ist meistens aber
0\-6, wobei 0=deaktiviert und 6=langsamster/\:bester Modus bedeutet.
@@ -4819,7 +4819,7 @@
Softwareequalizer mit interaktiver Kontrolle wie beim Hardwareequalizer, für
Karten/\:Treiber, die die Kontrolle über Helligkeit und Kontrast via Hardware
nicht unterstützen.
-Kann in Verbindung mit MEncoder nützlich sein; einerseits, um schlecht
+Kann in Verbindung mit MEncoder nützlich sein; einerseits, um schlecht
aufgenommene Filme zu reparieren, und zum anderen, um Artifakte zu maskieren
und niedrigere Bitraten benutzen zu können.
.PD 0
@@ -5937,7 +5937,7 @@
.TP
.B \-passlogfile <Dateiname>
Wenn mit zwei Durchgängen encodiert wird, dann schreibt MEncoder die
-Informationen des ersten Durchgangs in die angegebene Datei und nicht
+Informationen des ersten Durchgangs in die angegebene Datei und nicht
nach divx2pass.log.
.
.TP
1
0
CVS change done by Diego Biurrun CVS
Update of /cvsroot/mplayer/main/DOCS/man/de
In directory mail:/var2/tmp/cvs-serv17860/DOCS/man/de
Modified Files:
mplayer.1
Log Message:
small fixes
Index: mplayer.1
===================================================================
RCS file: /cvsroot/mplayer/main/DOCS/man/de/mplayer.1,v
retrieving revision 1.157
retrieving revision 1.158
diff -u -r1.157 -r1.158
--- mplayer.1 20 May 2005 18:06:27 -0000 1.157
+++ mplayer.1 31 May 2005 20:27:59 -0000 1.158
@@ -560,7 +560,7 @@
in die Datei geschrieben.
Damit erhält der Benutzer eine Ausgangsbasis, die er an seine Bedürfnisse
anpassen kann.
-Siehe DOCS/\:de/\:documentation.html#edl, dort stehen Details, wie du dieses
+Siehe DOCS/\:HTML/\:en/\:edl.html, dort stehen Details, wie du dieses
Feature benutzen kannst.
.
.TP
@@ -813,7 +813,7 @@
.RSs
.IPs "mplayer dvd://1 \-alang hu,en"
Wählt die ungarische Sprachspur einer DVD und wählt die englische, wenn
-ungarisch nicht verfügbar ist.
+Ungarisch nicht verfügbar ist.
.IPs "mplayer \-alang jpn example.mkv"
Spielt eine Matroskadatei auf japanisch ab.
.RE
@@ -1010,7 +1010,7 @@
.B \-dvdangle <Winkel-ID> (nur bei DVD)
Einige DVDs beinhalten Szenen, die aus verschiedenen Perspektiven/\:Winkeln
betrachtet werden können.
-Mit dieser Option kannst du MPlayer bestimmen, welche Perspektive er
+Mit dieser Option kannst du MPlayer vorschreiben, welche Perspektive er
wiedergeben soll (Standard: 1).
.
.TP
@@ -1018,7 +1018,7 @@
Aktiviert EDL-Aktionen (Edit Decision List) während der Wiedergabe.
Teile des Videos werden entsprechend den Einträgen der angegebenen
Datei übersprungen und Teile des Audios stummgeschaltet.
-Siehe DOCS/\:de/\:documentation.html#edl für Details, wie du dieses
+Siehe DOCS/\:HTML/\:en/\:edl.html für Details, wie du dieses
Feature benutzen kannst.
.
.TP
@@ -8689,7 +8689,7 @@
Viele Fehler sind das Resultat eines fehlerhaften Setups oder falscher
Benutzung der Parameter.
Die Sektion über Fehlerberichterstattung in der Dokumentation
-(DOCS/de/bugreports.html) beschreibt, wie man nutzbringende Fehlerberichte
+(DOCS/\:HTML/\:en/\:bugreports.html) beschreibt, wie man nutzbringende Fehlerberichte
erstellt.
.
.
1
0
30 May '05
CVS change done by Mizda Gábor CVS
Update of /cvsroot/mplayer/homepage/essays/src
In directory mail:/var2/tmp/cvs-serv19263
Modified Files:
konf2002-Pontscho.src.hu
Log Message:
synced with 1.3 (HTML update)
Index: konf2002-Pontscho.src.hu
===================================================================
RCS file: /cvsroot/mplayer/homepage/essays/src/konf2002-Pontscho.src.hu,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- konf2002-Pontscho.src.hu 13 Feb 2003 21:48:40 -0000 1.2
+++ konf2002-Pontscho.src.hu 30 May 2005 22:54:42 -0000 1.3
@@ -1,42 +1,39 @@
+
<!-- content start -->
-<p>
- <font class="bigheader">Ponekker Zoltán</font>
-</p>
+<!-- synced with 1.3 -->
+
+<h1>Ponekker Zoltán</h1>
<p>
- <font class="text">
- Én barkácsolom a grafikus felületet az MPlayer-ben, ahogy idõm ezt engedi.
- Próbáltam az egészet úgy felépíteni, hogy pillanatok alatt bõvíthetõ
- legyen, újabb funkciók hozzáadódhassanak, ami az alap MPlayer-ben
- megtalálható, mert iszonyatosan gyorsan változik a paraméter listája. Ezt
- nagyon nehéz követni. Pl. amikor egy kodek interface-t implementáltam a
- grafikus felületbe, akkor két nap múlva ez megváltozott, kezdhettem az
- egészet elölrõl. Ebbe mélyebben nem tudok belemenni idõ hiány miatt, de
- alakul. Most kezdtem egy komplett újraírási funkciót végrehajtani rajta,
- hogy ez sokkal átláthatóbbá váljon, mert pl. maga a grafikus felület
- skin-ezhetõ, tehát tetszõleges bõrt rá lehet húzni erre a kis lejátszóra,
- s ez nagyon sok nehézséget vet fel, s nagyon sok olyan funkciót kénytelen
- az ember implementálni, hogy a skin-ek hibájából adódó problémákat azért
- úgy-ahogy le tudja kezelni. Elég sokféle skin van, általában az összes
- konkurenciának a felülete megtalálható MPlayer alatt is. Lényegében a
- lejátszást, illetve a használhatóságot próbáltam úgy felépíteni, hogy
- minél átláthatóbb, minél egyszerûbb legyen, hogy ha egy átlag felhasználó
- leül elé, már tudja használni valamelyest. Látszik a CVS szépsége és
- hátránya is, hogy ez a bug még két napja nem volt benne. Amióta nem
- fejlesztettem bele, lehet, hogy valaki megváltoztatott valamit, s már
- ilyen szépséghiba bele is került.
- </font>
+Én barkácsolom a grafikus felületet az MPlayer-ben, ahogy idõm ezt engedi.
+Próbáltam az egészet úgy felépíteni, hogy pillanatok alatt bõvíthetõ
+legyen, újabb funkciók hozzáadódhassanak, ami az alap MPlayer-ben
+megtalálható, mert iszonyatosan gyorsan változik a paraméter listája. Ezt
+nagyon nehéz követni. Pl. amikor egy kodek interface-t implementáltam a
+grafikus felületbe, akkor két nap múlva ez megváltozott, kezdhettem az
+egészet elölrõl. Ebbe mélyebben nem tudok belemenni idõ hiány miatt, de
+alakul. Most kezdtem egy komplett újraírási funkciót végrehajtani rajta,
+hogy ez sokkal átláthatóbbá váljon, mert pl. maga a grafikus felület
+skin-ezhetõ, tehát tetszõleges bõrt rá lehet húzni erre a kis lejátszóra,
+s ez nagyon sok nehézséget vet fel, s nagyon sok olyan funkciót kénytelen
+az ember implementálni, hogy a skin-ek hibájából adódó problémákat azért
+úgy-ahogy le tudja kezelni. Elég sokféle skin van, általában az összes
+konkurenciának a felülete megtalálható MPlayer alatt is. Lényegében a
+lejátszást, illetve a használhatóságot próbáltam úgy felépíteni, hogy
+minél átláthatóbb, minél egyszerûbb legyen, hogy ha egy átlag felhasználó
+leül elé, már tudja használni valamelyest. Látszik a CVS szépsége és
+hátránya is, hogy ez a bug még két napja nem volt benne. Amióta nem
+fejlesztettem bele, lehet, hogy valaki megváltoztatott valamit, s már
+ilyen szépséghiba bele is került.
</p>
<p>
- <font class="text">
- Jelen pillanatban 5 db grafikus kimenetet supportálok, mert ezekhez volt
- hardver. Ez a Matrox épp említett kernel driver-e, az X11 driver, az XV
- driver, Vidix driver, valamint a DXR3, vagy a Holywood Plus néven elhíresült
- DVD/MPEG2 dekóder kártya. Ez úgy van megoldva, hogy ezen a dekóder kártyán
- akár AVI-t is lejátszhat az ember megfelelõen kemény vas esetében.
- </font>
+Jelen pillanatban 5 db grafikus kimenetet supportálok, mert ezekhez volt
+hardver. Ez a Matrox épp említett kernel driver-e, az X11 driver, az XV
+driver, Vidix driver, valamint a DXR3, vagy a Holywood Plus néven elhíresült
+DVD/MPEG2 dekóder kártya. Ez úgy van megoldva, hogy ezen a dekóder kártyán
+akár AVI-t is lejátszhat az ember megfelelõen kemény vas esetében.
</p>
<!-- content end -->
1
0
30 May '05
CVS change done by Mizda Gábor CVS
Update of /cvsroot/mplayer/homepage/essays/src
In directory mail:/var2/tmp/cvs-serv22107
Added Files:
konf2002-arpi.src.hu
Log Message:
synced with 1.1, new file from HTML
--- NEW FILE ---
<!-- content begin -->
<!-- synced with 1.1 -->
<h1>Az UHU-Linux által támogatott fejlesztõk bemutatkozása</h1>
<h2>Gereöffy Árpád elõadása: Az MPlayer videólejátszó bemutatása</h2>
<img class="left-inset" src="../essays/images/logo.png" alt="MPlayer Logo">
<p>
Én az MPlayer-rõl fogok beszélni, amely egy videó lejátszó program,
elsõsorban LINUX alá, de ma már szinte minden UNIX-like platformon fut,
beleértve a BSD-ket, Solarist és a MacOS 10-et is.
</p>
<p>
A project elsõdleges célja az internet fejlõdésével egyre elterjedtebbé vált
video formátumok, így az MPEG, QuickTime, Windows Media, RealVideo lejátszása,
de mára már ezt a célt túlteljesítettük, nem csak hogy kevesebb erõforrást
igényel a lejétszéshoz, mint a formátumok eredeti lejátszóprogramjai, de
ezen felül jobb a hibatûrése, stabilitása, sõt, akár át is
konvertálhatókak vele ezek a file-ok nyílt szabványú formátumokba.
</p>
<p>
Amikor elkezdtem, még nem volt használható video lejátszó linuxra, nemhogy
olyan, ami egyben mindent le tudna játszani. Azóta egyébként készült elég
sok program, ami már így hasonló szinten van.
</p>
<p>
Az MPlayer fejlesztése két éve kezdõdött, egyedül álltam neki, viszont pár
hónap alatt - köszönhetõen annak, hogy nyílt forráskóddal indítottam, és a 0.01
verziótól kezdve ez az interneten elérhetõ volt, elég hamar sokan
bekapcsolódtak a fejlesztésbe. Gyakorlatilag fél év alatt egy világméretû
program lett, sõt a mai napra már majdnem 30 fõ fejlesztõ teljes szabadidejében
az Mplayeren dolgozik, és több százan küldözgetnek különbözõ patcheket,
javításokat is.
</p>
<p>
A diagramon a piros vonalnál látható a letöltések száma, látszik, hogy az
elmúlt másfél év alatt ez igencsak magas értéket ért el. A csúcsértékek mindig
egy-egy újabb stabil verzióhoz köthetõk.
</p>
<div class="center">
<img src="../essays/images/konf2002-stats.png" alt="Fejlesztés">
</div>
<p>
A sárga görbe a kódhoz havonta hozzáadott sorok számát mutatja. Ez, tudom,
kicsit relatív mértékegység (microsoftos módszer), mindenesetre nagyjából
tükrözi a fejlesztés aktivitását. Ez durván egy éve tetõzött. Azóta inkább nem
új dolgokat teszünk bele a kódba, hanem a meglévõket próbáljuk javítani,
gyorsítani, de még mindig vannak újabb és újabb funkciók.
</p>
<table class="left-box" border="0" cellpadding="2">
<tr><th colspan="4"><a href="http://www.freshmeat.net/stats">www.freshmeat.net/stats</a></th></tr>
<tr><td> 1.</td><td><b>MPlayer</b></td><td>50,576</td><td>100%</td></tr>
<tr><td> 2.</td><td>Linux </td><td>39,514</td><td>78.13%</td></tr>
<tr><td> 3.</td><td>cdrecord </td><td>26.954</td><td>53.29%</td></tr>
<tr><td> 4.</td><td>xine </td><td>20.355</td><td>40.25%</td></tr>
<tr><td> 5.</td><td>Gaim </td><td>18.192</td><td>35.97%</td></tr>
<tr><td> 6.</td><td>gcc </td><td>17.199</td><td>34.01%</td></tr>
<tr><td> 7.</td><td>MySQL </td><td>17.028</td><td>33.67%</td></tr>
<tr><td> 8.</td><td>Nmap </td><td>16.211</td><td>32.05%</td></tr>
<tr><td> 9.</td><td>TightVNC </td><td>15.546</td><td>30.74%</td></tr>
<tr><td>10.</td><td>Apache </td><td>15.171</td><td>30.00%</td></tr>
</table>
<p>
A 0.90pre verzió kiadásakor, ami idén április végén, májusban volt, annyira
megnõtt a letöltések száma, hogy az egyik legnépszerûbb linuxos portál, a
http://freshmeat.net statisztikáján az elsõ helyre ugrott a program. Megelõzött
olyan projekteket, mint például a Linux kernel, vagy a nagy konkurens
videólejátszó, a xine, de például a GCC és egyéb programok is lejjebb
szorultak.
</p>
<p>
Megint csak vitatható ennek a statisztikának a létjogosultsága, mert általában
azok a programok kerülnek ide fel, amik nagy közönséget céloznak meg, vagy amit
nagyon sok felhasználó használ, így amelyikben akár több munka van, vagy több
fejlesztõ vesz részt a fejlesztésben, de ennek ellenére kisebb célközönség
használja a programot, azt nyilván nem fogják annyian letölteni, tehát ezek nem
is fognak ilyen toplistákra felkerülni.
</p>
<p>
Elég sok linuxra írt videolejátszó program létezett már két éve is. Amit
vastagon jelöltem, az a néhány még a mai napig fejlesztés alatt áll. Amelyeket
ki lehet közülük emelni, az az MPlayeren kívûl a xine, illetve az Avifile. Ezek
többé-kevésbé lejátsszák a mai médiaformátumokat.
</p>
<div class="right-box">
<h3>Linuxos videó lejátszók 2 éve</h3>
<p><b>Avifile</b>, DVDview, Gstreamer, Kmpg,<br>
LAMP, LiViD/OMS, <b>MPlayer</b>,<br>
mpeg2dec, MpegTV, <b>Ogle</b>, SMpeg,<br>
<b>VideoLan</b>, XMMP, XMPS, <b>XMovie</b>,<br>
Xanim, <b>xine</b>, Xtheater, ZZplayer
</p>
</div>
<p>
A többi inkább egy-egy formátum lejátszására specializált program. Az ogle
például a DVD lejátszást tûzte ki céljául, s abból talán a legjobbnak
mondható. Az XMovie inkább a quicktime-os dolgokra koncentrál. Érdemes
kiemelni az Open Media Systemet, amelyet gyakorlatilag már több mint egy éve
nem fejlesztenek. Ez annak idején, két éve olyan projektnek indult, ami majd
összefogja a linuxos lejátszó világot, és egységes szabványt teremt, codec
interface-t. Erre azért volt szükség, hogy elkerülhetõ legyen az, hogy
mindenki elkezdi a nulláról ugyanazt megírni. Sajnos kudarcba fulladt a
munkájuk, eleinte kicsit túlbonyolították a dolgokat, s utána csak feladat
listák maradtak, de nem volt, aki ezt megírta volna. Végül is a projekt
elhalt, és kis külön programok fejlõdtek tovább.
</p>
<div class="left-box">
<h3>SourceForge.net'2001</h3>
<ul>
<li>megbízhatatlan a CVS</li>
<li>lassúlnak a levlisták <sup>*</sup></li>
<li>nincs Reply-To:</li>
<li>nincs levlista archívum <sup>*</sup></li>
<li>megszünik az FTP</li>
<li>egyre több reklám, banner</li>
</ul>
<p><small>(<sup>*</sup> <i>2002-ben megoldva</i>)</small></p>
</div>
<p>
Nem volt zökkenõmentes az Mplayer útja. A projektet eleinte - amikor elkezdtek
többen bekapcsolódni a fejlesztésbe - a SourceForge szerverére raktam fel.
Viszont 2001-ben, amikor a VA-Linux-szal problémák voltak, és a cég a csõd
szélére került, elkezdték átszervezni magukat, akkor többek között a
SourceForge-tól elvonták a pénzt, és ez megérzõdött rögtön a szolgáltatásaikon
is.
</p>
<p>
Az elsõ és legnagyobb problémánk az volt vele, hogy a CVS szolgáltatásuk
kezdett megbízhatatlanná válni. Az anonymous felhasználók CVS letöltéseinél
beragadtak idõnként lock fájlok, és ez napokig akadályozta azt is, hogy a
fejlesztõk hozzáférjenek a kódhoz.
</p>
<p>
A levelezõ listáikat lassan nem bírták erõforrással, és egyre lassabban jöttek
meg a levelek. Egy ilyen fejlesztésnél, online beszélgetésnél elég zavaró volt,
hogy az ember válaszolt valamire, azt másfél óra múlva megkapta az illetõ, az
is válaszolt, másfél óra múlva megjött a válasz a kérdésre... Persze lehet
mondani, hogy át kellene térni IRC-re és más módszerekre. Tehát a levelezõ
listákkal ez volt a fõ problémánk. Végül is ezt próbálták õk úgy orvosolni,
hogy a Reply-To mezõt kivették a levelezõ listákról, hogy a válaszok ne a
listákra menjenek, hanem közvetlenül a feladónak, de ezzel igazán nem érték el
a céljukat. Továbbá a levelezéseknek archívuma sem volt, tehát nem lehetett
visszakeresni, például új fejlesztõk nem tudták megnézni, hogy a régebbi
diskurzusok mirõl szóltak. Aztán megszüntették az FTP-t is, ami nekünk elég
fontos volt, mert FTP-n tudták a felhasználók az éppen le nem játszható
fájlokat feltölteni, s így meg tudtuk nézni, hogy az adott file esetében éppen
mi a probléma. Az utóbbi idõben elkezdtek egyre több reklámot is feltenni.
Addig is voltak banner-ek az oldalon, de addig opensource, ingyenes programokat
reklámoztak, és késõbb ezeket fizetett hirdetésekre cserélték le, sõt
mostanában már a Microsoft féloldalas hirdetéseit is olvashatjuk.
</p>
<div class="right-box">
<h3>Az UHU Linux támogatása</h3>
<ul>
<li>Domain név regisztráció</li>
<li>Dedikált szerver gép (P3-733, 512Mb, RAID)</li>
<li>DVD drive-ok</li>
<li>VGA kártyák</li>
<li>GUI fejlesztés támogatása</li>
</ul>
</div>
<p>
Ekkor jött a képbe az UHU-Linux. Támogatásuk elsõ lépésében az mplayerhq.hu
domain regisztrációval és az MPlayer számra dedikált szervergéppel segítettek
minket. Egy hónap alatt átköltözött a projekt erre a szerverre, és a mai napig
gyakorlatilag ezen fut. Ezen fut a CVS-tõl kezdve a web, levelezõ listák, s
minden ilyen szolgáltatás. Ez nem csak azért volt érdekes, hogy megoldódtak a
SourceForge problémái, de olyan dolgokat is meg tudtunk oldani a szerveren, amit
addig nem lehetett volna. Pl. a CVS-nél a fájl átnevezést, bizonyos mûveleteket
csak a szerveren shell-bõl lehet elvégezni, ezeket a SourceForge nem tette
lehetõvé. Lehet nagyon sok mindent automatizálni, pl. a napi CVS buildeket, vagy ha
valaki módosít a dokumentációban, az rögtön felkerül a webre, sõt küld egy
üzenetet a mirror gépeknek, hogy töltsék le, és frissítsék õk is az oldalt.
</p>
<p>
A késõbbiekben folytatódott az UHU támogatása, a fejlesztõknek különbözõ
hardver eszközöket adott az UHU ahhoz, hogy különbözõ hardvereket tudjunk
támogatni. Az UHU elõadáson pont errõl volt szó, hogy az UHU-Linux is ilyen
gondokkal küszködik, nem tudnak mindenféle hardveren tesztelni. Ez a probléma
felmerült nálunk is. Szerencsére nekünk nem kell 25 féle hardver típus, igazán
egy-két konkrét eszköz fontos, leginkább a videokártyák. Ugyanis a
videokártyákhoz a Linux alatt még a driverek elég szegényesek multimédia terén.
Az, hogy van kép az Xserver alatt, az még messze nem elég ahhoz, hogy ezen
videot is lehessen lejátszani. A videokártyáknak általában képszinkronizálási,
pufferezési, scaling, colorspace konverziót és mindenféle olyan belsõbb dolgait
is el kell, hogy érjük, amiket az X-es driverek nagyrészt nem tesznek lehetõvé.
Nekiálltunk, és mi is fejlesztünk a videokártyákhoz drivert, ezekrõl még lesz
szó.
</p>
<p>
Az UHU-val kapcsolatban elmondom, bár az elõzõ elõadásban is elhangzott, hogy
régebben ilyen koprodukció volt, tehát õk segítettek hardver eszközökkel, mi
pedig cserébe ezeken is teszteltük mind az UHU-Linuxot, mind a saját
fejlesztéseinket, s mi is tudtunk nekik segíteni abban, hogy pl. milyen
kártyához mely drivereket célszerû használni, mikre kell figyelni a
beállításoknál. Illetve még az UHU Linux szponzorálta a GUI fejlesztését is,
utánam Ponekker Zoltán fog errõl mondani pár szót, illetve megmutatja, hogy mi
is az.
</p>
<div class="left-box">
<h3>Mi a végcél???</h3>
<ul>
<li>"Világuralom? :)" - <i>Gabucino</i></li>
<li>v1.0?</li>
<li>egy felhasználóbarát lejátszó?</li>
<li>mplayer desktop environment?</li>
<li>...</li>
</ul>
</div>
<p>
Felmerül mindig a kérdés, meg is szokták kérdezni, hogy mi a végcél. Megy a
fejlesztés, egyre több kódot írunk, s végül is mikor fogunk megállni, vagy
mikor mondjuk azt, hogy kész. Erre többféle választ is szoktak adni. Pl.
az egyik, ha azt mondjuk, hogy az 1.0 verziónál abbahagyjuk, de közismert, hogy
nincs kész program, csak olyan, aminek abbahagyták a fejlesztését. Tehát
valószínûleg nem fogjuk abbahagyni, mindig újabb és újabb ötletek fognak jönni.
A felhasználóbarát lejátszó - jó kérdés, valamerre erre haladunk, de nem ez az
elsõdleges célunk. MPlayer Desktop Environment - ez egy kicsit viccesen
hangzik, de fejlesztés közben elég sok problémával találtuk szembe magunkat,
hogy legyen szó a CVS-rõl, a C-fordítókról vagy akármirõl.
</p>
<p>
Többször merült fel,
hogy ebbõl meg abból sajátot kellene írnunk. Jobb lenne, ha írnánk saját
C-fordítót, saját X-terminált stb. S jöttek az ötletek, és ezek elõbb-utóbb meg
is valósulnak, mint ahogy több minden megvalósult már az idõk folyamán. S ha
ezekbõl elég sok megvalósul, akár egy ilyen futurisztikus dolog is
elképzelhetõ. Esetleg - Gabucinot idézve - világuralom. Persze ezt nem kell
komolyan venni, sõt, nem célunk a többi lejátszóval konkurálni. Nem célunk
azoknak a felhasználótáborát elhódítani, már csak azért sem, mert igazán nincs
szükségünk több felhasználóra.
</p>
<div class="right-box">
<h3 class="center">R T F M !</h3>
<h3>Read The Fine Manual</h3>
<h3>Olvasd el a leírást</h3>
</div>
<p>
A felhasználók inkább csak gondot okoznak, mint elõnyt. Az
az igazság, hogy az MPlayer fejlesztése nem egy kattintgatós programnak indult
eredetileg, bár most már ezen a GUI javított elég sokat. Ha az ember rendesen
tudja használni, s bekonfigurálni úgy, hogy az adott hardvert az utolsó bitig
ki is tudja használni, ahhoz nem árt a leírás elég sok részét elolvasni, s az
alapján a különbözõ parancssorokat, beállításokat megcsinálni. Általában a
legtöbben ezt nem végzik el, letöltik, beírják, hogy "mplayer", nyomnak egy
entert, s rögtön jön a levél, hogy nem mûködik, segítsetek.
</p>
<p>
Az a baj, hogy a
felhasználók 99%-a ilyen, s nagy részük meg is írja ezt a levelet. Nos, a
felhasználóknak körülbelül az egy ezreléke az, akik ténylegesen segítenek, akik
tényleg bugreportolnak. Akik küldenek olyan fájlokat, amelyet le kellene tudnia
játszania a programnak, és például más programok lejátsszák, ez nem. Meg tudjuk
nézni, mi okozhatja a hibát, ki tudjuk-e javítani, illetve ezek a felhasználók
tudnak írni újabb hardverekrõl, amelyeket esetleg nem támogatunk. Ezek esetében
megnézzük, hogyan lehetne módosítani, míg mások küldenek esetleg patch-eket.
</p>
<div class="left-box">
<h3>Kooperáció</h3>
<ul>
<li><b>Avifile</b>: .DLL loader / win32 emu</li>
<li><b>VideoLAN</b>: DVD/DeCSS</li>
<li><b>xine</b>: SVQ1 codec</li>
<li><b>FFmpeg</b>: libavcodec</li>
<li><b>OMS</b>: libmpeg2, libac3</li>
<li><b>Mpeg2dec</b>: libvo</li>
<li>...</li>
</ul>
</div>
<p>
Inkább kooperálunk a többi programmal, minthogy elhódítanánk a
felhasználóikat. Más a felhasználói táborunk, más a célunk, más a célja az
MPlayernek, más a célja a xine-nak, más a Avifile-nak. Az opensource projektek
is azért élnek ma még párhuzamosan, mert különbözõ célkitûzéseik vannak. Ha
ugyanaz lenne a céljuk, akkor nem létezne annyi program. Ehelyett inkább
közösen dolgozunk különbözõ projekteken, olyasmin amire mindenkinek szüksége
van, és végül is minden programban megtalálható.
</p>
<p>
Például az avifile-osokkal közösen fejlesztettük ki a DLL betöltõt. Ennek az
a lényege, hogy a Windows alá írt video és audio kodekek használhatók ennek
segítségével Linux, BSD, Solaris alatt az x86 platformon.
Gyakorlatilag kicsit trükkös megoldás, a Wine és a Wabi windows emulátoroknak
egy része van felhasználva. Ennek az a lényege, hogy a DLL-t úgy be tudja
tölteni Linux alatt, mint egyéb linuxos dinamikus libeket. Ha egyszer
betöltötte, az majdhogynem mûködik is, mert a codecnek nincs nagyon szüksége a
windowsos funkciókra. Tehát nem fog ablakokat kirakni, nem fog különbözõ
windows-specifikus dolgokat csinálni, általában csak valami adathalmazból
átkonvertál valamit egy másik adathalmazba. Viszonylag minimális windows
függõsége van, ezt a pár alapfunkciót emulálja ez a lib.
</p>
<p>
A VideoLAN-nal közösen dolgoztunk a dvdread, dvdcss kódon, ez a DVD-k
olvasásához volt szükséges. Elsõsorban õk fejlesztették, de utána mi is
küldtünk rá patch-eket. A xine-tõl vettük át az SVQ1 videó kodeket, ez egy
Quicktime formátum, a Sorenson 1 dekódere. Végül is õk fejlesztették
valamennyire ki, igaz, hogy egy volt MPlayer fejlesztõ segítségével, illetve õk
is vettek át tõlünk különbözõ kódokat. Az FFMpeg projekttel közösen dolgozunk a
libavcodecen, ez egy opensource kodek gyûjtemény, ami a mai elterjedt MPEG4,
MPEG1/2, MJPEG, H.263 video, illetve mostanában már windows média video, windows
média audio formátumokat is tudják dekódolni.
</p>
<p>
Az OMS projektbõl - amirõl említettem már, hogy megszûnt - vettük át az MPEG2,
illetve AC3 kodeket, amelyek DVD lejátszáshoz voltak szükségesek. Ezek mára már
eléggé továbbfejlõdtek, optimalizáltuk ezeket. Most már libac3 helyett liba52
van, ez már egy újabb változat. A volt mpeg2dec projekt libvo-ján alapul az
MPlayer libvo-ja is, illetve túl sok köze nincs már hozzá a nevén kívül, mert
eléggé át lett írva, de nyomokban felfedezhetõ az örökség.
</p>
<div class="left-box">
<h3>A lejátszó idõzít, nem az OS ütemezõje!</h3>
<ul>
<li style="display:block"><b>+</b> a lejátszó tudja, mikor mire van szüksége</li>
<li style="display:block"><b>+</b> nincs lock-olás, mutex-ek</li>
<li style="display:block"><b>+</b> nincs lassú thread- vagy task-switching</li>
<li style="display:block"><b>+</b> tisztább, átláthatóbb a kód -> kevesebb bug</li>
<li style="display:block"><b>+</b> egyszerübb a debug</li>
<li style="display:block"><b>-</b> nincs SMP kihasználás</li>
</ul>
</div>
<p>
A legfontosabb különbség mégis a programok között, s azt hiszem, az MPlayer
egyedülálló tulajdonsága, hogy az egész program egy szálon, egy processzben
fut, míg a legtöbb más lejátszó több szálon. Tehát külön szálon megy az audio
dekódolás, külön szálon a video dekódolás, külön szálon a video megjelenítés,
külön szálon a vezérlés stb. Tehát õk mindent külön vontak, mi viszont egy
szálon oldjuk meg az egész feladatot. Sokan vitatják, hogy ez jó vagy sem.
</p>
<p>
Itt elmondanék néhány érvet. Elsõ lépésben, legyen akármilyen jó az operációs
rendszer scheduler-je, tehát az idõzítõje, az soha nem fogja pontosan tudni,
hogy nekünk most hangra, képre vagy mire van szükségünk a folyamatban. Ezt a
lejátszó kernelje tudja gyakorlatilag, az pontosan meghatározza, hogy melyik
bufferban mennyi hely van, hogy most éppen videót vagy audiot akarunk
dekódolni, ha jött egy parancs a felhasználótól és azt végre kell hajtani.
Tehát a legjobb, ha a program maga idõzíti ezeket a feladatokat, s nem bízzuk
ezt az operációs rendszerre. Egy másik probléma az is, hogy a 2.2-es kernel - ami
még akkor volt, amikor ezt elkezdtem fejleszteni - de végül is a 2.4-es kernelben
sem olyan túl megoldott ez, azaz a szálak, illetve a processzek közötti
kapcsolás elég idõigényes. Ugye nem arra kell gondolni, hogy néhányszor
átkapcsolunk, hanem mondjuk egy 30 FPS-es video lejátszásakor plusz még hang
dekódolásnál ez több száz átkapcsolást jelenthet másodpercenként, s tekintve,
hogy a Linux idõzítõje, legalábbis a 2.4-es kernelig 100 Hz-en mûködik, ez
nagyon kevés a video lejátszásra, gyakorlatilag 33, illetve 40 millisecenként
kellene váltanunk. Ehhez a 10 millisec pontosság kevés volt.
</p>
<p>
A 2.5-ös kernelbe bekerült a gyorsabb szálváltás, azt hiszem, átállították 1000
Hz-re az alapfelbontást is, tehát valamennyire közelítenek, de igazából nem látjuk
értelmét, hogy emiatt többszálúra átírjuk a programot. Másrészt, amellett, hogy
a taskváltást megspóroljuk, van még egy hátulütõje, azon kívül, hogy az
operációs rendszer hogyan kezeli le. Ezek a kodekek már elég jól ki vannak
optimalizálva a CPU CACHE használatára. Nem tudom, ki mennyire van benne elvi
szinten az Intel platform programozásában, de itt, fõleg az újabb
processzorokban már külön lehet CACHE vezérlõ parancsokat kiadni, hogy miket
töltsön be elõre a CACHE-be, ki van arra élezve, hogy mi van az elsõdleges, mi
a másodlagos a CACHE-ben, és úgy van optimalizálva a kód, hogy a regisztereken
túl pl. a CACHE-re is számít, hogy abban éppen mi lesz, s azt gyorsan fogja
elérni. Viszont taszkváltás esetén a CACHE törlõdik, és a másik taszk fogja
újra tölteni az adataival, emiatt ez nekünk nem túl nyerõ, mivel ilyenkor sûrûn
váltunk taszkot. Mondjuk egy video frame dekódolása közben kétszer-háromszor
átváltunk, akkor állandóan törlõdik a CACHE, és kezdhet minden adatot újra
betölteni. Ez elég idõigényes, és ezek a memóriák nem túl gyorsak. További
elõnye az egyszálú megoldásnak, hogy tisztább, átláthatóbb lett a kód, tehát
nem kell több szálban gondolkodni, nem kell több szálat egyszerre összehangolni,
ezek között mutexelni illetve lockolni, megmondani, hogy mikor melyik szál a
másikat nem szakíthatja meg stb.
</p>
<p>
Tehát ezeket a problémákat gyakorlatilag mind megúsztuk, s mivel ennyire
egyszerûsödött a kód, gyakorlatilag a hiba is kevesebb benne, és a stabilitása
jelentõsen javult, legalábbis hasonló problémákkal mi nem találkozunk.
Egyszerûbb lett így a hibakeresés is: egy szálon fut a program, van egy adott
feladat lista, amit végre kell hajtson, ha valahol megáll, meg lehet nézni,
hogy miért ott állt meg. Amikor több szál fut egyszerre, akkor lehet, hogy az
egyik szál okozta a másik hibáját, ezeket mi megússzuk.
</p>
<p>
Van persze egy nagy hátránya is ennek a dolognak, az, hogy a multiprocesszoros
gépeket nem lehet kihasználni. Viszont ha jobban belegondolunk, az nem nagy
probléma, mert végülis az MPlayert nem szervereken szokták futtatni. Itt egy
videolejátszóról van szó, desktop gépekre nem annyira jellemzõ, hogy több
processzor lenne bennük, márpedig ha több processzor is van bennük, általában
egy processzor is több mint elég, a videodekódoláshoz, tehát nincs igazán
kihasználva még az az egy processzor sem, nemhogy szükség lenne még egyre. Azt
esetleg lehet addig más programok futtatására használni, vagy több MPlayert
lehet futtatni egyszerre.
</p>
<div class="left-box">
<h3>Támogatott formátumok</h3>
<ul>
<li>MPEG1 (VCD), 2 (SVCD/DVD/DVB), 4 (.MP4)</li>
<li>AVI, DivX (support of Windows DLLs!)</li>
<li>ASF, Windows Media Audio/Video 7/8</li>
<li>RealAudio/Video G2, 8.0, 9.0, RealOne</li>
<li>Quicktime (Cinepak, Sorenson1)</li>
<li>VIVO 1.0, 2.0</li>
<li>DV PAL/NTSC (Sony Digital Video)</li>
<li>FLI, RoQ, SMJPEG, NuV, Y4M, FILM, PVA ...</li>
</ul>
</div>
<p>
Jelenleg a Linux alatt lévõ lejátszók közül az MPlayer támogatja a legtöbb
videoformátumot, röviden átfutva rajta: - a szabványos MPEG 1, azaz Video
CD, MPEG 2-es, ami a DVD, DVB, és használható az MPEG4 is. Az MPEG4 alatt az
összes általunk ismert MPEG4 kodeket, beleértve a DivX variációkat,
Microsoft "MPEG4" verzióit mind támogatjuk, legalábbis, amik eddig vannak
rendelkezésünkre fájlok, ezeket mind tökéletesen lejátssza.
</p>
<p>
A windows alatt elterjedt AVI fájlformátum végülis inkább csak ilyen nagyon
tág definíció, mert az csak a fájlformátumot adja meg, azon belül szinte
bármilyen kodek használható, de miután a windowsos DLL-eket is támogatjuk,
így gyakorlatilag szinte minden fájl lejátszható. Nagyon kevés olyan DLL
van, amivel esetleg problémák vannak, mert pl. 16 bites windowsra írták és
nem mûködik a mi emulátorunkkal.
</p>
<p>
Az utóbbi idõben elterjedt a <i>windows média audio/video</i>, korábbi nevén az
<i>ASF formátum</i>. Ebbõl is a 7, 8-ast gond nélkül le tudja játszani. A 7-es
videohoz, illetve a 7, 8-as audiohoz most már van natív kód is, nincs szükség a
DLL-ekre. A 8-on még dolgoznak, de az is elõbb-utóbb meg lesz oldva. Az utóbbi
idõben megjelent a 9-es változat, azt hiszem, még csak béta változatban windowsra,
ez még nagy kihívás számunkra, miután változtatott a Microsoft a kodek formátumon,
tehát nem kompatibilis a korábbi DLLekkel, tehát egy újabb interface-t kell
majd írnunk hozzá.
</p>
<p>
<i>RealAudio</i>, <i>RealVideo</i>: elméletileg az összes verziót támogatjuk, a
régebbi verziókhoz van natív dekóder, az újabb verziókat a lejátszóhoz adott
végülis bináris pluginek felhasználásával tudjuk lejátszani. Megjegyzendõ, hogy
ezek nem csak x86 platformon mûködnek, a lejátszót nagyon sok platformra kiadták,
minden platformra az adott platformú pluginjeit lehet betenni alá.
</p>
<p>
A <i>Quicktime</i> formátum a Macintoshtól ered, szintén lejátszható. Itt probléma
van a kodekekkel, miután elég extrém és általában zárt szabványú kodekeket
használnak. Itt néhány régebbi formátum vissza van már annyira fejtve, hogy
ezek lejátszhatók, de pl. a Sorenson 3, illetve a QDM audioval még gondok
vannak. A napokban dolgozunk egyébként azon, hogy a windowsos Quicktime lejátszó
pluginjeit fel tudjuk használni, így ezek is lejátszhatók lennének legalább
az x86 platformon.
</p>
<p>
<i>Vivo 1, 2</i> - talán valaki még emlékszik rá, néhány évvel ezelõtt volt windowson
elterjedt formátum. Az utóbbi években kihalt a közéletbõl, fõleg az ASF-nek
köszönhetõen.
</p>
<p>
A <i>Sony digital video</i>, a DV formátumhoz most van kb. négyféle dekóder,
ebbõl két nyílt forráskódú és két DLL, lehet válogatni, különbözõ sebességûek,
illetve tudásúak.
</p>
<p>
Illetve van elég sok régi fájlformátum: különbözõ játékprogramok
fájlformátumai, illetve ritkábban használt média szerkesztõ programok saját
formátumai, azokat is általában le tudja játszani, ezeket általában nem mi
írtuk, hanem az ilyeneket igénylõ felhasználók készítették a patch-et és
küldték el nekünk.
</p>
<div class="right-box">
<h3>Támogatott video output eszközök</h3>
<ul>
<li><b>X11</b>: Shm, Xvideo, GLX/OpenGL, DGA 1/2</li>
<li><b>Linux</b>: framebuffer, svgalib, VESA, mga_vid</li>
<li><b>Wrappers</b>: SDL, GGI, DirectFB, VidiX, AAlib</li>
<li><b>HW decoders</b>: dxr2, H+/dxr3, dvb, zoran</li>
<li><b>Images</b>: gif89, png, jpeg, pgm, yuv4mpeg</li>
</ul>
</div>
<p>
Az MPlayernek van még egy nagy erõssége a többi lejátszóhoz hasonlítva: a
kimeneti formátumok, az output eszközök támogatása. A legtöbb lejátszó X11-et
igényel, s azon belül is egy-két funkciót tud kihasználni. Mi az X11-bõl
kihasználjuk gyakorlatilag az összes lehetõséget, tehát mind a sima XImage-s
XSHM módot, mind az Xvideo-t, ami a 4.X-el került bele. Ha az OpenGL-hez van
megfelelõ hardver gyorsítás, akkor azt is lehet használni video lejátszásra,
illetve DGA1, DGA2 verziót is teljes képernyõs lejátszásnál. Ezenkívül, ha
nincs X11 a gépen, vagy nem szeretnénk használni - beágyazott rendszereknél ez
gyakori probléma -, akkor használható a Linux framebufferje, az SVGAlib, tudja
a program használni a kártya VESA BIOS-át is, gyakorlatilag semmilyen linuxos
driverre nincs szükség: még ha nincs a kártyához linuxos driver, akkor is
mûködhet a dolog, egyszerûen DOS emulációs módon keresztül a VGA kártya BIOS-án
keresztül bekapcsolja a grafikus módot, lekérdezi a paramétereit, és
közvetlenül a kártya memóriájába ír. Így végül is minden kártya vezérelhetõ
vele.
</p>
<p>
Mi is fejlesztettünk hozzá drivereket, ezekrõl mindjárt szó lesz. Például ilyen
az mga_vid, ami a Matrox videokártyához írt speciális driver. Vannak még ilyen
köztes libraryk, amit wrappereknek hívunk, más interface-k és a program közötti
áthidalást végzik. Ilyen az SDL, a GGI, DirectFB, illetve az általunk
fejlesztett Vidix. De ilyen a szöveges módokra kitalált AAlib is. Hardveres
dekóder kártyákat is támogat a program, illetve képkockánként ki lehet
képfájlokba is menteni a videot, ha valaki ilyesmit szeretne mûvelni.
</p>
<div class="left-box">
<h3>Közvetlenül támogatott VGA kártyák</h3>
<ul>
<li><b>mga_vid</b>: Matrox G200, G400, G450, G550</li>
<li><b>vidix</b>: ATI mach64, Rage 128, Radeon</li>
<li><b>tdfxfb</b>: 3Dfx Voodoo 3/Banshee</li>
</ul>
</div>
<p>
Említettem a video drivereket. Az mga_vid a Matrox G200 és afölötti kártyáit
támogatja. Itt az a nagy problémánk (ezért is kezdtünk neki saját magunk
video drivereket írni), hogy bár az utóbb pár év alatt elég sokat fejlõdött
a video driverek minõsége, illetve támogatottsága, de még mindig messze
vannak attól, hogy teljes mértékben ki tudják használni a kártyák
videolejátszási képességét. A Matrox videokártyák hardveresen négy video
buffer között tudnak maguktól kapcsolni amikor az elektronsugár visszafelé
fut (tehát a vertikális retrace idõ alatt), így a képen tehát nem látszanak
csíkozások, villogások. Illetve a videokártya RAM-jába is lehet tenni ezeket
a buffereket, tehát õ automatikusan onnan fogja kiolvasni.
</p>
<p>
Ezeket az X-es driverekkel nem lehet megoldani, mert az X is a
rendszermemóriába teszi a képet, onnan másolja át egy külön processz a
videokártya memóriába, s ott is maximum két buffert tud. Tehát vannak ilyen
problémák, amiket ki lehet küszöbölgetni, de ezek mind a teljesítmény és a
képminõség rovására mennek. A VIDIX driver egy unified rendszer, amely
egységesíti az általunk fejlesztett video driver interface-eket. Úgy
keletkezett, hogy az ATI kártyákhoz készült driverekhez hozzáfejlesztettünk,
de a többi maradt a saját egyéni interface-ével.
</p>
<p>
A Linux kernelben van egy TDFXFB nevû driver, amely lehetõvé teszi a 3Dfx
régebbi kártyáinak a teljes mértékû kihasználását. Ebben is nagy segítséget
jelentett nekünk az UHU, miután nélkülük nem tudtunk volna ennyiféle kártyán
tesztelni, illetve fejleszteni, ezeket is õk biztosították számunkra. Illetve
sokan kértek az nVidia kártyák támogatását. Nem tudom, ki volt a Free SW
fórumon az ebédszünetben, felmerült pont ez a téma, hogy a hardvergyártók nem
adnak ki semmi dokumentációt a chipekre. Az nVidiával is az a fõ problémánk,
hogy a gyártó megtagadja mindenféle informácó kiadását, míg a Matrox, a ATI
vagy a 3DFX kiadott minden szükséges anyagot, legalább a fejlesztõknek. Az
nVidiánál csak arra tudunk támaszkodni, hogy a Linux alatt kiadott bináris
drivereket visszafejtegetjük, nézegetjük, vajon hogy mûködhet ez, kitalálni
régebbi kódokból - de ez így elég nehézkesen halad. Már jó pár hónapja
dolgozunk rajta, de még valószínûleg legalább ennyi lesz, amíg valami
mûködõképes kódot készítünk, s lesz még egyszer ennyi, amíg valóban optimális
kód lesz. Mindenesetre tervbe van véve. Remélem, hogy a jövõben a
videokártya-gyártók megpróbálnak vagy õk maguk fejleszteni ilyesmit, pl. Vidix
alá drivereket, vagy legalább kiadják a szükséges dokumentációt, hogy legalább
így támogassák a fejlesztést. Sajnos egyelõre nem nagyon érdekli õket a Linux
alatti video lejátszás, mert ha Linux-szal foglalkozik is egy-egy gyártó, az
inkább csak a szerver platformban érdeklõdik.
</p>
<div class="right-box">
<table border="0" cellpadding="2">
<tr>
<td colspan="4"><b>MPlayer "stabil" verziók</b></td>
</tr>
<tr><td>v0.01:</td><td>2000.</td><td>Nov</td><td>01.</td></tr>
<tr><td>v0.10:</td><td>2001.</td><td>Jan</td><td>01.</td></tr>
<tr><td>v0.17:</td><td>2001.</td><td>Apr</td><td>27.</td></tr>
<tr><td>v0.50:</td><td>2001.</td><td>Oct</td><td>08.</td></tr>
<tr><td>v0.60:</td><td>2002.</td><td>Jan</td><td>03.</td></tr>
<tr><td>v0.90:</td><td>2002.</td><td>???</td></tr>
<tr><td>v1.0:</td><td>????</td></tr>
</table>
</div>
<p>
Az MPlayer verziószámozása elég érdekes probléma. A 0.01 verzió két nap
híján két éve lett kiadva, azóta érdekes verziószámok jelentek meg. Ezeknek
hosszú története van, hogy melyik verzió miért ennyi. Mégis lényeges az,
hogy a 0.90-es verziót április óta húzzuk, halasztjuk. Áprilisban jelent meg
az elsõ Pre beta verziója, azóta kiadtunk már 9 pret, illetve kiadtuk volna
tegnap a 10-est, de az el lett megint tolva, s végül is 0.90 stabil verzió
nem tudom mikor lesz ténylegesen, valószínûleg néhány hónapon, illetve héten
belül.
</p>
<p>
Az a probléma, hogy nem akarunk, illetve nem is tudunk fix
határidõket szabni, nem mondhatom, hogy január 8-án kiadjuk a 0.90-et,
addigra mindenki mindent csináljon meg, s minden legyen stabil. Sajnos ez
nem így mûködik, egyrészt mert a fejlesztõk ezt hobbiból csinálják, és ez
egy teljesen nonprofit projekt. Tehát nem mondhatjuk valakinek azt, hogy
márpedig ezt te holnapra fogod megírni, és kész legyen, mert emellett más
dolguk is van az embereknek, tanulnak, dolgoznak. Tehát erre nem lehet
számítani. Másrészt a fejlesztés jelentõs része, valószínûleg több mint a
fele abból jön, amiket nem is mi fejlesztünk, hanem közvetlenül a
felhasználók küldözgetnek nekünk patch-eket, javításokat, amikre végül is
nem lehet nagyon elõre építeni. Viszont általában egy-egy ilyen javítás
elindít egy egész lavinát, s egész sok kódot átalakítunk, amit az a
módosítás indított meg, az világított rá, hogy azt szükséges átírni. Tehát
egy-egy ilyen patch érkezése elõfordul, hogy hónapokra eltolja egy-egy új
verzió kiadását, s már április óta így tologatjuk magunk elõtt, s még mindig
nem látjuk, hogy mikor fog megjelenni, de valószínû, hogy még az idei évben
kiadjuk. Az 1.0 megint jó kérdés. Kb. egy éve írtam egy listát, hogy
mi az, amit az 1.0-ba bele akarunk tenni, mi az, ami az 1.0 verzió
kiadásához szükséges. Azok már rég megvalósultak, de a lista fokozatosan
nõtt, mert amikor kitöröltünk egy sort, kettõt hozzáírtunk, tehát így soha
nem fog elfogyni, így valószínû, hogy ez majd valamikor jövõre fog
elkészülni. Igazából az MPlayernél azt a filozófiát követjük, hogy túl
szigorúra sem lehet venni a kiadás dátumait, de túl szabadra sem, úgyhogy
próbálunk tág határidõket szabni, csak nem nagyon sikerül betartani
egyelõre.
</p>
<div class="left-box">
<h3>Távlati tervek - v1.0 után</h3>
<ul>
<li>Videó szerkesztõ</li>
<li>Streaming server</li>
<li>Web-böngészõ plugin</li>
<li>Kódmodularizáció</li>
</ul>
</div>
<p>
Még néhány szót a távlati tervekrõl, hogy mi lesz az 1.0 után, ha
elkészül. Terveinkben szerepel például egy videoszerkesztõ program, a
szükséges kód magyrésze már rendelkezésre áll, (pl. kodekek, MEncoder,
demuxerek) tehát amire szükség van ahhoz, hogy egy fájlt olvassunk, írjunk,
dekódoljunk. Gyakorlatilag egy felületet kell hozzá létrehozni, illetve úgy
kell átalakítani valamennyire a kódot, hogy párhuzamosan több videofájlt is
fel lehessen vele dolgozni. Most úgy van megírva, hogy egyszerre egy fájlt
tud olvasni. Ezt viszonylag kis munkával át lehet alakítani, továbbá ilyen
"streaming" szervert, hogy lehessen pl. videokonferencia feladatokra, video
szolgáltatásra használni, szintén ehhez is majdnem minden megvan, a hálózati
részt kell hozzá implementálni.
</p>
<p>
Web böngészõ plugin, ezt nagyon sok
felhasználó kéri. Létezik több tõlünk független projekt, ami ezt próbálja
elérni, de valószínûleg ezt igazából teljes értékûen csak úgy lehet, ha ezt
magába az MPlayer kódba írjuk bele, külsõ vezérlõ kódokkal ezt nehéz lesz
megoldani. Kód modularizáció - ez végül is az utóbbi idõben kezdõdött el, s
folyamatosan dolgozunk rajta, hogy kicsit modulárisabbá tegyük az elég
monolitikus programot. Különbözõ libekre van szétszeparálva a program, s
ezek most már kezdenek lassan egymástól függetlenné válni. Ha akarja egy
program, az MPlayer egy-egy részét fel tudja használni. Arra is szükség van,
hogy a többi lejátszóval közösen tudjunk egy-egy részt használni, tehát
végül is átemelhetõek bizonyos modulok más programokba. Ezek a távlati
terveink.
</p>
<h3>Kérdések - válaszok</h3>
<p><b>K</b>: Ez a modularizációs ötlet nem jelenti azt, hogy az elszeparált
modulhatárok közötti adatcsere, átmenet, lassíthatja a lejátszást?</p>
<p><b>V</b>: A kérdés jogos, feltehetõen lassítani fogja, ezért megy ez ilyen lassan,
mert nagyon át kell gondolni minden egyes módosító lépést, hogy úgy
tudjuk átalakítani, hogy ne okozzon semmilyen lassítást, illetve
semmilyen hátrányt a kódban. A modularizáció mindenképpen az, hogy
egységesítjük a különbözõ viselkedési formákat, ráerõltetni egy közös
felületet, az biztos, hogy bizonyos funkciókat ki fogunk belõle venni,
illetve meg fogja bonyolítani azt, hogy a formátum specifikus opciókat
átadunk egy-egy dekódernek, amiket egy másik dekóder nem tud értelmezni.
Emiatt megy ez lassan. Most egy új konfig kódot készítünk, még nincs
benne a CVS-ben, mert elég béta állapotú, végül is ez próbálja majd azt
valamennyire egyszerûsíteni. Tehát egy-egy ilyen modul amikor indul, be
tudja regisztrálni egy központi konfig kódba azt, hogy õ milyen
funkciókat tud ellátni milyen protokollal. Végülis nem lesz annyira
ráerõltetve ilyen szabványos interface, hanem valamennyire meghagyjuk a
szabadságát, de azért megpróbáljuk úgy, hogy azt egy külsõ program is le
tudja kérdezni, megismerni mik a sajátosságai.</p>
<p>
A média fájlokból két alapvetõ fajta van, vannak az interleaved formátumok,
amikor folyamatosan van összekeverve a hang- és a videojel, és vannak olyan
fájlformátumok, amikor szét vannak ezek választva, tehát külön van a kép,
külön a hang a fájlban. Ezeket alapvetõen másként kell kezelni, ezért a
lejátszónak tudnia kell, hogy ez milyen jellegû. És nagyon sok ilyen apró
példa van még. Amiért az MPlayer elérte ezt a sebességet és stabilitást, az
az, hogy ezekre külön figyelünk. A többi lejátszó megpróbálta a kezdetektõl
fogva ráerõltetni egy közös felületre ezeket.
</p>
<p>
Ez az erõltetés elég találó szó, végül is ugyanez a probléma az X-es meg
mindenféle egyéb driverekkel, amikor videokártyákra próbálnak interface-t
erõltetni. Nagyon jó példát mondasz, például ez az, amiért a Matrox driver
át lett írva Vidix interface alá, de végülis még mindig a kernel drivert
használjuk, mert még mindig több minden funkciót el tud látni, mint amit a
Vidix egységesített felületén el lehet érni. Így aztán kitalálunk egy
felületet, de utána kiderül, hogy jön egy újabb kártya, aminek megint
másfajta jellemzõi vannak, ezeket megint nem lehet ráerõltetni, s valószínû,
hogy az X-nél pont ez a probléma. Az a másik gond, hogy az XVideo-t amikor
kitalálták pont erre célra, hogy video overlayt elérjenek, grabbelésre,
digitalizálásra találták ki, és utána tették bele a következõ kiadásnál,
hogy lejátszást is lehessen, de ez már kicsit "belegányolás" lett inkább,
mert alapvetõ funkciók például hiányoznak ebbõl, mondjuk képek
szinkronizálása, ami tv-kimenet esetén elég problémás, mert annak pont 25
Hz-en kell megjelenni, különben a képernyõn futni fog - ez a monitoron nem
látszik. Erre õk valószínûleg nem is gondoltak akkor, de késõbb már nem
tudják beletenni, mert akkor megint át kellene írni az egészet.
</p>
<p><b>Q</b>: Hallottál már ilyen irányzatról, hogy minél kevesebb interface
felhasználásával való programírás? Hogy érted? Pont annak az ellenkezõje,
amire mennétek, hogy modularizálni kellene a dolgot, hogy inkább jó a
monolitikus, és gyakorlatilag amit elérnétek a modularizációval, azt úgy
megvalósítani, hogy forrás szinten használja fel az a program az adott
modult, aminek szüksége van rá. Mert ha nem írtok annyi interface-t,
akkor a lényegi kód kisebb, kevesebb probléma származik abból, ha azt
felhasználják egy az egyben. Mintha jól körbecsomagolod.</p>
<p><b>A</b>: A jól körbecsomagolást próbáljuk mi is elkerülni, de annyira nem kell pl.
a GTK-hoz hasonlítani, ahol tényleg túl van bonyolítva, ahol sok réteg
van ráépítve. Mi igyekszünk egy réteget tartani, s azok is ilyen
opcionális függvények. A kodekek modulárisan lettek átdolgozva idén
tavasszal, ez a réteg úgy néz ki, hogy van egy általános struktúra,
amiben a kodek beállíthatja, hogy õ abból a funkcionalitásból melyik
funkciókat implementálja. S akkor meg kell nézni a lejátszónak, hogy
ezekbõl a funkciókból, amelyiket õ implementál, melyik a legoptimálisabb.
Tehát nem kell olyat implementálni, ami neki nem optimális.</p>
<!-- content end -->
1
0
[MPlayer-translations] CVS: homepage/essays/src konf2002.src.hu, 1.2, 1.3
by syncmail@mplayerhq.hu 30 May '05
by syncmail@mplayerhq.hu 30 May '05
30 May '05
CVS change done by Mizda Gábor CVS
Update of /cvsroot/mplayer/homepage/essays/src
In directory mail:/var2/tmp/cvs-serv9647
Modified Files:
konf2002.src.hu
Log Message:
synced with 1.3 (HTML fixes)
Index: konf2002.src.hu
===================================================================
RCS file: /cvsroot/mplayer/homepage/essays/src/konf2002.src.hu,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- konf2002.src.hu 12 Feb 2003 20:52:28 -0000 1.2
+++ konf2002.src.hu 30 May 2005 21:45:29 -0000 1.3
@@ -1,81 +1,80 @@
-<P><FONT CLASS="bigheader">
- Az MPlayer csapat a IV. GNU/Linux konferencián</FONT><BR>
- <FONT CLASS="header">írta: Gabucino</FONT>
-</P>
-
-<P><FONT CLASS="header">
- A konferenciáról
-</FONT></P>
-
-<P><FONT CLASS="text">
- Csak annyit tudok róla hogy a honosítás volt a fõ témája :D
- Azt kérdezed hogyan kerültünk akkor mi mégis oda? Nos, a szponzorunk, az
- UHU-Linux (akik mellesleg a rendezvény egyik fõ szerverzõi voltak)
- szerette volna ha szerény személyeink is jelen lennének. Ígyhát azt mondtuk,
- <I>"miért is ne, úgyis csak ritkán találkozunk"</I>, és elkezdtünk
- készülõdni. Hamarosan megegyeztünk hogy az összes fõbb magyar fejlesztõ
- eljön: A'rpi, Pontscho, al3x, és én: Gabucino.
-</FONT></P>
-
-<P><FONT CLASS="text">
- Sajnos végül nem csináltuk meg az RTFM pólókat (amikoris mindegyikünk
- viselne egy-egy betût, lehetne hullámozni, stb:). Talán majd legközelebb.
-</FONT></P>
-
-<P><FONT CLASS="header">
- Az utazás
-</FONT></P>
-
-<P><FONT CLASS="text">
- A rendezvény Budapesten volt megtartva, valamilyen hosszú nevû Grand
- Hotelben. al3x és én Szegedrõl vonattal utaztunk, a többiek már Pesten
- várakoztak. A vonat persze tele volt szegedi Linuxosokkal. Amikor
- elterjedt a hír hogy a vonaton tartózkodik két MPlayer fejlesztõ, azonnal
- egy külön luxuskocsiba szállítottak minket, aholis néhány szõke
- hosszúcombú... Khm, tehát akkor vissza a valóságba. :DD Pestre megérkeztünk,
- és a Blahán találkoztunk jól. Ez volt az eddigi legnagyobb találkozója
- MPlayer fejlesztõknek. Én már a Flag 2002-n találkoztam A'rpival és
- Pontschoval, így ez volt al3x "beavatása" :)
-</FONT></P>
-
-<P><FONT CLASS="text">
- Eztán az összeállt csapat vidáman vonul keresztül a városon, világuralomról,
- MPlayer Operációs Rendszerrõl, és hasonló csacskaságokról beszélgetve.
-</FONT></P>
-
-<P><FONT CLASS="header">
- A megérkezés
-</FONT></P>
-
-<P><FONT CLASS="text">
- Megérkezve a hotelbe, gyorsan (2 hét) bejutottunk. Hé. Itt nincsenek
- nõk, húzzunk el! ... Najó. Ez meg valami megfigyelõrendszer a projectoron.
- Elsõ pillantásra feltünt hogy milyen rettenetes az swscaler-je, ígyhát
- nem lehet MPlayer. A monitor-ra vetve figyelmes szemünket rögtön
- feltûnt az ablakkezelõ kísérteties hasonlósága a Win98-cal. Szerencsére
- elkezdõdött az elsõ elõadás, így nem tudtunk meggyõzõdni az igazságról.
-</FONT></P>
-
-<P><FONT CLASS="header">
- Késõbb: az UHU-Linux által támogatott project-ek bemutatása
-</FONT></P>
-
-<P><FONT CLASS="text">
- Nyílván ez volt a miénk is. Miután az - egyébként szórakoztató -
- BSD elõadásnak vége lett, A'rpi csatlakoztatta a notebookját a projectorhoz -
- lévén hozott egy OpenOffice-ban írt prezentációt is. Ponstchonak is volt
- egy beszéde betervezve úgyhogy a GUI is ki lett próbálva (igen, ez
- szenvedõ szerkezet, de nem érdekel).. Még jó, mert a seekbarban épp volt
- egy bug amitõl ugrált :) Próbáltak egy kicsit debuggolni, de az egyetlen
- amit elértek az az volt, hogy késett az elõadás. :)
- A'rpi és Ponstcho beszéde (a prezentáció képeivel együtt) külön letölthetõ
- az MPlayer honlapról magyar és angol nyelven.
-</FONT></P>
-
-<P><FONT CLASS="text">
- A többi elõadás nem volt túlzottan érdekes ahhoz hogy írjak ide róluk,
- úgyhogy egy szomorú(?) búcsú után felszálltunk a vonatra.
- Szerencsére velünk utazott Herman Tamás, neki, és a Squeak nevû
- "OS"-ének köszönhetõen végigröhögtük az utat. Nem is beszélve a
- furulyájáról ;)))
-</FONT></P>
+
+<!-- content begin -->
+
+<!-- synced with 1.3 -->
+
+<h1>
+ Leírás: Az MPlayer csapat a IV. GNU/Linux konferencián Magyarországon
+ <br><span class="poster">Írta: Gabucino</span>
+</h1>
+
+<h2>A konferenciáról</h2>
+
+<p>
+Csak annyit tudok róla hogy a honosítás volt a fõ témája :D
+Azt kérdezed hogyan kerültünk akkor mi mégis oda? Nos, a szponzorunk, az
+UHU-Linux (akik mellesleg a rendezvény egyik fõ szerverzõi voltak)
+szerette volna ha szerény személyeink is jelen lennének. Ígyhát azt mondtuk,
+<i>"miért is ne, úgyis csak ritkán találkozunk"</i>, és elkezdtünk
+készülõdni. Hamarosan megegyeztünk hogy az összes fõbb magyar fejlesztõ
+eljön: Árpi, Pontscho, al3x, és én: Gabucino.
+</p>
+
+<p>
+Sajnos végül nem csináltuk meg az RTFM pólókat (amikoris mindegyikünk
+viselne egy-egy betût, lehetne hullámozni, stb:). Talán majd legközelebb.
+</p>
+
+<h2>Az utazás</h2>
+
+<p>
+A rendezvény Budapesten volt megtartva, valamilyen hosszú nevû Grand
+Hotelben. al3x és én Szegedrõl vonattal utaztunk, a többiek már Pesten
+várakoztak. A vonat persze tele volt szegedi Linuxosokkal. Amikor
+elterjedt a hír hogy a vonaton tartózkodik két MPlayer fejlesztõ, azonnal
+egy külön luxuskocsiba szállítottak minket, aholis néhány szõke
+hosszúcombú... Khm, tehát akkor vissza a valóságba. :DD Pestre megérkeztünk,
+és a Blahán találkoztunk jól. Ez volt az eddigi legnagyobb találkozója
+MPlayer fejlesztõknek. Én már a Flag 2002-n találkoztam Árpival és
+Pontschoval, így ez volt al3x "beavatása" :)
+</p>
+
+<p>
+Eztán az összeállt csapat vidáman vonul keresztül a városon, világuralomról,
+MPlayer Operációs Rendszerrõl, és hasonló csacskaságokról beszélgetve.
+</p>
+
+<h2>A megérkezés</h2>
+
+<p>
+Megérkezve a hotelbe, gyorsan (2 hét) bejutottunk. Hé. Itt nincsenek
+nõk, húzzunk el! ... Najó. Ez meg valami megfigyelõrendszer a projectoron.
+Elsõ pillantásra feltünt hogy milyen rettenetes az swscaler-je, ígyhát
+nem lehet MPlayer. A monitor-ra vetve figyelmes szemünket rögtön
+feltûnt az ablakkezelõ kísérteties hasonlósága a Win98-cal. Szerencsére
+elkezdõdött az elsõ elõadás, így nem tudtunk meggyõzõdni az igazságról.
+</p>
+
+<h2>Késõbb: az UHU-Linux által támogatott project-ek bemutatása</h2>
+
+<p>
+Nyílván ez volt a miénk is. Miután az - egyébként szórakoztató -
+BSD elõadásnak vége lett, Árpi csatlakoztatta a notebookját a projectorhoz -
+lévén hozott egy OpenOffice-ban írt prezentációt is. Ponstchonak is volt
+egy beszéde betervezve úgyhogy a GUI is ki lett próbálva (igen, ez
+szenvedõ szerkezet, de nem érdekel).. Még jó, mert a seekbarban épp volt
+egy bug amitõl ugrált :) Próbáltak egy kicsit debuggolni, de az egyetlen
+amit elértek az az volt, hogy késett az elõadás. :)
+Árpi és Ponstcho beszéde (a prezentáció képeivel együtt) külön letölthetõ
+az MPlayer honlapról magyar és angol nyelven.
+</p>
+
+<p>
+A többi elõadás nem volt túlzottan érdekes ahhoz hogy írjak ide róluk,
+úgyhogy egy szomorú(?) búcsú után felszálltunk a vonatra.
+Szerencsére velünk utazott Herman Tamás, neki, és a <i>Squeak</i> nevû
+"OS"-ének köszönhetõen végigröhögtük az utat. Nem is beszélve a
+furulyájáról ;)))
+</p>
+
+<!-- content end -->
1
0
30 May '05
CVS change done by Mizda Gábor CVS
Update of /cvsroot/mplayer/homepage/essays/src
In directory mail:/var2/tmp/cvs-serv16110
Modified Files:
interview-Pontscho.src.hu
Log Message:
added missing sync tag
Index: interview-Pontscho.src.hu
===================================================================
RCS file: /cvsroot/mplayer/homepage/essays/src/interview-Pontscho.src.hu,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- interview-Pontscho.src.hu 30 May 2005 11:25:36 -0000 1.2
+++ interview-Pontscho.src.hu 30 May 2005 21:28:13 -0000 1.3
@@ -1,7 +1,7 @@
<!-- content start -->
-<!-- $Revision$ -->
+<!-- synced with 1.8 -->
<h1>Interjú Pontscho-val</h1>
1
0
CVS change done by Guillaume Poirier CVS
Update of /cvsroot/mplayer/main/DOCS/man/fr
In directory mail:/var2/tmp/cvs-serv14330/DOCS/man/fr
Modified Files:
mplayer.1
Log Message:
geometry support for gl2 under win, default window pos centered for gl, gl2
Index: mplayer.1
===================================================================
RCS file: /cvsroot/mplayer/main/DOCS/man/fr/mplayer.1,v
retrieving revision 1.266
retrieving revision 1.267
diff -u -r1.266 -r1.267
--- mplayer.1 24 May 2005 11:35:07 -0000 1.266
+++ mplayer.1 30 May 2005 11:49:41 -0000 1.267
@@ -2301,7 +2301,7 @@
.br
.I NOTE:
Cette option n'est permise que par les pilotes de sortie vidéo x11, xmga, xv,
-xvmc, xvidix, directx et tdfxfb.
+xvmc, xvidix, gl, gl2, directx et tdfxfb.
.sp 1
.I EXEMPLE:
.PD 0
1
0
30 May '05
CVS change done by Mizda Gábor CVS
Update of /cvsroot/mplayer/homepage/essays/src
In directory mail:/var2/tmp/cvs-serv29528
Modified Files:
interview-Pontscho.src.hu
Log Message:
synced with 1.8 (HTML fixes)
Index: interview-Pontscho.src.hu
===================================================================
RCS file: /cvsroot/mplayer/homepage/essays/src/interview-Pontscho.src.hu,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- interview-Pontscho.src.hu 31 Jan 2003 21:17:31 -0000 1.1
+++ interview-Pontscho.src.hu 30 May 2005 11:25:36 -0000 1.2
@@ -1,108 +1,266 @@
+
<!-- content start -->
-<P><font class="header">Ez az interjú egy módosítatlan másolata a <a href="http://www.hup.hu/english">Hungarian Unix portal-on [www.hup.hu]</A> 2002.03.04 dátummal megjelent interjúnak.</font></P>
-<P><font class="header">A másolás az interjú készítõjének <a href="http://debian.szintezis.hu">(trey)</A> tudtával és engedélyével történt.</font></P>
+<!-- $Revision$ -->
+
+<h1>Interjú Pontscho-val</h1>
+
+<p>
+Ez az interjú a
+<a href="http://www.hup.hu">Hungarian Unix Portal</a>-on
+2002. 03. 04. dátummal megjelent
+<a href="http://www.hup.hu/modules.php?name=News&file=article&sid=704">interjú</a>
+másolata, melyben csak gépelési javítások történtek.
+Az interjút a szerzõ, <a href="http://www.hup.hu/me.php">trey</a> tudtával és
+beleegyezésével közöljük itt.
+</p>
+
+<p>
+Pár hónappal ezelõtt <a href="http://portal.fsn.hu/article.php?sid=363">beszélgettem</a>
+Árpival az <a href="http://www.mplayerhq.hu">MPlayer</a> kitalálójával arról,
+hogy hogyan kezdett el foglalkozni az MPlayer-rel, mi késztette arra, hogy
+a legjobb Média Playert elkészítse. Most Pontscho-t (Ponekker Zoltánt, .so =)),
+az MPlayer grafikus felületének kitalálóját, készítõjét faggattam ki.
+</p>
+
+<p>
+Idõközben az MPlayer körül változások is történtek, ezekre a kérdésekre
+is kerestem a választ.
+</p>
+
+<dl>
+<dt>trey:</dt>
+<dd>Beszélnél egy kicsit magadról (iskola, programozói múlt, stb.)?</dd>
+
+<dt>Pontscho:</dt>
+<dd>Hm. 24 éves "vén marha" vagyok ;). Annak idején orvosi
+mechanikai mûszerész és karbantartóként végeztem. Az elsõ számítógépem
+egy Commodore VIC-20 volt. Két hétig, mert állítólag nem lehet
+billentyûzetrõl kinyírni egy ilyen gépet, hát nekem sikerült. Majd jött
+egy C64, majd a szokásos XT ..., és így tovább. Pár éve a fresh!mindworkz
+tagja vagyok, mint kóder.</dd>
+
+<dt>trey:</dt>
+<dd>Hogyan kezdtél el a Linuxszal foglalkozni? Mi az a dolog, ami miatt a
+Linuxszot választottad?</dd>
+
+<dt>Pontscho:</dt>
+<dd>Egy idõben imádtam buherálni. Ma már kezd unalmassá válni az állandó
+variálás, hogy akár egy ISDN modem driver mûködjön. Ma már a stabilitása
+tart meg a használatánál. (Bár újabban elég fura dolgokat tud mûvelni ...)
+Valamint az, hogy kereszt platformra tudok dolgozni alatta az esetek nagy
+részében.</dd>
+
+<dt>trey:</dt>
+<dd>Említetted, hogy egy kóder csapatban vagy tag. Ez még mindig az a régi
+idõk "ki tud 4K-ban jobb asm demot csinálni" dolog? Azt hittem a
+scene korszaknak vége.</dd>
+
+<dt>Pontscho:</dt>
+<dd>Nem :) Sokan mondják, hogy a scene halott, de nem. Amúgy az 4k intro
+kategória az amirõl te beszélsz ;)</dd>
+
+<dt>trey:</dt>
+<dd>A demok még mindig DOS alatt készülnek?</dd>
+
+<dt>Pontscho:</dt>
+<dd>Csak a mazohisták írják még mindig DOS alatt :) De inkább már senki.</dd>
+
+<dt>trey:</dt>
+<dd>Hallottam, hogy nem nagyon lehet ilyen demokat Linux alatt csinalni.
+Mi ennek a korlátja?</dd>
+
+<dt>Pontscho:</dt>
+<dd>Abszolút hülyeség. Minden adott egy jó demo megírásához. Bár tény, hogy
+a sok "kompatíbilis" window manager megnehezíti az ember dolgát.
+JPEG loadert annyit tölt le az ember, amennyit nem szégyell, hangrendszer is
+van egy-kettõ, HW gyorsított OpenGL dögivel. Csak nem túl elterjedt dolog a
+Linux desktop a scenen. Talán egy kezemen meg tudom számolni, hogy hány
+csapat adott ki Linux-os demot/introt. Igyekszünk ezen változtatni,
+elviekben az új Fresh3D engine-ben lesz Linux support.
+<br>
+Amúgy Arpi/Astral tagja, õk eleve Linux alatt írták a demoikat, és késõbb
+portolták win32-re.</dd>
+
+<dt>trey:</dt>
+<dd>Vannak olyan demok amiket ismerhetünk régebbrõl, és ami a nevedhez fûzõdik?</dd>
+
+<dt>Pontscho:</dt>
+<dd>Hm. Akad, de nem futnak Linux alól. FPC X kompatibilitása nevetséges,
+és a gcc-vel fordított objectek linkelhetõsége is kritikán aluli. Nem Linux
+alatt. Win32 alatt. Így elég nehéz keresztplatformra dolgozni vele. Win32
+alatt, amiben már én is részt vettem az az 54-es sorozat volt. (Konplex54,
+Synbolik54, Konputer54 (ebben csak az elõbbi az általam írt kód), 54 ).
+Meg volt pár éve egy party gyõztes 4k-m. (DosEmuban íródott :) Konplex54-et
+szeretném átírni majd Linux alá is, az a demo jön be nekem a legjobban az
+összes fresh cucc közül.</dd>
+
+<dt>trey:</dt>
+<dd>Mikor, és hogyan csatlakoztál az MPlayer fejlesztéséhez?</dd>
+
+<dt>Pontscho:</dt>
+<dd>Ha jól emlékszem 2000-ben, a Conference7007-en (egy partyn) említette
+Árpi elõször, hogy írt egy mpeg1 dekodert 5k-ban hardware gyorsítással.
+Kértem, hogy küldje el, majd jól "összevesztünk", hogy kiba***** lassú.
+Meg segfaultol, meg minden. Aztán rájöttem, hogy én voltam a hunyó, mer
+nem RTFM-eltem, és a gcc i686-ra optimalizált, és nekem k6-2-m van. A
+kettõ meg nem szereti egymást. Így hát megíródott a configure script elsõ
+változata...</dd>
+
+<dt>trey:</dt>
+<dd>Mi is a pontos szereped a az MPlayer projectben?</dd>
+
+<dt>Pontscho:</dt>
+<dd>Jó kérdés. Vannak szerepek ? :)</dd>
+
+<dt>trey:</dt>
+<dd>Milyen eszközökkel dolgozol munkád során? Gondolok itt a hardware, és
+szoftver eszközökre.</dd>
+
+<dt>Pontscho:</dt>
+<dd>Egy 450@500-as AMD K6-2-m van, már évek óta egy Matrox G400-al. Tuner
+kártya, Vortex2 Gus PnP (emlékszik még rá valaki, hogy mi az? :) 384 MB RAM,
+DVD, ilyesmi. Általában ezt használom, igen jól tép. Páldának okáért
+tetszõleges DVD filmet meg tudok nézni rajta. Apropó ... ha van valakinek
+megunt, felesleges DVD-je igazán elküldhetné, mert nekem nincs ilyenem, és
+eléggé stagnál így a GUI DVD supportja. :))) Szoftver? DosNavigator, Gimp,
+gcc, xnview :)</dd>
+
+<dt>trey:</dt>
+<dd>Használsz más operációs rendszert is a Linuxszon kívül? Vagy ez az egyetlen?</dd>
+
+<dt>Pontscho:</dt>
+<dd>Igen. Mivel tiszta Linux alatti programozásból mocskos nehéz megélni.</dd>
+
+<dt>trey:</dt>
+<dd>Mivel foglalkozol olyankor, amikor nem az MPlayert fejleszted?</dd>
+
+<dt>Pontscho:</dt>
+<dd>Más projectekbe dolgozom be. Vagy ha úgy hozza a véletlen, a fõiskolára
+is benézek. Ha az istenek is úgy akarják néhány hónap és diplomás honvéd
+leszek ;) Sajnos.</dd>
+
+<dt>trey:</dt>
+<dd>Árpi az interjúban említette, hogy te vagy a GUI hacker, és a CVS
+nagymestere. Ez mit is jelent pontosan?</dd>
+
+<dt>Pontscho:</dt>
+<dd>Én írom a grafikus felületet az MPlayerhez. Néhány apró változtatást
+kivéve az egészet én írtam. A "CVS nagymester" meg irónia. Egyszer Gabucino-val
+(akkor még fogalmam se volt arról, hogy mi az a CVS) alaposan elcsesztük a
+sourceforge-n a CVS-t :)</dd>
+
+<dt>trey:</dt>
+<dd>Árpi néhány hónappal ezelõtt <a href="http://portal.fsn.hu/article.php?sid=528">bejelentette</a>,
+hogy az MPlayerhez sokat hozzátenni már nem tud, kevesebb az ideje, ezért
+mostantól csak a patcheket fogadja, és a CVS-t kezeli. Hogyan érintette ez
+a project munkáját?</dd>
+
+<dt>Pontscho:</dt>
+<dd>Jó kérdés. Nem állja meg, hogy ne válaszoljon az userek hülyeségeire ;)</dd>
+
+<dt>trey:</dt>
+<dd>Sokak szerint lelassult az MPlayer fejlesztése. Ebben az évben egy
+release jelent meg (MPlayer 0.60 2002. január. 02). Úgy hallottam, hogy a
+CVS verzióval vannak gondok. Sokszor fordítási problémák vannak vele. A
+honlap se nagyon változik. Te hogy látod ezt?</dd>
+
+<dt>Pontscho:</dt>
+<dd>Gabu azt üzeni, hogy most fog commit-olni. Eddig sztrájkolt. Amúgy nem
+lassult le. Csak most nincsenek az user számára látványos változások. Például
+az sem látszik hogy codec interface Árpi által kezd újraíródni, illetve GUI
+kódja is 90%-ban újraíródott egy-két hete.</dd>
+
+<dt>trey:</dt>
+<dd>Úgy tudom, hogy az MPlayer bináris terjesztése (a sebesség problémák
+miatt) tiltott. Viszont hallani arról, hogy az MPlayer része lesz az UHU
+Linuxnak. Hogyan oldottátok meg azt, hogy az UHU-ba bele került? Forrásban
+terjesztitek?</dd>
+
+<dt>Pontscho:</dt>
+<dd>Nem. Mivel az UHU csapat nagyon sokat segített nekünk (szerver, hardver)
+így nagyjából már megoldódott a csomagba illeszthetõség. (Na, azért nem kell
+örülni, nem lesz .deb, .rpm, egyelõre). Mivel napi kapcsolatunk van velük
+így meg tudják oldani az UHU-ba való integrálást. (De ez kényes kérdés, sok
+vita volt emiatt)</dd>
+
+<dt>trey:</dt>
+<dd>Az UHU Linuxszal kapcsolatban... Árpi említette, hogy együtt dolgoztok
+egy közös munkán az UHU fejlesztõivel. Miért pont az UHU Linux?</dd>
+
+<dt>Pontscho:</dt>
+<dd>Mert szimpatikus a kezdeményezés. És akárki akármit mond, jó lesz a cucc.
+Keményen dolgoztak a fiúk, hogy használható legyen. És az is lett. Tény, hogy
+nem szerverre való. De desktopra tökéletes.</dd>
+
+<dt>trey:</dt>
+<dd>Tudom, hogy dolgozol egy titkos projecten =). Fõleg, hogy teszteltem is
+a dolgot. Tudnál errõl mondani valamit? Vagy ez meg mindig titok?</dd>
+
+<dt>Pontscho:</dt>
+<dd>:))))) Úgy tervezem, hogy rilizkor lesz nyilvános a cucc, fõleg, hogy
+némi fejlesztés még kell hozza. Na jó. Az MPlayerhez lesz installer. Elvileg
+képes lesz arra, hogy a net-rõl letöltött forrást lefordítsa, a szükséges
+fontokkal, skinekkel egyetemben. De idõhiány miatt ehhez sem tudtam az utóbbi
+idõben hozzányúlni.</dd>
+
+<dt>trey:</dt>
+<dd>Milyen irányban halad most az MPlayer fejlesztése? Dolgoztok új funkciókon,
+vagy csak a sebességbeli optimalizálás, kódtisztítás a jelenlegi cél?</dd>
+
+<dt>Pontscho:</dt>
+<dd>Kód tisztítás. Elég érdekes már néhol a forrás :)</dd>
+
+<dt>trey:</dt>
+<dd>Kerestek már meg benneteket hivatalosan más disztribúcióktól (SuSE,
+Red Hat, stb.), hogy szívesen látnák az MPlayert a saját terjesztésükben?</dd>
+
+<dt>Pontscho:</dt>
+<dd>A Red Hat csak fikázott, bár tény hogy a 2.96-os gcc (és egyéb
+hülyeségeik) miatt mi is alkottunk róluk véleményt ;). A SuSE-tól egy
+magyar fazon keresett meg minket, de akkor a csomag gyárthatóság még
+annyira sem volt lehetséges, mint ma (de inkább most sem ;). (Fúúú a
+Keresztapában most vetkõztette le a leendõ Keresztapa a feleségét :)</dd>
+
+<dt>trey:</dt>
+<dd>Hogyan érintette a project tagjait a Joe Barr féle
+<a href="http://portal.fsn.hu/article.php?sid=481">negatív kritika</A>?</dd>
+
+<dt>Pontscho:</dt>
+<dd>Engem nem érdekel. A többiek heves anyázásba kezdtek :) De az ilyen
+kritika általában le van s*****. Hobbi a cucc. Még mindig.</dd>
+
+<dt>trey:</dt>
+<dd>Volt egy kis <a href="http://portal.fsn.hu/article.php?sid=385">gáz</a>
+az OS2-be került MPlayer kóddal kapcsolatban. Az orosz arc "lenyúlta"
+a kódot szerintetek. Mi lett ebbõl az ügybõl? Sikerült megoldani?</dd>
+
+<dt>Pontscho:</dt>
+<dd>Huh, errõl nem sokat tudok. Nem érdekelt a dolog, volt aki leugassa
+helyettem õket ;)</dd>
+
+<dt>trey:</dt>
+<dd>Hogy látod a project jövõjét? Mik a távolabbi célok?</dd>
+
+<dt>Pontscho:</dt>
+<dd>Hm. Van jövõje szerintem. Ha csak Freshmeat.net "állását" tekintem.
+Célok? Jó kérdés. Részemrõl be szeretném fejezni GUI el nem készült
+feature-jait (playlist, etc.). Kiadni az Installer-t. Utána meg a fene tudja.
+Nem tervezem a továbbiakat. Majd kialakul.</dd>
+
+<dt>trey:</dt>
+<dd>Van még valami amit hozzá szeretnél tenni? Valamit ami nem szerepel a
+kérdések között?</dd>
+
+<dt>Pontscho:</dt>
+<dd>Igen. Mi a jelszavam portal.fsn.hu-n? :) És a fórumot mikor javítod meg? :)<br>
+Csak annyit, hogy szerintem igen jó szoftver lett az MPlayer. A dokumentáció
+is a legjobbak között van. Az átlag project dokumentációk között messze a
+legjobb. A kódból is rengeteget tanultam, amit más projectekben már alkalmaztam
+is. (Nem egy elsõ helyezett demonkban van belõle kód oldalról ötlet merítve)<br>
+Pontscho
+</dd>
+
+</dl>
-<font class="text"><br>Pár hónappal ezelõtt <a href="http://portal.fsn.hu/article.php?sid=363">beszélgettem</a> Árpival az <a href="http://www.mplayerhq.hu">MPlayer</a> kitalálójával arról, hogy hogyan kezdett el foglalkozni az MPlayer-rel, mi késztette arra, hogy a legjobb Média Playert elkészítse. Most Pontscho-t (Ponekker Zoltánt, .so =)), az MPlayer grafikus felületének kitalálóját, készítõjét faggattam ki.
-<br><br>
-Idõközben az MPlayer körül változások is történtek, ezekre a kérdésekre is kerestem a választ.<br />
-<br />
-<br />
-trey: Beszélnél egy kicsit magadról (iskola, programozói múlt, stb.)?<br />
-<br />
-Pontscho: Hm. 24 éves ``vén marha" vagyok ;). Annak idején orvosi mechanikai mûszerész és karbantartóként végeztem. Az elsõ számítógépem egy Commodore VIC-20 volt. Két hétig, mert állítólag nem lehet billentyûzetrõl kinyírni egy ilyen gépet, hát nekem sikerült. Majd jött egy C64, majd a szokásos XT ..., és így tovább. Pár éve a fresh!mindworkz tagja vagyok, mint kóder.<br><br>trey: Hogyan kezdtél el a Linuxszal foglalkozni? Mi az a dolog, ami miatt a Linuxszot választottad?<br />
-<br />
-Pontscho: Egy idõben imádtam buherálni. Ma már kezd unalmassá válni az állandó variálás, hogy akár egy ISDN modem driver mûködjön. Ma már a stabilitása tart meg a használatánál. (Bár újabban elég fura dolgokat tud mûvelni ...) Valamint az, hogy kereszt platformra tudok dolgozni alatta az esetek nagy részében.<br />
-<br />
-trey: Említetted, hogy egy kóder csapatban vagy tag. Ez még mindig az a régi idõk ``ki tud 4K-ban jobb asm demot csinálni" dolog? Azt hittem a scene korszaknak vége.<br />
-<br />
-Pontscho: Nem :) Sokan mondják, hogy a scene halott, de nem. Amúgy az 4k intro kategória az amirõl te beszélsz ;)<br />
-<br />
-trey: A demok még mindig DOS alatt készülnek?<br />
-<br />
-Pontscho: Csak a mazohisták írják még mindig DOS alatt :) De inkább már senki.<br />
-<br />
-trey: Hallottam, hogy nem nagyon lehet ilyen demokat Linux alatt csinalni. Mi ennek a korlátja?<br />
-<br />
-Pontscho: Abszolút hülyeség. Minden adott egy jó demo megírásához. Bár tény, hogy a sok ``kompatíbilis" window manager megnehezíti az ember dolgát. JPEG loadert annyit tölt le az ember, amennyit nem szégyell, hangrendszer is van egy-kettõ, HW gyorsított OpenGL dögivel. Csak nem túl elterjedt dolog a Linux desktop a scenen. Talán egy kezemen meg tudom számolni, hogy hány csapat adott ki Linux-os demot/introt. Igyekszünk ezen változtatni, elviekben az új Fresh3D engine-ben lesz Linux support.<br />
-<br />
-Amúgy Arpi/Astral tagja, õk eleve Linux alatt írták a demoikat, és késõbb portolták win32-re.<br />
-<br />
-trey: Vannak olyan demok amiket ismerhetünk régebbrõl, és ami a nevedhez fûzõdik?<br />
-<br />
-Pontscho: Hm. Akad, de nem futnak Linux alól. FPC X kompatibilitása nevetséges, és a gcc-vel fordított objectek linkelhetõsége is kritikán aluli. Nem Linux alatt. Win32 alatt. Így elég nehéz keresztplatformra dolgozni vele. Win32 alatt, amiben már én is részt vettem az az 54-es sorozat volt. (Konplex54, Synbolik54, Konputer54 (ebben csak az elõbbi az általam írt kód), 54 ). Meg volt pár éve egy party gyõztes 4k-m. (DosEmuban íródott :) Konplex54-et szeretném átírni majd Linux alá is, az a demo jön be nekem a legjobban az összes fresh cucc közül.<br />
-<br />
-trey: Mikor, és hogyan csatlakoztál az Mplayer fejlesztéséhez?<br />
-<br />
-Pontscho: Ha jól emlékszem 2000-ben, a Conference7007-en (egy partyn) említette Árpi elõször, hogy írt egy mpeg1 dekodert 5k-ban hardware gyorsítással. Kértem, hogy küldje el, majd jól "összevesztünk", hogy kiba***** lassú. Meg segfaultol, meg minden. Aztán rájöttem, hogy én voltam a hunyó, mer nem RTFM-eltem, és a gcc i686 - ra optimalizált, és nekem k6-2-m van. A kettõ meg nem szereti egymást. Így hát megíródott a configure script elsõ változata...<br />
-<br />
-trey: Mi is a pontos szereped a az Mplayer projectben?<br />
-<br />
-Pontscho: Jó kérdés. Vannak szerepek ? :)<br />
-<br />
-trey: Milyen eszközökkel dolgozol munkád során? Gondolok itt a hardware, és szoftver eszközökre.<br />
-<br />
-Pontscho: Egy 450@500-as AMD K6-2-m van, már évek óta egy Matrox G400-al. Tuner kártya, Vortex2 Gus PnP (emlékszik még rá valaki, hogy mi az? :) 384 MB RAM, DVD, ilyesmi. Általában ezt használom, igen jól tép. Páldának okáért tetszõleges DVD filmet meg tudok nézni rajta. Apropó ... ha van valakinek megunt, felesleges DVD-je igazán elküldhetné, mert nekem nincs ilyenem, és eléggé stagnál így a GUI DVD supportja. :))) Szoftver? DosNavigator, Gimp, gcc, xnview :)<br />
-<br />
-trey: Használsz más operációs rendszert is a Linuxszon kívül? Vagy ez az egyetlen?<br />
-<br />
-Pontscho: Igen. Mivel tiszta Linux alatti programozásból mocskos nehéz megélni.<br />
-<br />
-trey: Mivel foglalkozol olyankor, amikor nem az Mplayer-t fejleszted?<br />
-<br />
-Pontscho: Más projectekbe dolgozom be. Vagy ha úgy hozza a véletlen, a fõiskolára is benézek. Ha az istenek is úgy akarják néhány hónap és diplomás honvéd leszek ;) Sajnos.<br />
-<br />
-trey: Árpi az interjúban említette, hogy te vagy a GUI hacker, és a CVS nagymestere. Ez mit is jelent pontosan?<br />
-<br />
-Pontscho: Én írom a grafikus felületet az Mplayerhez. Néhány apró változtatást kivéve az egészet én írtam. A "CVS nagymester" meg irónia. Egyszer Gabucino-val (akkor még fogalmam se volt arról, hogy mi az a CVS) alaposan elcsesztük a sourceforge-n a CVS - t :)<br />
-<br />
-trey: Árpi néhány hónappal ezelõtt <a href="http://portal.fsn.hu/article.php?sid=528">bejelentette</a>, hogy az Mplayer-hez sokat<br />
-hozzátenni már nem tud, kevesebb az ideje, ezért mostantól csak a patcheket fogadja, és a CVS-t kezeli. Hogyan érintette ez a project munkáját?<br />
-<br />
-Pontscho: Jó kérdés. Nem állja meg, hogy ne válaszoljon az userek hülyeségeire ;)<br />
-<br />
-trey: Sokak szerint lelassult az MPlayer fejlesztése. Ebben az évben egy release jelent meg (MPlayer 0.60 2002. január. 02). Úgy hallottam, hogy a CVS verzióval vannak gondok. Sokszor fordítási problémák vannak vele. A honlap se nagyon változik. Te hogy látod ezt?<br />
-<br />
-Pontscho: Gabu azt üzeni, hogy most fog commit-olni. Eddig sztrájkolt. Amúgy nem lassult le. Csak most nincsenek az user számára látványos változások. Például az sem látszik hogy codec interface Árpi által kezd újraíródni, illetve GUI kódja is 90%-ban újraíródott egy-két hete.<br />
-<br />
-trey: Úgy tudom, hogy az MPlayer bináris terjesztése (a sebesség problémák miatt) tiltott. Viszont hallani arról, hogy az MPlayer része lesz az UHU Linuxnak. Hogyan oldottátok meg azt, hogy az UHU-ba bele került? Forrásban terjesztitek?<br />
-<br />
-Pontscho: Nem. Mivel az UHU csapat nagyon sokat segített nekünk (szerver, hardver) így nagyjából már megoldódott a csomagba illeszthetõség. (Na, azért nem kell örülni, nem lesz .deb, .rpm, egyelõre). Mivel napi kapcsolatunk van velük így meg tudják oldani az UHU-ba való integrálást. (De ez kényes kérdés, sok vita volt emiatt) <br />
-<br />
-trey: Az UHU Linuxszal kapcsolatban... Árpi említette, hogy együtt dolgoztok egy közös munkán az UHU fejlesztõivel. Miért pont az UHU Linux?<br />
-<br />
-Pontscho: Mert szimpatikus a kezdeményezés. És akárki akármit mond, jó lesz a cucc. Keményen dolgoztak a fiúk, hogy használható legyen. És az is lett. Tény, hogy nem szerverre való. De desktopra tökéletes.<br />
-<br />
-trey: Tudom, hogy dolgozol egy titkos projecten =). Fõleg, hogy teszteltem is a dolgot. Tudnál errõl mondani valamit? Vagy ez meg mindig titok?<br />
-<br />
-Pontscho: :))))) Úgy tervezem, hogy rilizkor lesz nyilvános a cucc, fõleg, hogy némi fejlesztés még kell hozza. Na jó. Az MPlayer-hez lesz installer. Elvileg képes lesz arra, hogy a net-rõl letöltött forrást lefordítsa, a szükséges fontokkal, skinekkel egyetemben. De idõhiány miatt ehhez sem tudtam az utóbbi idõben hozzányúlni.<br />
-<br />
-trey: Milyen irányban halad most az MPlayer fejlesztése? Dolgoztok új funkciókon, vagy csak a sebességbeli optimalizálás, kódtisztítás a jelenlegi cél?<br />
-<br />
-Pontscho: Kód tisztítás. Elég érdekes már néhol a forrás :)<br />
-<br />
-trey: Kerestek már meg benneteket hivatalosan más disztribúcióktól (SuSE, Red Hat, stb.), hogy szívesen látnák az Mplayer-t a saját terjesztésükben?<br />
-<br />
-Pontscho: A Red Hat csak fikázott, bár tény hogy a 2.96-os gcc (és egyéb hülyeségeik) miatt mi is alkottunk róluk véleményt ;). A SuSE-tól egy magyar fazon keresett meg minket, de akkor a csomag gyárthatóság még annyira sem volt lehetséges, mint ma (de inkább most sem ;). (Fúúú a Keresztapában most vetkõztette le a leendõ Keresztapa a feleségét :)<br />
-<br />
-trey: Hogyan érintette a project tagjait a Joe Barr féle <a href="http://portal.fsn.hu/article.php?sid=481">negatív kritika</A>?<br />
-<br />
-Pontscho: Engem nem érdekel. A többiek heves anyázásba kezdtek :) De az ilyen kritika általában le van s*****. Hobbi a cucc. Még mindig.<br />
-<br />
-trey: Volt egy kis <a href="http://portal.fsn.hu/article.php?sid=385">gáz</a> az OS2-be került MPlayer kóddal kapcsolatban. Az orosz arc "lenyúlta" a kódot szerintetek. Mi lett ebbõl az ügybõl? Sikerült megoldani?<br />
-<br />
-Pontscho: Huh, errõl nem sokat tudok. Nem érdekelt a dolog, volt aki leugassa helyettem õket ;)<br />
-<br />
-trey: Hogy látod a project jövõjét? Mik a távolabbi célok?<br />
-<br />
-Pontscho: Hm. Van jövõje szerintem. Ha csak Freshmeat.net "állását" tekintem. Célok? Jó kérdés. Részemrõl be szeretnem fejezni GUI el nem készült feature-jait (playlist, etc.). Kiadni az Installer-t. Utána meg a fene tudja. Nem tervezem a továbbiakat. Majd kialakul.<br />
-<br />
-trey: Van még valami amit hozzá szeretnél tenni? Valamit ami nem szerepel a kérdések között?<br />
-<br />
-Pontscho: Igen. Mi a jelszavam portal.fsn.hu-n ? :) És a fórumot mikor javítod meg ? :)<br />
-<br />
-Csak annyit, hogy szerintem igen jó szoftver lett az MPlayer. A dokumentáció is a legjobbak között van. Az átlag project dokumentációk között messze a legjobb. A kódból is rengeteget tanultam, amit más projectekben már alkalmaztam is. (Nem egy elsõ helyezett demonkban van belõle kód oldalról ötlet merítve)<br />
-<br />
-Pontscho<br><br>
-</font>
<!-- content end -->
1
0
30 May '05
CVS change done by Mizda Gábor CVS
Update of /cvsroot/mplayer/homepage/essays/src
In directory mail:/var2/tmp/cvs-serv19914
Modified Files:
interview-Arpi.src.hu
Log Message:
dumped sync tag
Index: interview-Arpi.src.hu
===================================================================
RCS file: /cvsroot/mplayer/homepage/essays/src/interview-Arpi.src.hu,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- interview-Arpi.src.hu 30 May 2005 09:20:55 -0000 1.3
+++ interview-Arpi.src.hu 30 May 2005 10:50:54 -0000 1.4
@@ -1,7 +1,7 @@
<!-- content start -->
-<!-- synced with 1.8 -->
+<!-- synced with 1.9 -->
<h1>Interjú Árpival</h1>
1
0