Posts by Doc


    Hi Sven,


    Danke für den Tipp! Ich habe ja jetzt die ISO-Standards über die MPEG Streams, aber es tauchen bestimmt weitere Fragen auf....


    Leider habe ich momentan nicht viel Zeit, aber ich werde zwischendurch immer mal wieder den Fortschritt posten (im anderen Thread). Hoffentlich dann auch mal Code ;-)


    Cheers


    doc

    Hallo Holger,


    transcode ist ein ultra-mächtiges Packet, welches Video und Audio Formate via plugins lesen und schreiben kann, also das Format der Daten ändert.


    ds.jar habe ich immer nur benutzt, um Video und Audio Daten "auszupacken", hier wird keine Konvertierung in in anderes Format vorgenommen. Durch das Entfernen der "Verpackung" gehen aber AV-sync Infos verloren, und dafür hat ds-jar kompensiert (also Audio Frames eingefügt oder gelöscht).


    Warum soll das nicht auch transcode können?
    Ja, warum eigentlich nicht? Das Problem ist nur, dass es das bis jetzt nicht kann, und ich kein C programmieren kann um das Feature selber hinzuzufügen. Es wäre eher ein Helper-Tool in Transcode nötig (so wie tcprobe oder tcmplex).


    Weil ich die ds.jar Lücke gerne schliessen würde, habe ich mich also mit PES und ES streams beschäftigt und bin dabei, einen ds.jar Ersatz in Perl zu versuchen. (Eigentlich kann ich auch kein Perl, aber immer noch besser als C). Wie in meinem anderen Thread schon angedeutet, wäre ich froh wenn jemand, der wirklich programmieren kann, ein Tool schreiben würde (oder transcode erweitern würde). Aber da ich von niemandem weiss, der an sowas arbeitet, habe ich mich halt selber mal drangesetzt.


    Zum Thema Gehirnschmalz:
    Ich kann zu transcode nichts beitragen (Ist in C, beschäftigt sich mit transcodierung von video und Audio Daten ...)
    Also werde ich mein Schmalz weiter in Perl stecken müssen. Was ich versuchen kann (und das habe ich ja getan), ist, die grundsätzlichen Infos über die Problematik, die ich gefunden habe, mal zu posten, damit andere sich ein Bild davon machen können. Die kann auch jemand als Ausgangspunkt nehmen, der das Problem in C angehen will.


    Mein Fazit:


    - Transcode ist ein mächtiges transcodier Tool, ds.jar ist ein "Entpacker"
    - Wäre cool wenn transcode auch entpacken könnte (via eines neuen tools wie tcpesdemux), aber wer schreibt's?
    - Ich kann nur Perl, also versuche ich ein Tool in Perl (wäre ja auch schön, wenn es unter Windows / MacOS etc laufen könnte)


    Cheers


    doc

    Hey ma.hoff,


    vielen Dank für die Antwort! Gerade die Info mit dem Drift in "freier Wildbahn" war mir neu. Ich werde mal weiterspielen, gestern habe ich Star Wars geschnitten und gebrannt, das taugt wahrscheinlich ganz gut zum testen, da ja ein AC3 stream drin ist und jede Menge Werbung raus musste.
    Noch ein paar Dinge zu meinem "Roman":
    - PTS stamps sind leider gar nicht an jedem PES Packet dran, sondern müssen nur alle 700 (oder 70?) ms auftauchen. Den Rest soll der Encoder interpolieren. Ausserdem wird es unangenehm weil die Timestamps in meinem Test-Stream für Video Daten auch nicht schön brav immer aufsteigen. Hier mal eine Demo vom Video Stream:


    Gap: Abstand zu vorherigem PTS im Video Stream (in Clock Ticks, also 90 Khz Ticks)
    Packet: Nummer des PES Packets, das den PTS Stamp enthielt (von 0 an gezählt)
    dec: in decimal decoded (vorher hatte ich mal Bitmuster in der Analyse, deshalb der komische Name)
    secs: Das ganze in Sekunden, also dec / 90000


    Gap: 12007330552 Packet: 0 dec: 12007330552 secs: 133414.783911111
    Gap: -7200 Packet: 23 dec: 12007323352 secs: 133414.703911111
    Gap: 3600 Packet: 30 dec: 12007326952 secs: 133414.743911111
    Gap: 14400 Packet: 36 dec: 12007341352 secs: 133414.903911111
    Gap: -7200 Packet: 48 dec: 12007334152 secs: 133414.823911111


    Und Audio hinterher
    Gap: 12007298118 Packet: 11 dec: 12007298118 secs: 133414.423533333
    Gap: 12961 Packet: 45 dec: 12007311079 secs: 133414.567544444
    Gap: 12960 Packet: 78 dec: 12007324039 secs: 133414.711544444
    Gap: 12959 Packet: 112 dec: 12007336998 secs: 133414.855533333
    Gap: 12960 Packet: 145 dec: 12007349958 secs: 133414.999533333


    Im Video Teil folgen die PTS Einträge in netten Mustern, immer -7200 / 3600 / 14400 "Ticks" zwischen den PTS-Stamps und dann wieder von vorne. Wenn das immer so schön regelmässig sein sollte, dann könnte man natürlich einfach eine mittlere Zeit berechnen...


    Audio ist super reglemaessig, kein Problem hier.
    Also werde ich mich mal ranmachen, und das über einen längeren Stream ausprobieren.


    Allerdings hätte ich mal wieder ein paar Fragen:
    Auf DVDs sind in den VOBS ja auch PES Streams.
    - Kann man nicht evt unter Beibehaltung der PES Strukturen einen DVD-kompatiblen Stream erzeugen? Wie unterscheidet sich der DVD-PES-Stream vom .vdr-PES Stream?
    - Ich komme auf total andere absolute Werte als ds.jar, wenn ich die PTS-Stamps decode, relativ bleibt der Abstand aber gleich. ???
    - mein Test mit der Korrektur hat funktioniert, in dem ich 6 Frames weggeschmissen habe (am Anfang des Audio Streams), ds.jar hat am Ende vier anghängt. Das ging auch. ??????


    Naja, ich halte euch auf dem laufenden.


    Cheers


    doc


    PS: Gehört der Thread jetzt besser in ein anderes Forum?

    Hallo,


    ich dachte, ich gebe mal 'ne Zusammenfassung von meinen Versuchen (vielleicht kann ich ja ein paar Mitstreiter locken ...)


    Vorne weg ein paar Details:mein


    - Ich habe einen DVD-Brenner und brenne liebend gern Mitschnitte ohne Werbung auf DVD, insbesondere wenn Sie mit AC3-Sound kommen (Pro7) oder zusätzlich mit Originalton (Arte).
    - Hierfür nehme ich u.a. ds.jar, da ich ja von den VDR Dateien zu einem DVD-Image kommen muss (geschnittenes vdr durch ds.jar, dann tcmplex, dann dvdauthor, dann mkisofs und dvdrecord)
    - Das klappt wunderbar (meistens), aber ds.jar ist ja nun nicht mehr
    - Mein grösstes Problem war immer Audio/Video Sync, und das hätte ich gerne für alle Kanäle gelöst. ds.jar war echt prima...
    - Also hätte ich gern einen Ersatz für ds.jar, möglichst unter Linux auf der Kommando Zeile
    - Ich kann nicht Programmieren, und das bisschen, was ich kann, ist Perl, aber was soll's?


    Also habe ich mich auf die Suche nach Infos über MPEG2 Streams gemacht. Da ich mal aufgeschnappt habe, dass .vdr Files PES Dateien sind und ich als input von mplex immer ES-Streams angeben muss, wollte ich auch wissen, wie die aufgebaut sind.


    Hier erstmal eine Uebersicht über die Infos, die ich gefunden habe. Falls ein Guru das liest, BITTE KORRIGIEREN UND ERGAENZEN. Danke.


    Eine Video Datei im MPEG Format (ES = elementary stream):


    - Einzelne Frames sind in GOPs (groups of pictures) organisiert, das erste Bild in voller Schönheit (I-Frame), die danach als Differenz zu dem Frame davor (P-Frame), oder als Differenz zu dem davor UND dem danach (B-Frame). Meistens (immer?) sind 15 Frames in einer GOP. Die Länge eines GOP (in Byte, nicht in Frames) variiert je nach Komprimierungsgrad von GOP zu GOP (variable Bitrate).
    - Aus der Frame-Rate und der Anzahl der Frames ergibt sich zwangsläufig die Länge des Videos. Soweit alles ganz ok.


    - Audio (ebenfalls ES Stream)
    -Eine Audio Datei im MPEG Format (MP2) besteht aus Frames, die immer 1152 Bytes lang sind. Aus der Bitrate und der Anzahl der Frames ergibt sich die Länge des Audiostücks. Soweit auch ganz klar.


    Nun wirds langsam interessant:


    Wenn man Audio und Video Dateien synchron abspielen will und nur einen Uebertragungskanal hat (so wie z.B. ein .VOB File auf einer DVD oder wie ein .vdr File), dann muss man abwechselnd Video und Audio Daten senden. Damit sind wir (fast) beim


    PES Stream (= packetized elementary stream):
    - Der PES besteht also aus zerhackten und gemischten Video und Audio Streams. Etwa so:


    ES-Video: VVV VVV VVV VVV VVV VVV VVV VVV VVV
    (V steht für Video Stream, drei Vs ein GOP)


    ES-Audio: AA AA AA AA AA AA AA
    (A steht für Audio, zwei As ein Frame)


    PES A/V: VVAVVAVVAVVAVVAVVAVVA


    OOPs, nun sind die GOPS und die Audio Frames zerhackt..... Macht aber nix (später mehr). Das eigentliche Problem besteht in der Synchronisation der Daten. Welches (wieder rekonstruierte) Audio-Schnippselchen gehört zu welchem (rekonstruierten) Video-Schnippselchen? Wenn der Sender einen kontinuierlichen Stream schickt, dann hat man ja schliesslich keinen Anfang und kein Ende.


    Jetzt kommen die PES-HEADER ins Spiel:
    Der PES Stream enthält neben den zerhackten GOPs und Audio Frames auch Packet-Header, in denen Infos zur Audio/Video Synchronisation stehen. Eigentlich sieht der Stream so aus:


    PES-A/V: HVHVHAHVHVHAHVHVHA
    (H für Header)
    Also steht vor jedem PES-Packet ein Header mit Infos über den Stream (Welcher Stream ist es, Video 1 oder 2 oder 3 ... Audio 1 oder 2 oder 3 ... Private Data (Teletext) oder oder oder) und mit TIMING Infos. D.h. der Header kann einen Zeitstempel enthalten, der sagt "spiele diesen Schnipsel bei 10.543 sec".


    Also habe ich versucht, in einem 5 min .vdr File PES-Packete zu finden. Die starten immer mit 0x000001, dann kommt die Stream Bezeichnung und dann die Länge des Packets. Und siehe da: es geht (nach eingem Tüfteln), ich kann mich per Skript von Packet zu Packet "hangeln".


    Dann habe ich versucht, die Streams in eigene Dateien zu schreiben (also Audio PES Packete in ein File und Video-PES Packete in ein anderes). Es geht, mplayer spielt den Video Stream ohne Ton, tcprobe sagt einmal Audio und einmal Video. Hurra.


    Schliesslich habe ich versucht, die PES-Header los zu werden. Dazu habe ich nicht mehr die gesamten Packete in getrennte Dateien geschrieben, sondern nur den Payload (=Packet minus Header). Und was soll ich sagen: Es geht! Kein Problem mit zerhackten GOPs oder Audio Frames. Die Payloads hintereinander ergeben saubere ES Streams. mplayer und tcprobe sind happy. Cool....oder?


    Nun habe ich also das langweiligste programmiert, was man sich nur vorstellen kann: denn X-ten demuxer, den niemand haben will oder gebrauchen kann. Der produziert aus .vdr files (die ja PES sind) getrennte Audio und Video ES-Streams. Und dafür habt Ihr bis hierher gelesen. Sorry.


    Tut mir echt leid.


    Aber es geht noch ein wenig weiter (ich sage nicht, dass es besser wird ;-))
    Wie gesagt, der X-te demuxer, der sich nicht um A/V Sync kümmert. Nun, die anderen demuxer sagen ja sogar noch, wieviel Verschiebung die Audio und Video Streams in ms haben. Der mutiplexer der dvb-mpegtools der Metzler-Bros nimmt sogar ein .vdr File auseinander, und baut es ohne shift wieder zusammen - manchmal.
    Wo ist das Problem? Warum nur manchmal? Was programmiere ich mir zusammen, wo ich doch gar nicht programmieren kann? Mal wieder ein bisschen ASCII-Art (mit der bitte um Korrektur):


    Ein PES:
    HVHVHAHVHVHAHVHVHA


    In den PES-Headern stecken, wie oben gesagt, Timing Informationen, genauer gesagt PTS und DTS Infos. Das sind die Zeitstempel die angeben, wann ein bestimmtes Schnippselchen Audio oder Vodeo Dekodiert (DTS) oder Präsentiert (=abgespielt) werden soll. Wenn also der erste Teil meines PES aus
    HVHV
    besteht, dann steht da z.B. drin, "abspielen nach 00:00:10.345". Danach kommt
    HA
    da steht z.B. drin "abspielen nach 00:00:10.545".
    Nun kann ich getrost hingehen und demuxen und sagen "Audio Abspielen muss 200 ms nach Video Abspielen starten". Nun kommt das Schneiden (oje oje oje)
    Vorher
    HVHVHAHVHVHAHVHVHAHVHVHA
    Schnitt | |
    HVHVHAHVHVHVHAHVHVHA
    Das soll heissen: Ich habe ein bisschen Video rausgeworfen, aber wieviel Audio weiss ich auch nicht so genau undistjaauchgarnichtsoschlimmoderweilichguckjanuraufGOPsundüberhaupt


    In anderen Worten:
    - wegen der GOP Strukturen kann mann nur effizient (=sehr schnell) zwischen GOPs schneiden (also alle 15 Bilder), sonst müsste man die Bilder neu kodieren (laaaange Arbeit => transcodiere mal 'nen Spielfilem)
    - dabei gehen aber, tja, weiss auch nicht, ein paar Audio Frames drauf. Wieviele? Puuh, soviele wie zwischen den GOPS halt stehen, die wegfallen. Lange Rede, kurzer Sinn:
    Durch das Schneiden an GOPs ergibt sich eine Veränderung der A/V Verschiebung. Deshalb war/ist ds.jar wahrscheinlich so cool: es findet Schnitte und gleicht spätere Verschiebungen durch Einfügen oder Löschen von Audio Frames aus. HIER BITTE JA ODER NEIN ANTWORTEN (Nein bitte mit Erklärung ;-))


    Das habe ich natürlich auch ausprobiert, und habe meine 5 min test .vdr File mit meinem Demuxer demuxt und mit tcmplex wieder zusammengebaut: Ergebnis: A/V nicht mehr synchron.
    Dann habe die AV sync aus den PTS-Stamps des PES Streams berechnet und 6 Audio Frames weggeschmissen. Siehe da, nach remux wieder synchron. Hey Coool! Was für ein schöner 1ster Mai (na gut, wenn man seinen Compi liebt)!


    Also werde ich mal weiter tüfteln (der nächste erste Mai kommt bestimmt), und jetzt seid Ihr dran (wenn Ihr noch dran seid):


    - Habt Ihr überhaupt bis hierhin gelesen? Wirklich? Warum? Könnt Ihr nicht schlafen?


    - Wisst Ihr was über den Quatsch, den ich geschrieben habe, oder kennt Ihr jemanden, der jemanden kennt, der mir auf die Sprünge helfen könnte (dein Opa sein Kollege sein Enkel oder so)?


    - Würdet Ihr so ein Tool überhaupt wollen, oder ist ds.jar / PVAstrumento gut genug?


    - Könnt Ihr programmieren und sowas nicht viel besser als ich?


    - Wisst Ihr wie man einen PTS-Timestamp mit 33 bit verteilt auf 40 Bit am besten in Perl entschlüsselt? Oder wo derjenige wohnt, der sich so was ausgedacht hat? Wärt Ihr bereit, dem mal den Marsch zu blasen? (Erklärung: hier das PTS-TIMESTAMP Format als BIT-Code:
    0010XXX1XXXXXXXXXXXXXXX1XXXXXXXXXXXXXXX1
    die Xse sind wichtig, die anderen Bits sind immer wie angegeben)
    - Würdet Ihr ein Tool testen und mehr Feedback geben als "echt sch*** dass Du nicht coden kannst" (das weiss ich nämlich schon;-))?


    JETZT KOMMTS:
    - Wie ist AC3 aufgebaut? Wie MP2 was die Header angeht?
    - Wäre das Beste nicht Frame-genaues Schneiden, mit einem neuen GOP mit evt weniger als 15 Frames? Kann ein DVD Player das lesen?
    - Wenn man über den Audiostream sync-Pannen ausbügeln will, muss man dann nicht eigentlich den Audiostream komplett neu kodieren, weil man sonst auch nur in Frame Schritten arbeiten kann?
    - Wie lang ist ein Audio Frame eigentlich? Meine Rechnung:
    1152 Byte/s / 192KBit/s = 0.048 s. Stimmt das? Wie ist das mit anderen Bit-Raten? Ist MP2 immer "constant bit rate" codiert? Wie ist das mit AC3?


    Ich habe noch mindestens 100 Fragen mehr, aber
    1) es ist spät
    2) Bier ist alle
    3) Ich muss mal Rauchen
    (ich weiss, ich lebe VIEL zu ungesund)


    Ich freue mich auf Input


    Cheers


    doc

    Hi,


    ich war gerade ne Woche im Urlaub und habe keinen Compi angefasst ....


    Aber vorher habe ich noch ein paar Infos gefunden:
    http://happy.emu.id.au/lab/tut/dttb/dttbtuti.htm
    hat ein paar Infos ueber die Header Strukturen, Packetized Elementary Streams usw. Mal schauen, ob ich die Sachen mit nem HEX-Editor in den VDR Aufnahmen finden kann, danach würde ich erstmal einen Parser versuchen (also die Streams analysieren und Infos ausgeben).
    Ich habe auch noch ein paar Info-Quellen mehr gefunden, aber die sind etwas spezieller und behandlen die Header der Packete nicht im Detail...
    Es wird aber wohl noch eine ganze Weile dauern, bis was kommt. Mein Brötchengeber hat im Moment 'ne Menge Aufgaben für mich (das ist irgendwie immer so nach dem Urlaub ;-))


    CU


    Doc

    Hi Olaf,


    ich bin in letzter Zeit ganz gut damit gefahren auf


    http://packman.links2linux.de/


    bereitgestellete Packete für SuSE runterzuladen. Die für SuSE 8.1 haben alle bestens funktioniert. (libdvdnav, libdvdread ....)
    Nun ist die 8.2 so neu, dass es dort noch nicht so viele Packete für 8.2 gibt, aber bei vielen habe ich einfach das Source Packet runtergeladen und mit


    > rpm --rebuild Packetname


    auf 8.2 neu übersetzt. Das fertige Packet (bzw oft auch 2, eines als devel Packet) sind dann in /usr/src/packages/RPMS/i386/
    (manchmal auch in i686 oder i585).
    Von da aus installieren und - funzt.


    Wahrscheinlich werden sich in Zukunft aber immer mehr Packete für 8.2 dort finden lassen (so hoffe ich zumindest)
    Eine Liste mit alle Packages für 8.2 kann man hier anschauen:
    http://kbs59.informatik.uni-bremen.de/~henne/suse/8.2/i686/


    Kannst ja mal testen....


    Cheers


    Doc

    Hi Tom,


    Wichtig: Du musst auf jeden fall das libdvdread-devel-packet installiert haben:
    SuSE 8.2:


    > rpm -qa | grep dvdread
    libdvdread-0.9.3-86
    libdvdread-devel-0.9.3-86


    > rpm -ql libdvdread-devel
    /usr/include/dvdread
    /usr/include/dvdread/dvd_reader.h
    /usr/include/dvdread/ifo_print.h
    /usr/include/dvdread/ifo_read.h
    /usr/include/dvdread/ifo_types.h
    /usr/include/dvdread/nav_print.h
    /usr/include/dvdread/nav_read.h
    /usr/include/dvdread/nav_types.h
    /usr/lib/libdvdread.a
    /usr/lib/libdvdread.la
    /usr/lib/libdvdread.so


    => also folgende Zeile:


    > gcc -o dvdbackup -I/usr/include/dvdread -L/usr/lib -ldvdread dvdbackup.c


    Die Versionen auf 8.1 kann ich nicht mehr raussuchen, aber dvdbackup lief ohne Probleme auch auf 8.1 (und 8.0).


    Falls Du "zu Fuss" compiliert hast, dann ist locate Dein Freund


    > locate libdvdread


    und


    > locate dvdread | grep include


    Falls Du locate nicht installiert hast => yast Software installieren => nach locate suchen (fileutils-locate oder so) => installieren und als root:
    > updatedb


    eingeben=> Warten..... Warten => locate benutzen


    Viel Erfolg


    Doc

    Hi jul,


    zum Thema bearbeiten:
    Warum rippst Du mit dvdbackup nicht nur das, was Du haben willst? Mit dvdbackup -I gibt es alle Infos ueber Kapitel usw, dann wähle doch einfach nur den Titelset aus, den Du haben willst ("dvdbackup -T x"). Du kannst ja auch vor dem rippen mit "mplayer -dvd x " anschauen, ob das der korrekte Titel ist. Wenn Du mehrere haben willst, dann machst Du das ganze mit allen gewümschten Titelsets hintereinander, Trailer und Copyright sind fast immer eigene Titelsets, die Du auf diese Art schon los wirst.
    Zum Abspielen: Ich habe das Mplayer plugin nicht installiert, aber damit koennte das Abspielen schon gehen (?).


    Wenn Du wirklich .vdr Files daraus machen willst, dann musst Du die VOBs in "generic" MPEG2 streams konvertieren. Ich habe gerade kein ds.jar hier, aber Du müsstest wahrscheinlich als erstes mal damit demuxen (habe ich aber noch nicht mit VOBs probiert) , Dich dann für maximal 2 Audio-Spuren entscheiden und einen generischen MPEG2 Stream multiplexen (zb mit tcmplex von transcode) und den 001.vdr nennen.
    Danach kannst Du versuchen, mit genindex (oder so) die Index-Datei zu erstellen, die vdr erwartet, und das ganze unter einer Verzeichnisstruktur abzulegen, wie sie auch VDR erzeugt (wie bei einer Aufnahme).
    Du könntest ausserdem versuchen, zwei Folgen einfach mit "cat folge1.vdr folge2.vdr > 2folgen.vdr; mv 2folgen.vdr 001.vdr" zusammenzuhängen, bevor Du den Index erzeugst.


    Ein anderer Ansatz wäre, per tccat (auch von transcode) nur einen Titelset in eine Datei zu "cat-ten" und damit weiter zu "spielen".


    Alle Angaben ohne Gewähr, da ich das noch nicht selber versucht habe.


    Viel Erfolg.....


    Doc

    Hi,


    nach meiner Erfahrung lässt sich DMA für die Platten nur dann nicht aktivieren, wenn der Chipsatz-Treiber noch nicht im Kernel enthalten ist. Eigentlich behebt ein aktueller Kernel das Problem (fast) immer. Wenn es irgend geht, würde ich aber einen SuSE Kernel nehmen, weil das mit Abstand am einfachsten geht. Eigene Kernels laufen bei mir zwar auch sehr gut, aber meistens vergesse ich doch, irgedwas anzuwählen, oder ich nehme doch alles, und dann kann ich auch gleich 'nen SuSE Kernel installieren.


    Cheers


    Doc

    Hallo zusammen,


    hat jemand eine link zu einer guten Dokumentation über MPEG-STREAMs (ES und PES wären nötig)? Ich würde gerne mal damit rumspielen, um eventuell einen Demux-Ersatz für ds.jar zu basteln. VDR sollte ja eigentlich PES Streams aufzeichnen, und die Multiplexer, (von den Metzlerbros und tcmplex von transcode) die ich ausprobiert habe, schlucken auch ES_STREAMs ohne zu murren. Das Schöne an ds.jar ist ja, dass die A/V sync ganz gut funktioniert (zumindest bei mir). Also waere die minimal-Lösung ein Dumxer mit A/V sync Korrektur.
    Ich kann zwar nur begrenzt coden, aber ein wenig versuchen kann man es ja mal.
    Die Dokumente, die ich gefunden habe, sind nicht so ganz brauchbar, und der ISO Standard kostet ....


    Bin froh über jeden Tipp


    Cheers


    Doc

    Hi,


    auf 8.2 ist schon vdr-1.1.25 enthalten, ausserdem eine Treiberversion vom 24.02.2003. Mit ein wenig Glück läuft die Kiste also schon ohne Handarbeit.....


    Viel Erfolg


    Doc

    Hi,


    ich hatte das Problem auch mal auf einem Dell (ich denke es war 8.0), aber ich habe lieber den "Mantel"-Kernel genommen, als einen Vanilla-Kernel zu patchen, danach war alles ok (Hubert Mantel ist bei suse fuer die Kernels zusteandig, glaube ich), ftp://ftp.suse.com/pub/people/mantel/next/RPM/
    aber dort gibt es immer nur die Testversionen fuer die aktuelle SuSE.
    In jedem Fall wuerde ich alle verfuegbaren Update Kernels einspielen.....


    Viel Glueck


    Doc

    Hallo,


    ds.jar findet bei mir eigentlich immer AC3 streams (Pro7), allerdings nur, wenn ich nicht zu "grosszuegig" schneide; d.h. wenn noch ein Stueck ohne AC3 davorhaengt, dann klappt es nicht. Ich nehme meistens die erste GOP des Films weg, um auf der sicheren Seite zu sein. Zum testen kannst Du auch ein Stueck aus der Mitte des Filmes schneiden und mit ds.jar demuxen.


    Viel Erfolg


    Doc

    Hallo,


    die beiden streams (oder auch beide und teletext) kriegt man super mit ds.jar demuxt, und der korrigiert auch A/V sync, so dass nach neuem muxen (bei mir immer fuer DVD) alles schoen synchron laeuft. Die Homepage von ds ist allerdings irgendwie abgetaucht .....


    Cheers


    Doc

    Hallo,


    für ein einfaches weiterbearbeiten reicht ein


    cat 001.vdr 002.vdr > neu.vdr


    Wenn Du das Ergebnis mit dem vdr anschauen willst, habe ich keine Ahnung was bei Dateien über 2GB passiert ....
    Den Index fuer die neue Datei würde ich auch per genindex generieren.


    Zum Anschauen per VDR solltest Du einfach eine entsprechende Verzeichnisstruktur anlegen (wie bei einer Aufnahme), und das neu.vdr sollte 001.vdr heissen. Der Index darf natuerlich nicht fehlen...


    Hope that helps


    Doc