Bei der Gruppe, für die Sie eine Mitteilung verfassen, handelt es sich um eine Usenet-Gruppe. Wenn Sie in dieser Gruppe Nachrichten posten, ist Ihre E-Mail-Adresse für jeden im Internet sichtbar
weil inzwischen echt viel Zeit verronnen ist, und weil ich (zumindest CCC-intern) gesagt hatte, daß ich mich dieses Jahr darum kümmern werde, daß die Videos in anständig komprimiert im Netz landen werde, möchte ich mal ein Update posten.
Zuerst einmal: die Videos existieren. Seit ungefähr einer Woche habe ich sie jetzt in Form einer IDE-Platte in der Hand, die komische Geräusche macht. Ich habe also erst mal ein Backup gezogen davon. Die Daten sind alle da.
Der Batch-Komprimier-Job wäre auch schon durchgelaufen, aber ich habe ihn nach der Hälfte abgebrochen, weil sich herausstellte, daß vor und nach den Vorträgen teilweise bis zu einer Stunde Pause ist, wo man sieht, wie Leute sich in Saal 1 mit ihren Notebooks hinsetzen, und so weiter. Desweiteren gibt es Sync-Probleme, die allerdings nicht so schlimm sind, daß sie verhindern würden, daß man sich das anguckt und was lernt.
Nerviger ist, daß in Saal 1 eine Brummschleife auf dem Audiotrack ist. Nicht nur 50 Hz, sondern auch die Obertöne davon. Ich habe eine Toolchain gebaut, mit der ich das raus filtern konnte, allerdings klingt es danach nicht merklich besser, weil wir die Tonspuren nur in komprimierter Form vorliegen haben. Audiokompression funktioniert so, daß der Encoder guckt, welche Bereiche das Ohr nicht wahrnimmt (z.B. weil daneben ein lauter, prägnanter anderer Ton ist, wie ein lautes 50 Hz Brummen), und dann dort weniger Bits ausgibt, was sich als Quantisierungrauschen niederschlägt. Wenn ich jetzt das Brummen rausfiltere, klingt der Ton wie aus dem Klo, wie ein schlecht komprimiertes mp3, ihr wißt schon, 96 kbit stereo (nicht joint stereo) mit bladeenc, dieses Qualitätsniveau.
Kurz gesagt: das Brummen bleibt da drin.
Ich habe hier zwar eine Liste mit Veranstaltungen und Schnittpunkten, aber die sind sehr ungenau und daher habe ich sie weitgehend verworfen und mache das jetzt neu. Für das nächste Jahr lernen wir daraus, daß nicht die Engel am Platz Schnittpunkte setzen sollen, sondern einfach pro Tag ein MPEG rausfallen soll. Dann passiert auch nicht, was hier ein paar Mal passiert ist, nämlich daß eine Sendung über mehrere Dateien verteilt ist, die ich dann wieder manuell zusammen fummeln muß.
Ich habe jetzt die Veranstaltungen in Saal 1 und 2 encoded, Saal 3 und 4 kommen noch. Wenn es gut läuft, ist das am Sonntag fertig.
Ich komprimiere Video mit H.264 (fixed quantizer) und Audio mit AAC. Die durchschnittliche Datenrate für H.264 ist bei unter 100 kbit, für Audio um die 64 kbit. Die Auflösung ist 496x368, und das Bild sieht (für mein Dafürhalten) exzellent aus. Als Containerformat nehme ich AVI.
Hier sind die Gründe, wieso ich das so mache:
1. AVI kann man auf jeder Plattform prinzipiell abspielen 2. H.264 ist State of the Art und es existiert ein freier Decoder als Teil von ffmpeg 3. AAC ist State of the Art und existiert ein freier Decoder in Form von FAAD2 4. Die Datenrate ist klein genug, daß alles zusammen gerade so auf eine DVD passen könnte. Das ist dann natürlich eine _Daten_-DVD, keine Video-DVD, die man in seinen Player stecken kann.
Man kann die Videos unter Linux mit einem aktuellen mplayer abspielen, wenn man da AAC-Dekodierung drinnen hat.
Unter dem Windoze Media Player habe ich bisher Video am Start, Audio funktioniert irgendwie nicht. Es gibt ein mplayer für Windoze, aber der kann (zumindest das offizielle Binary) kein AAC.
Quicktime (auch Quicktime 7) soll dem Vernehmen nach crashen beim Abspielen der Videos, obwohl die AVI und H.264 und AAC können sollten.
Wer sich also gerade langweilt, der kann die Zeit prima damit überbrücken, auf seiner Plattform überhaupt erst mal eine Player-Software an den Start zu bringen, die das abspielen kann. :-)
Der eine oder andere wird sich jetzt vielleicht fragen, wenn ich schon so viel fertig habe, wieso ich das noch nicht auf ftp.ccc.de getan habe. Der Hintergrund ist der, daß das auf Freundschaft basierende Mirrorbetreiber sind, die wir nicht vor den Kopf schlagen wollen, indem wir da mal eben ein paar Gigabyte hin uploaden. Daher hier der Aufruf: wer nen Server mit "Traffic spielt keine Rolle" hat, der möge sich bitte bei mir melden.
Felix
PS: Wenn wir in Europa Software-Patente kriegen, gibt es nächstes Jahr keine Kongressvideos mehr. Helft also mit, Softwarepatente zu verhindern!!
Felix von Leitner <usenet-20050...@fefe.de> wrote:
>Für das nächste Jahr lernen wir daraus, daß >nicht die Engel am Platz Schnittpunkte setzen sollen, sondern einfach >pro Tag ein MPEG rausfallen soll.
Mein Vorschlag wär als Fallback direkt auf Tape aufzeichnen und nicht ausschließlich mit Rechnern. Streaming ist immernoch möglich, aber wenn was schief geht gibt's zumindest keine Syncprobleme.
Zum Thema Schnittpunkte (aus eigener Erfahrung), das funktioniert nur gut wenn derjenige der die Schnittpunkte gesetzt hat auch selbst schneidet und etwas Übung hat.
Thus spake Felix von Leitner (usenet-20050...@fefe.de):
> Wer sich also gerade langweilt, der kann die Zeit prima damit > überbrücken, auf seiner Plattform überhaupt erst mal eine > Player-Software an den Start zu bringen, die das abspielen kann. :-)
Daran könnt ihr mal eure Software tunen. :-) Wenn ihr das mit Bild und Ton abspielen könnt, könnt ihr auch die anderen Videos gucken, sobald sie fertig sind.
*yeaah* besten dank fuer die ganze Arbeit, ich hoffe schon lange drauf mal alle Videos in brauchbarer Qualitaet und einem Abspielbaren format zu haben.
Ich werde dir einen tempel erreichten wenn die Daten da sind.
Es gibt da auch noch eine Dauerbaustelle, nämlich den "Datenschleuder - Server." Es ist verdammt schade, das ein exellent gutes Medium, das ja nun die Datenschleuder einmal darstellt, durch den äusserst schlechten Service im Internet diskreditiert wird. Wann kann man auch ohne Hack, also auf offiziellem Wege, die "Datenschleuder" im Netz bewundern?
Also mit mplayer 1.0pre7-3.4.3 unter Fedora Core 3 keine Probleme. Gutes Bild und guter Ton. Ich musste nur in der codecs.conf
audiocodec faad info "FAAD AAC (MPEG2/MPEG4 Audio) decoder" status working fourcc mp4a,MP4A fourcc "AAC " ; Used in NSV format 0xff driver faad
ändern in audiocodec faad info "FAAD AAC (MPEG2/MPEG4 Audio) decoder" status working fourcc mp4a,MP4A fourcc "AAC " ; Used in NSV format 0xff format 0x706D driver faad dll libfaad
»Felix von Leitner« <usenet-20050...@fefe.de> wrote:
> 2. H.264 ist State of the Art und es existiert ein freier Decoder als > Teil von ffmpeg
Der leider ständig abstürzt...
Womit erzeugst du die H.264-Files eigentlich? x264 oder Kommerzkram, wenn ja, welcher und gibt's eine Demoversion?
> Man kann die Videos unter Linux mit einem aktuellen mplayer abspielen, > wenn man da AAC-Dekodierung drinnen hat.
Wenn du das sagst, wird das wohl stimmen, weil du es ausprobiert hast. Das heißt also, dass *DU* die Dateien so mit H.264 komprimierst, dass ffmpeg dabei NICHT ständig segfaultet. Hast du schon vor- und zurückspulen mit den Pfeiltasten im mplayer probiert?
Ich jedenfalls habe schon ein paar MKVs mit H.264-kodiertem Videostream gesehen, die mplayer beim Abspielen, manchmal erst beim Seeken, und manchmal "nur" beim Framedroppen (das lässt sich durch schnelles Drücken der Leertaste oder viel CPU-Last gut reproduzieren - oder Fullscreendarstellung mit -framedrop -vo x11 -zoom) zersäbeln.
-- <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"><html><title
</style><div class=f>Der vorhergehende Satz ist kopiergeschützt.</div> <hr>Best viewed with Mozilla Firefox 0.8 at 320x240 on FreeBSD 4.10.</html>
»Rudolf Polzer« <divver...@caths.co.uk> wrote: > »Felix von Leitner« <usenet-20050...@fefe.de> wrote: > > 2. H.264 ist State of the Art und es existiert ein freier Decoder als > > Teil von ffmpeg
> Der leider ständig abstürzt...
[...]
OK, Test mit aktuellem mplayer 1.0pre7: kein Ton, Lösung wie beschrieben funktioniert aber.
CVS-Snapshot von heute: läuft perfekt, Ton geht auch, doch er verabschiedet sich etwas unschön:
Assertion failed: (pic->data[0]), function mc_dir_part, file h264.c, line 2313.
MPlayer interrupted by signal 6 in module: decode_video - MPlayer crashed. This shouldn't happen. It can be a bug in the MPlayer code _or_ in your drivers _or_ in your gcc version. If you think it's MPlayer's fault, please read DOCS/HTML/en/bugreports.html and follow the instructions there. We can't and won't help unless you provide this information when reporting a possible bug.
Das dürte sich sehr störend auswirken, wenn man es re-encoden will. Aber da mplayer das ja abspielt...
Es wäre daher gut, die Videos in einem Alternativformat anzubieten. Das kann durchaus auch ein schlechter aussehendes MPEG-4 mit niedrigerer Auflösung und kleinerer Datenrate sein.
Kann ich den Link zur Keynote.avi den MPlayer-Entwicklern schicken?
Ach ja, und es gab noch ein größeres Abspielproblem als der H.264-Kram: der Vortrag wirkt sehr monoton und abgelesen ;) wie wäre es, wenn du da noch so ein schönes 50 Hz-Brummen drüberlegst, um ein wenig Spannung zu suggerieren? Leute, die vor der Kamera hin und herlaufen und ab und zu mal gegen das Stativ stoßen wären auch nicht schlecht... sagen wir es so: das Video ist so gut kodiert, dass man vom Vortragenden mehr erwartet.
-- <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"><html><title
</style><div class=f>Der vorhergehende Satz ist kopiergeschützt.</div> <hr>Best viewed with Mozilla Firefox 0.8 at 320x240 on FreeBSD 4.10.</html>
> Also mit mplayer 1.0pre7-3.4.3 unter Fedora Core 3 keine Probleme. Gutes > Bild und guter Ton. Ich musste nur in der codecs.conf > audiocodec faad > info "FAAD AAC (MPEG2/MPEG4 Audio) decoder" > status working > fourcc mp4a,MP4A > fourcc "AAC " ; Used in NSV > format 0xff > driver faad > ändern in > audiocodec faad > info "FAAD AAC (MPEG2/MPEG4 Audio) decoder" > status working > fourcc mp4a,MP4A > fourcc "AAC " ; Used in NSV > format 0xff > format 0x706D > driver faad > dll libfaad
Mhh, das ist zumindest im mplayer-cvs bereits gefixt in codecs.conf. (also das 0x706d).
> Exzellent ist sicherlich was anderes, sind doch mitunter recht deutliche > Makroblöcke zu erkennen.
Na klar sind da Makroblöcke. Aber im Hintergrund, nicht über dem Gesicht des Vortragenden.
Im Übrigen ist das ja systemisch heute. Wer MPEG kennt, sieht auch im Fernsehen ständig überall Makroblöcke.
> Aber die Qualität ist nach meinem Dafürhalten mehr > als ausreichend und in der Summe auch als "gut" zu bezeichnen, und > anbetrachts der Datenrate beeindruckend. Ich wünsche mir, das man derart > zeitgemäße Kompression an anderen Stellen einführt (DVB-T drängt sich direkt > auf, hier in NRW werden 4 Programme in MPEG2 in 12.75 MBit gepresst, die > Bildqualität ist entsprechend mittelmäßig bis schlecht. Mit H264 könnte man > dann wohl locker 30 Programme in guter Qualität pro Frequenz senden).
ACK. Ich gucke hier gerade per DVB-T ein Coldplay-Konzert auf 3sat, das geht noch. Aber Tierfilme sind per DVB-T regelmäßig eine Katastrophe.
> > Der Hintergrund ist der, daß das auf Freundschaft basierende > > Mirrorbetreiber sind, die wir nicht vor den Kopf schlagen wollen, indem > > wir da mal eben ein paar Gigabyte hin uploaden. > FTP ist für sowas einfach nicht mehr zeitgemäß. Bittorrent skaliert und > sorgt dafür, daß der Traffic für den einzelnen sehr überschaubar bleibt.
Wie wir das dann unter die Leute bringen, finde ich persönlich ziemlich wurscht. Ich brauche auch bei Torrent Leute mit 10 GB Plattenplatz und anständiger Netzanbindung. Wenn ich einfach nur nen Torrent über meine DSL-Leitung ins Netz stelle, und darauf hoffe, daß sich das schon irgendwie regelt, dann muß ich meiner Erfahrung nach mindestens 1.8* die eigentlichen Nutzdaten rausgeben, bis alle zufrieden sind. Bei 10 Gigabyte Daten über 128 kbps kannst du dir ja ausrechnen, wie viel Spaß das machen wird.
> > 2. H.264 ist State of the Art und es existiert ein freier Decoder als > > Teil von ffmpeg > Der leider ständig abstürzt...
Bei mir nicht. Ich encode seit ein paar Wochen meine gesammelten Fernsehmitschnitte damit und konnte das bisher alles streßarm wiedergeben.
Aber man braucht eine aktuelle Version von ffmpeg, das ist richtig.
> Womit erzeugst du die H.264-Files eigentlich? x264 oder Kommerzkram, > wenn ja, welcher und gibt's eine Demoversion?
Mit mencoder-cvs vom 29.4.2005 mit FAAC (dem CVS-Snapshot von deren Server, ist vom letzten Jahr irgendwann) und x264 (svn von Ende April).
> Wenn du das sagst, wird das wohl stimmen, weil du es ausprobiert hast. > Das heißt also, dass *DU* die Dateien so mit H.264 komprimierst, dass > ffmpeg dabei NICHT ständig segfaultet. Hast du schon vor- und > zurückspulen mit den Pfeiltasten im mplayer probiert?
Ja, natürlich. Keine Frage, das ist alles bleeding edge und da wird der eine oder andere noch ein bißchen Ärger mit haben, aber wir reden hier von <10 Gig H.264/AAC im Vergleich zu 17 Gig MPEG-4/MP3. Für eine Halbierung der Lager- und Downloadzeit finde ich es gerechtfertigt, daß man sich mal die Playersoftware auf den aktuellen Stand bringen muß.
> Ich jedenfalls habe schon ein paar MKVs mit H.264-kodiertem Videostream > gesehen, die mplayer beim Abspielen, manchmal erst beim Seeken, und > manchmal "nur" beim Framedroppen (das lässt sich durch schnelles Drücken > der Leertaste oder viel CPU-Last gut reproduzieren - oder > Fullscreendarstellung mit -framedrop -vo x11 -zoom) zersäbeln.
Daher hab ich auch AVI genommen :-)
OGG habe ich noch überlegt. MKV traue ich nicht über den Weg. "Binary XML", wie krank ist das denn bitte?!
> Es wäre daher gut, die Videos in einem Alternativformat anzubieten. Das > kann durchaus auch ein schlechter aussehendes MPEG-4 mit niedrigerer > Auflösung und kleinerer Datenrate sein.
Spätestens beim nächsten Kongress wird das auch als MP4 irgendwo rumliegen. Aber ins Netz stellen werde ich das zumindest nicht.
> Kann ich den Link zur Keynote.avi den MPlayer-Entwicklern schicken?
Na klar, gerne!
> Ach ja, und es gab noch ein größeres Abspielproblem als der H.264-Kram: > der Vortrag wirkt sehr monoton und abgelesen ;) wie wäre es, wenn du da > noch so ein schönes 50 Hz-Brummen drüberlegst, um ein wenig Spannung zu > suggerieren? Leute, die vor der Kamera hin und herlaufen und ab und zu > mal gegen das Stativ stoßen wären auch nicht schlecht... sagen wir es > so: das Video ist so gut kodiert, dass man vom Vortragenden mehr > erwartet.
Das liegt am Vortragenden -- der Mann sitzt im Rollstuhl, und er hat tatsächlich von Notizen abgelesen. Andere Vorlesende sind da lebhafter, und insbesondere in Saal 3 laufen auch mal Leute durchs Bild, da geht dann auch die Datenrate hoch.
> > Man kann die Videos unter Linux mit einem aktuellen mplayer abspielen, > > wenn man da AAC-Dekodierung drinnen hat. > Ich habe hier eine deutlichen Versatz zwischen Bild und Ton. Ist das nun ein > Problem des Codecs oder ist das File kaputt?
Das ist leider ein Problem der Aufnahme, weil ffmpeg (womit das aufgenommen wurde) da beim Multiplexing gepfuscht hat. Leider ist der Versatz nicht uniform (nicht mal pro Vortrag), sonst hätte ich das repariert. :-(
Michael Holzt wrote: > Ich wünsche mir, das man derart > zeitgemäße Kompression an anderen Stellen einführt (DVB-T drängt sich direkt > auf, hier in NRW werden 4 Programme in MPEG2 in 12.75 MBit gepresst, die > Bildqualität ist entsprechend mittelmäßig bis schlecht. Mit H264 könnte man > dann wohl locker 30 Programme in guter Qualität pro Frequenz senden).
Ach mach dir keine Sorgen, wenn sich erst jeder mal so eine DVB-T Decoder-Schachtel gekauft hat, danach kommt das bestimmt...
Michael Holzt wrote: >> mplayer: relocation error: mplayer: undefined symbol: faacDecOpen >> Debian/unstable mit mplayer, libfaad usw. von Christian Marillat.
> Kann ich nicht nachvollziehen. mplayer von marillat, version 1:1.0-pre6-0.4, > libfaac0 1.24-0.3, libfaad2-0 2.0.0-0.5. Funktioniert.
Hier auch 1.0-pre6-0.4, libfaad 2.0-r3 und libfaac 1.24 (alles aus dem gentoo portage) und trotzdem hängt sich mplayer gleich nach dem starten mit "h264.c:2023: hl_motion: Assertion `((mb_type)&(0x0008|0x0010|0x0020|0x0040))' failed." auf.
> wurscht. Ich brauche auch bei Torrent Leute mit 10 GB Plattenplatz und > anständiger Netzanbindung.
Gut, aber das sind ja schonmal harmlosere Anforderungen als "jemand dem Traffic voellig egal ist". 10GB Plattenplatz auf nem Server mit guter Anbindung und zumindest mal gut 100GB Traffic die egal sind haben hier doch sicher einige (ich zumindestens :). Hm, die Hegg 2004 Videos wollte ich von da aus auch mal seeden, aber ich hoffe die haben sich inzwischen auch so einigermassen verteilt? Statt das ueber Dein DSL rauszupusten kannste ja auch einfach mal 2-3 DVDs brennen und per Post verschicken, das muss doch ueber unsere Chaosstruktur zumindestens einigermassen unter die Leute zu bringen sein - also Du schickst es wem (z.B. mir :) und der kopierts sich und schickt's weiter und verteilt es dann in seinem Erfakreis und eben evtl. auf Server mit bischen Bandbreite fuer nen Torrent oder so.
> Das ist leider ein Problem der Aufnahme, weil ffmpeg (womit das > aufgenommen wurde) da beim Multiplexing gepfuscht hat.
Hm, wollen wir dann naechstes mal nicht wirklich einfach zumindestens paralell standard Consumergeraete mitschneiden lassen?
Also eben z.B. HD-Videorekorder... Ich habe hier einen Panasonic mit 400G Festplatte, da kann man 170 Stunden in 5MBit MPEG2 und wenn man will zusaetzlich etwas krankes MPEG4 aufzeichnen. Zumindestens die MPEG2s sind perfekt synchron und man kann sie direkt auf dem Geraet dann auch sauber (ohne reencode) schneiden. Ich behaupte mal damit haette man zumindestens einiges noch direkt am Abend als MPEG2 im Congressnetz haben koennen - und von da aus dann immernoch coole modernere Files encoden.
Auf der Hegg2004 haben wir halt in DV aufgenommen, unser Problem da war, dass wir zu wenig DV-Tapes hatten und die Videoengel mit dem Ueberspielen nicht nachkamen... (und natuerlich dass wir nur eine Kamera hatten und daher nur bis zu einem Vortrag gleichzeitig aufgenommen haben, aber prinzipiell hat das denke ich besser funktioniert als alle gleich-toll-mit-dem-Rechner aufnehmen Varianten...)
»Felix von Leitner« <usenet-20050...@fefe.de> wrote:
> Thus spake Rudolf Polzer (divver...@caths.co.uk): > > > 2. H.264 ist State of the Art und es existiert ein freier Decoder als > > > Teil von ffmpeg > > Der leider ständig abstürzt...
> Bei mir nicht. Ich encode seit ein paar Wochen meine gesammelten > Fernsehmitschnitte damit und konnte das bisher alles streßarm wiedergeben.
> Aber man braucht eine aktuelle Version von ffmpeg, das ist richtig.
Aktueller als im mplayer-CVS-Snapshot drin ist?
Bei mir geht das zumindest, bis auf den Crash beim Beenden. Und wie ich gerade sehe, ist er doch nicht so kritisch, da er nur mplayer und nicht mencoder betrifft - er tritt nämlich nur auf, wenn man übers Ende hinausseekt, aber nicht, wenn das Video "von selbst" zuende läuft. Bei mencoder passiert naturgemäß nur letzteres.
> > Womit erzeugst du die H.264-Files eigentlich? x264 oder Kommerzkram, > > wenn ja, welcher und gibt's eine Demoversion?
> Mit mencoder-cvs vom 29.4.2005 mit FAAC (dem CVS-Snapshot von deren > Server, ist vom letzten Jahr irgendwann) und x264 (svn von Ende April).
Aha, genau das bin ich zur Zeit auch am testen.
Bei dem Videomaterial, mit dem ich das teste, bringt H.264 ohne große Konfiguriererei etwa 15% Gewinn.
Was mir aus der Manpage nicht klar ist: wenn ich
-ovc x264 -x264opts qp_constant=23
nehme und nur mit einem Pass kodiere, verliere ich dann irgendwas außer ungefährer Bitratenkonstanz gegenüber dem three-pass-Verfahren?
> > Wenn du das sagst, wird das wohl stimmen, weil du es ausprobiert hast. > > Das heißt also, dass *DU* die Dateien so mit H.264 komprimierst, dass > > ffmpeg dabei NICHT ständig segfaultet. Hast du schon vor- und > > zurückspulen mit den Pfeiltasten im mplayer probiert?
> Ja, natürlich. Keine Frage, das ist alles bleeding edge und da wird > der eine oder andere noch ein bißchen Ärger mit haben, aber wir reden > hier von <10 Gig H.264/AAC im Vergleich zu 17 Gig MPEG-4/MP3. Für eine > Halbierung der Lager- und Downloadzeit finde ich es gerechtfertigt, daß > man sich mal die Playersoftware auf den aktuellen Stand bringen muß.
Das Problem ist bloß, dass es wohl noch keine halbwegs fehlerfreie Playersoftware dafür gibt. Nur ein Monat früher und mplayer wäre vollkommen ungeeignet gewesen.
> > Ich jedenfalls habe schon ein paar MKVs mit H.264-kodiertem Videostream > > gesehen, die mplayer beim Abspielen, manchmal erst beim Seeken, und > > manchmal "nur" beim Framedroppen (das lässt sich durch schnelles Drücken > > der Leertaste oder viel CPU-Last gut reproduzieren - oder > > Fullscreendarstellung mit -framedrop -vo x11 -zoom) zersäbeln.
> Daher hab ich auch AVI genommen :-)
> OGG habe ich noch überlegt.
Stimmt, im Gegensatz zu mkvmerge hat ogmmerge überhaupt kein Problem damit, ein H.264-kodiertes AVI als Videostreamquelle zu nehmen. Als FOURCC setzt es "h264", ist das richtig so?
Fragt sich, was bei gleichem Hörgenuss kleiner wird - AVI mit AAC oder OGM mit Vorbis. OGM ist leider etwas verschwenderisch im Umgang mit Bytes. Muss ich mal probieren.
> MKV traue ich nicht über den Weg. "Binary XML", wie krank ist das > denn bitte?!
Immerhin besser als Text XML.
-- <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"><html><title
</style><div class=f>Der vorhergehende Satz ist kopiergeschützt.</div> <hr>Best viewed with Mozilla Firefox 0.8 at 320x240 on FreeBSD 4.10.</html>
»Felix von Leitner« <usenet-20050...@fefe.de> wrote:
> Thus spake Rudolf Polzer (divver...@caths.co.uk): > > Es wäre daher gut, die Videos in einem Alternativformat anzubieten. Das > > kann durchaus auch ein schlechter aussehendes MPEG-4 mit niedrigerer > > Auflösung und kleinerer Datenrate sein.
> Spätestens beim nächsten Kongress wird das auch als MP4 irgendwo > rumliegen. Aber ins Netz stellen werde ich das zumindest nicht.
> > Kann ich den Link zur Keynote.avi den MPlayer-Entwicklern schicken?
> Na klar, gerne!
OK, werde ich tun... wobei, wenn ich das Ganze auch mit mencoder und x264 selbst reproduzieren kann, mache ich das.
> > Ach ja, und es gab noch ein größeres Abspielproblem als der H.264-Kram: > > der Vortrag wirkt sehr monoton und abgelesen ;) wie wäre es, wenn du da > > noch so ein schönes 50 Hz-Brummen drüberlegst, um ein wenig Spannung zu > > suggerieren? Leute, die vor der Kamera hin und herlaufen und ab und zu > > mal gegen das Stativ stoßen wären auch nicht schlecht... sagen wir es > > so: das Video ist so gut kodiert, dass man vom Vortragenden mehr > > erwartet.
> Das liegt am Vortragenden -- der Mann sitzt im Rollstuhl, und er hat > tatsächlich von Notizen abgelesen. Andere Vorlesende sind da lebhafter, > und insbesondere in Saal 3 laufen auch mal Leute durchs Bild, da geht > dann auch die Datenrate hoch.
Ich weiß, beim 20C3 war ich ja auch dabei... die Diskussion, warum ich nicht beim 21C3 war, muss jetzt aber nicht wieder gerauc^Waufgewärmt werden.
-- <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"><html><title
</style><div class=f>Der vorhergehende Satz ist kopiergeschützt.</div> <hr>Best viewed with Mozilla Firefox 0.8 at 320x240 on FreeBSD 4.10.</html>
> Hier auch 1.0-pre6-0.4, libfaad 2.0-r3 und libfaac 1.24 (alles aus dem > gentoo portage) und trotzdem hängt sich mplayer gleich nach dem starten > mit "h264.c:2023: hl_motion: Assertion > `((mb_type)&(0x0008|0x0010|0x0020|0x0040))' failed." auf.
Unmaske mplayer-1.0_pre7, damit funktioniert's.[1]
.BjH
[1] =media-video/mplayer-1.0_pre7 in die Datei /etc/portage/package.unmask schreiben. -- Whoever had created humanity had left in a major design flaw. It was its tendency to bend at the knees. --Terry Pratchett, Feet of Clay
> Trying to force audio codec driver family libmad... > Opening audio decoder: [faad] AAC (MPEG2/4 Advanced Audio Coding) > mplayer: relocation error: mplayer: undefined symbol: faacDecOpen
Ich seh gerade auf >ftp://ftp.nerim.net/debian-marillat/index.html>, daß das wohl ein Problem mit Paketen aus verschiedenen Repositories sein kann. Ich hab auch mal rarewares.org benutzt und bin grad nicht sicher, ob da noch Reste auf meinem System sind. Werd mal schauen.
>> Trying to force audio codec driver family libmad... >> Opening audio decoder: [faad] AAC (MPEG2/4 Advanced Audio Coding) >> mplayer: relocation error: mplayer: undefined symbol: faacDecOpen
> Ich seh gerade auf >ftp://ftp.nerim.net/debian-marillat/index.html>, daß > das wohl ein Problem mit Paketen aus verschiedenen Repositories sein > kann. Ich hab auch mal rarewares.org benutzt und bin grad nicht sicher, > ob da noch Reste auf meinem System sind. Werd mal schauen.
apt-get remove --purge libfaad2-0 inklusive aller Abhängigkeiten und Reinstallation derselben Pakete hat geholfen.
> > wurscht. Ich brauche auch bei Torrent Leute mit 10 GB Plattenplatz und > > anständiger Netzanbindung. > Gut, aber das sind ja schonmal harmlosere Anforderungen als "jemand dem > Traffic voellig egal ist".
Naja Moment, diese Art Seeden läuft ja vermutlich von ganz alleine an. Ich hätte gerne von Anfang an ein paar Sites, die das schon vollständig haben, und ohne große Schmerzen eine Weile seeden können.
> Statt das ueber Dein DSL rauszupusten kannste ja auch einfach mal 2-3 > DVDs brennen und per Post verschicken, das muss doch ueber unsere > Chaosstruktur zumindestens einigermassen unter die Leute zu bringen > sein - also Du schickst es wem (z.B. mir :) und der kopierts sich und > schickt's weiter und verteilt es dann in seinem Erfakreis und eben > evtl. auf Server mit bischen Bandbreite fuer nen Torrent oder so.
Na klar, kann man andenken, sowas. Aber laß uns das klären, nachdem klar ist, wie viele Leute mit seeden von Anfang an.
> Tss, was jammerst Du? In Berlin habt Ihr auf Grund anderer Sendeparameter > nicht nur 12.75 sondern 14.25 MBit für 4 Kanäle zur Verfügung, das sind also > pro Sender fast 400 kBit mehr. Die Bildqualität ist dementsprechend hier in > NRW noch deutlich schlechter als das, was ich beim Congress per DVB-T bekam. > Mit DVB-T wird jetzt in großem Maßstab ein Video-Codec unter die Leute > gebracht, der schon seinen Zenit überschritten hat. Man hätte besser noch > zwei Jahre gewartet.
Also hier in Berlin ist das Gerüchten zufolge so, daß das alte SAT-Encoder-Equipment für DVB-T recycled wurde, und von der Förderkohle für die DVB-T Einrichtung haben sich die Sender dann neues SAT-Encoder-Equipment gekauft. Vermutlich gleich HDTV-fähig und so.
|
