May 2005 - MPlayer-translations - lists.mplayerhq.hu

CVS: main/DOCS/man/de mplayer.1,1.152,1.153
by syncmail＠mplayerhq.hu 31 May '05

31 May '05

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: main/DOCS/man/de mplayer.1,1.158,1.159
by syncmail＠mplayerhq.hu 31 May '05

31 May '05

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: main/DOCS/man/de mplayer.1,1.157,1.158
by syncmail＠mplayerhq.hu 31 May '05

31 May '05

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

CVS: homepage/essays/src konf2002-Pontscho.src.hu, 1.2, 1.3
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-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 @@ +  - - Ponekker Zoltán - + + +<h1>Ponekker Zoltán</h1> - - É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. - +É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. - - 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. - +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.

1 0

CVS: homepage/essays/src konf2002-arpi.src.hu, NONE, 1.1
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-serv22107 Added Files: konf2002-arpi.src.hu Log Message: synced with 1.1, new file from HTML --- NEW FILE ---   <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"> É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. 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. 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. 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. 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. <div class="center"> <img src="../essays/images/konf2002-stats.png" alt="Fejlesztés"> </div> 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. <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>MPlayer</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> 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. 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. 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. <div class="right-box"> <h3>Linuxos videó lejátszók 2 éve</h3> Avifile, DVDview, Gstreamer, Kmpg, LAMP, LiViD/OMS, MPlayer, mpeg2dec, MpegTV, Ogle, SMpeg, VideoLan, XMMP, XMPS, XMovie, Xanim, xine, Xtheater, ZZplayer </div> 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. <div class="left-box"> <h3>SourceForge.net'2001</h3> <ul> <li>megbízhatatlan a CVS</li> <li>lassúlnak a levlisták *</li> <li>nincs Reply-To:</li> <li>nincs levlista archívum *</li> <li>megszünik az FTP</li> <li>egyre több reklám, banner</li> </ul> (* 2002-ben megoldva) </div> 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. 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. 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. <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> 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. 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ó. 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. <div class="left-box"> <h3>Mi a végcél???</h3> <ul> <li>"Világuralom? :)" - Gabucino</li> <li>v1.0?</li> <li>egy felhasználóbarát lejátszó?</li> <li>mplayer desktop environment?</li> <li>...</li> </ul> </div> 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. 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. <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> 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. 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. <div class="left-box"> <h3>Kooperáció</h3> <ul> <li>Avifile: .DLL loader / win32 emu</li> <li>VideoLAN: DVD/DeCSS</li> <li>xine: SVQ1 codec</li> <li>FFmpeg: libavcodec</li> <li>OMS: libmpeg2, libac3</li> <li>Mpeg2dec: libvo</li> <li>...</li> </ul> </div> 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é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. 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. 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. <div class="left-box"> <h3>A lejátszó idõzít, nem az OS ütemezõje!</h3> <ul> <li style="display:block">+ a lejátszó tudja, mikor mire van szüksége</li> <li style="display:block">+ nincs lock-olás, mutex-ek</li> <li style="display:block">+ nincs lassú thread- vagy task-switching</li> <li style="display:block">+ tisztább, átláthatóbb a kód -> kevesebb bug</li> <li style="display:block">+ egyszerübb a debug</li> <li style="display:block">- nincs SMP kihasználás</li> </ul> </div> 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. 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. 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. 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. 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. <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> 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. 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. Az utóbbi idõben elterjedt a windows média audio/video, korábbi nevén az ASF formátum. 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á. RealAudio, RealVideo: 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á. A Quicktime 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. Vivo 1, 2 - 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. A Sony digital video, 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. 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. <div class="right-box"> <h3>Támogatott video output eszközök</h3> <ul> <li>X11: Shm, Xvideo, GLX/OpenGL, DGA 1/2</li> <li>Linux: framebuffer, svgalib, VESA, mga_vid</li> <li>Wrappers: SDL, GGI, DirectFB, VidiX, AAlib</li> <li>HW decoders: dxr2, H+/dxr3, dvb, zoran</li> <li>Images: gif89, png, jpeg, pgm, yuv4mpeg</li> </ul> </div> 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. 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. <div class="left-box"> <h3>Közvetlenül támogatott VGA kártyák</h3> <ul> <li>mga_vid: Matrox G200, G400, G450, G550</li> <li>vidix: ATI mach64, Rage 128, Radeon</li> <li>tdfxfb: 3Dfx Voodoo 3/Banshee</li> </ul> </div> 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. 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. 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. <div class="right-box"> <table border="0" cellpadding="2"> <tr> <td colspan="4">MPlayer "stabil" verziók</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> 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. 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. <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> 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. 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. <h3>Kérdések - válaszok</h3> K: 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? V: 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. 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. 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. Q: 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. A: 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.

1 0

[MPlayer-translations] CVS: homepage/essays/src konf2002.src.hu, 1.2, 1.3
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 @@ - - Az MPlayer csapat a IV. GNU/Linux konferencián - írta: Gabucino - - - - A konferenciáról - - - - 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, - "miért is ne, úgyis csak ritkán találkozunk", é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. - - - - 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. - - - - Az utazás - - - - 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" :) - - - - 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. - - - - A megérkezés - - - - 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. - - - - Késõbb: az UHU-Linux által támogatott project-ek bemutatása - - - - 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. - - - - 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 ;))) - + + + + + +<h1> + Leírás: Az MPlayer csapat a IV. GNU/Linux konferencián Magyarországon + Írta: Gabucino +</h1> + +<h2>A konferenciáról</h2> + + +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, +"miért is ne, úgyis csak ritkán találkozunk", é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. + + + +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. + + +<h2>Az utazás</h2> + + +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" :) + + + +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. + + +<h2>A megérkezés</h2> + + +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. + + +<h2>Késõbb: az UHU-Linux által támogatott project-ek bemutatása</h2> + + +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. + + + +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 ;))) + + +

1 0

CVS: homepage/essays/src interview-Pontscho.src.hu, 1.2, 1.3
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-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 @@  - + <h1>Interjú Pontscho-val</h1>

1 0

CVS: main/DOCS/man/fr mplayer.1,1.266,1.267
by syncmail＠mplayerhq.hu 30 May '05

30 May '05

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

CVS: homepage/essays/src interview-Pontscho.src.hu, 1.1, 1.2
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-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 @@ +  -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. -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. + + +<h1>Interjú Pontscho-val</h1> + + +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á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. + + + +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. + + +<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. + +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? :) +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) +Pontscho +</dd> + +</dl> - 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. - -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. - - -trey: Beszélnél egy kicsit magadról (iskola, programozói múlt, stb.)? - -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. trey: Hogyan kezdtél el a Linuxszal foglalkozni? Mi az a dolog, ami miatt a Linuxszot választottad? - -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. - -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. - -Pontscho: Nem :) Sokan mondják, hogy a scene halott, de nem. Amúgy az 4k intro kategória az amirõl te beszélsz ;) - -trey: A demok még mindig DOS alatt készülnek? - -Pontscho: Csak a mazohisták írják még mindig DOS alatt :) De inkább már senki. - -trey: Hallottam, hogy nem nagyon lehet ilyen demokat Linux alatt csinalni. Mi ennek a korlátja? - -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. - -Amúgy Arpi/Astral tagja, õk eleve Linux alatt írták a demoikat, és késõbb portolták win32-re. - -trey: Vannak olyan demok amiket ismerhetünk régebbrõl, és ami a nevedhez fûzõdik? - -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. - -trey: Mikor, és hogyan csatlakoztál az Mplayer fejlesztéséhez? - -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... - -trey: Mi is a pontos szereped a az Mplayer projectben? - -Pontscho: Jó kérdés. Vannak szerepek ? :) - -trey: Milyen eszközökkel dolgozol munkád során? Gondolok itt a hardware, és szoftver eszközökre. - -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 :) - -trey: Használsz más operációs rendszert is a Linuxszon kívül? Vagy ez az egyetlen? - -Pontscho: Igen. Mivel tiszta Linux alatti programozásból mocskos nehéz megélni. - -trey: Mivel foglalkozol olyankor, amikor nem az Mplayer-t fejleszted? - -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. - -trey: Árpi az interjúban említette, hogy te vagy a GUI hacker, és a CVS nagymestere. Ez mit is jelent pontosan? - -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 :) - -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 -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? - -Pontscho: Jó kérdés. Nem állja meg, hogy ne válaszoljon az userek hülyeségeire ;) - -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? - -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. - -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? - -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) - -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? - -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. - -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? - -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. - -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? - -Pontscho: Kód tisztítás. Elég érdekes már néhol a forrás :) - -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? - -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 :) - -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>? - -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. - -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? - -Pontscho: Huh, errõl nem sokat tudok. Nem érdekelt a dolog, volt aki leugassa helyettem õket ;) - -trey: Hogy látod a project jövõjét? Mik a távolabbi célok? - -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. - -trey: Van még valami amit hozzá szeretnél tenni? Valamit ami nem szerepel a kérdések között? - -Pontscho: Igen. Mi a jelszavam portal.fsn.hu-n ? :) És a fórumot mikor javítod meg ? :) - -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) - -Pontscho -

1 0

CVS: homepage/essays/src interview-Arpi.src.hu, 1.3, 1.4
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-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 @@  - + <h1>Interjú Árpival</h1>

1 0