Hmm... Grab Engine wichtig fuer erfolgreiches Demuxen?

[Schlunz]

Ich probier gerade diverse Varianten beim Grabben, bin mittlerweile bei JTG gelandet und hab mir widerwillig dotnet installiert, wie auch immer... bisher habe ich mit der WinGrab-Engine ueber diverse Streamingserver (Ngrab z.b.) gestreamt, und beim Demuxen / Korrigieren mit Project X gabs eigentlich nicht eine Fehlermeldung. Perfekt, sozusagen.

Da sich nun aber manche Sender bei mir nicht sauber Streamen liessen hab ich mal die Option von JTG genutzt und mit "ggrab" gestreamt. Tolle Sache, hatte ueber 6 Stunden Daueraufnahme nicht 1 Resynch... http://www.mysmilie.de/smilies/schilder/2/img/010.gif

Wie dem auch sei, wenn ich diesen mit ggrab erzeugten Stream mit Project X Demuxen will bekomme ich beim abschliessenden Check&Synchronize am laufenden Band eine Fehlermeldung ueber falschen Timecode bei 00:00:00, ich glaube die Meldung wird pro Frame erzeugt und die Bearbeitung dauert sehr lange. Mache ich was falsch? Ist ggrab nicht gut? Muss ich bestimmte Parameter veraendern?

[Lucike]

Hi Schlunz,

das ein Grabtool keine Syncs anzeigt bzw. produziert ist eigentlich fast nicht möglich. Diese Tools meckern wohl erst beim Überspringen mehrerer GOPs. :?

Wenn ich über die DBox2 streame, verwende ich immer noch das gute alte WinGrab von Elminster. Das zeigt Fehler zuverlässig an und es gibt beim Demuxen absolut keine Probleme.

Ich muß JTG wirklich mal ausprobieren. Ich habe das Famework ja bereits drauf. Mein Matrox Parhelia braucht das leider für die Feineinstellung. :?

Gruß
Lucike

[Schlunz]

Tja, nach ein bisschen Rumprobieren mit den Streams ist das auch mein Fazit: WingrabEngine benutzen. Ich glaube es werden mit ggrab keine Synchs angezeigt weil die wirklich nicht gemacht werden / ggrab korrigiert die Streams nicht / wie auch immer... :?


EDIT: so schnell geb ich dann doch nicht auf, und die Option zur Erfolgreichen Bearbeitung bringt Project X mit: Reiter "spec", specials 2, "take only first Audio PTS for synch".... allerdings muss ich jetzt erstmal den kompletten Stream anschauen, ob das wirklich die richtige Massnahme war.

[Lucike]

Ich weiß nicht. Die Funktion bewirkt, daß nur der Anfang synchronisiert wird und alle darauf folgenden Lücken werden dann nicht mehr mit Frames aufgefüllt. Hm ... :|

Gruß
Lucike

[Kamikaze_12]

Hallo,
ich weiß das dieser thread schon etwas älter ist, aber da ich dasselbe Problem habe möchte ich mal nachfragen ob es hierzu irgendwelchen neuen Erkenntnisse gibt.
Ich benutze ggrab unter Suse 8.2 und bin damit eigentlich ganz zufrieden zumal es meines Wissens keine vernünftige Alternative unter Linux gibt.. Ggrab bemüht sich nach meinem Kenntnisstand darum beim streamen möglichst wenig vom Stream wegzuwerfen, d.h. da wo andere Tools einen resync machen wird bei ggrab einfach weiter aufgezeichnet.

Den Trick mit der Option "take only first Audio PTS for sync" habe ich auch schon herausgefunden und es scheint bisher auch immer funktioniert zu haben, aber schöner wäre es natürlich wenn das auf normale Weise funktionieren würde.

Sollte hierzu in der aktuellen Version etwas geändert worden sein, BITTE BITTE nicht hauen! Die habe ich mir gerade erst gezogen und werde sie nachher ausprobieren. Ggfs kann ich dann morgen auch ein LOG posten (komme zur Zeit nur in der Firma ins Netz).

[dvb.matt]

Sollte hierzu in der aktuellen Version etwas geändert worden sein
nicht das ich wüßte...

bislang hat aber noch niemand die Sache wirklich hinterfragt, also weder Log- noch andere Daten beigesteuert...

mfg

[Kamikaze_12]

Asche auf mein Haupt...

Jetzt habe ich gestern extra Logfiles erstellt und wa mache ich Depp? Vergesse sie in die Firma mitzunehmen...GRRR!

Werde sie dann am Montag mitbringen und hier posten.

Schönes Wochenende allerseits!

[Kamikaze_12]

So da bin ich wieder!

Und hier die Logfiles...

erstmal das ohne "take only first Audio PTS for sync":

(0) AC-3,CM,2/0(2.0),48000Hz,448kbps
(1) AC-3,CM,3/2lfe(5.1),48000Hz,448kbps
(2) AC-3,CM,2/0(2.0),DS,48000Hz,384kbps
3 additional AC3 frames loaded..
X V0.81.4 (29.08.2003)

=== session infos ===

=> working with collection 4
-> write output files to :
E:\Temp\_umzurechnen\

=> File 0: J:\PREMIERE_NOSTALGIE_Das_Gasthaus_an_der_Themse_2 0030903_2214511.vob (1780912128 bytes)
=> File is MPEG-2 PS/SS (Video/Audio PES)
=> demux
-> found PES-ID 0xE0 (MPEG Video)
-> found PES-ID 0xC0 (MPEG Audio)
-> video basics: 480*576 @ 25fps @ 0.6735 (4:3) @ 15000000bps, vbvBuffer 112
dropping useless B-Frames @ GOP#0 / new Timecode 00:00:00.000
dropping gop(sequence) @ orig.PTS 00:00:00.599 / new Timecode 00:00:00.400
GOP#1, Pics expected/count 14/9 ; PTS difference 0ms (should be 0)
dropping useless B-Frames @ GOP#2 / new Timecode 00:00:00.400
video: fr/ct/1p/cg/og/dg 135071/2/0/10971/0/1
videolength: 135071f @ 01:30:02.840
avg. nom. bitrate 2413385bps (min/max: 168400/4892400)
set first sequence_header bitrate to 4892400bps
===> new File: E:\Temp\_umzurechnen\PREMIERE_NOSTALGIE_Das_Gastha us_an_der_Themse_20030903_2214511.mpv
--> MPEG Audio (0xC0)
Audio PTS: first packet 00:00:00.331, last packet 01:30:04.083
Video PTS: start 1.GOP 00:00:00.199, end last GOP 01:30:03.719
-> adjusting audio at video-timeline
-> 6 frame(s) (144ms) pre-inserted @ 00:00:00.000
=> src_audio: MPEG-1,Layer2,48000Hz,stereo,192kbps,noCRC @ 00:00:00.144
-> skipped sourceframe(s) @ 00:00:00.216
-> skipped sourceframe(s) @ 00:00:00.288
-> skipped sourceframe(s) @ 00:00:00.336
-> skipped sourceframe(s) @ 00:00:00.336
-> skipped sourceframe(s) @ 00:00:00.336
...[gekürzt, scheint für jeden weiteren Frame ausgegeben zu werden]
-> skipped sourceframe(s) @ 00:00:00.336
-> skipped sourceframe(s) @ 00:00:00.336
-> skipped sourceframe(s) @ 00:00:00.336
-> skipped sourceframe(s) @ 00:00:00.336
-> skipped sourceframe(s) @ 00:00:00.336
audio frames: wri/pre/skip/ins/add 14/6/26691/0/0 @ 00:00:00.336 done..
===> new File: E:\Temp\_umzurechnen\PREMIERE_NOSTALGIE_Das_Gastha us_an_der_Themse_20030903_2214511.mp2

summary of created media files:
.Video: 135071 Frames 01:30:02.840 E:\Temp\_umzurechnen\PREMIERE_NOSTALGIE_Das_Gastha us_an_der_Themse_20030903_2214511.mpv
Audio 0: 14 Frames 00:00:00.336 6/26691/0/0 E:\Temp\_umzurechnen\PREMIERE_NOSTALGIE_Das_Gastha us_an_der_Themse_20030903_2214511.mp2
=> 1629900037 bytes written...

Das war eindeutig nicht das was wir haben wollten.

Mit "take only first Audio PTS for sync" sieht es dann so aus:
X V0.81.4 (29.08.2003)

=== session infos ===

=> working with collection 4
-> write output files to :
E:\Temp\_umzurechnen\

=> File 0: J:\PREMIERE_NOSTALGIE_Das_Gasthaus_an_der_Themse_2 0030903_2214511.vob (1780912128 bytes)
=> File is MPEG-2 PS/SS (Video/Audio PES)
=> demux
-> found PES-ID 0xE0 (MPEG Video)
-> found PES-ID 0xC0 (MPEG Audio)
-> video basics: 480*576 @ 25fps @ 0.6735 (4:3) @ 15000000bps, vbvBuffer 112
dropping useless B-Frames @ GOP#0 / new Timecode 00:00:00.000
dropping gop(sequence) @ orig.PTS 00:00:00.599 / new Timecode 00:00:00.400
GOP#1, Pics expected/count 14/9 ; PTS difference 0ms (should be 0)
dropping useless B-Frames @ GOP#2 / new Timecode 00:00:00.400
video: fr/ct/1p/cg/og/dg 135071/2/0/10971/0/1
videolength: 135071f @ 01:30:02.840
avg. nom. bitrate 2413385bps (min/max: 168400/4892400)
set first sequence_header bitrate to 4892400bps
===> new File: E:\Temp\_umzurechnen\PREMIERE_NOSTALGIE_Das_Gastha us_an_der_Themse_20030903_2214511.mpv
--> MPEG Audio (0xC0)
-> take only first Audio PTS (to sync the starttime
Audio PTS: first packet 00:00:00.331, last packet 00:00:00.331
Video PTS: start 1.GOP 00:00:00.199, end last GOP 01:30:03.719
-> adjusting audio at video-timeline
-> 6 frame(s) (144ms) pre-inserted @ 00:00:00.000
=> src_audio: MPEG-1,Layer2,48000Hz,stereo,192kbps,noCRC @ 00:00:00.144
audio frames: wri/pre/skip/ins/add 225118/6/0/0/0 @ 01:30:02.832 done..
===> new File: E:\Temp\_umzurechnen\PREMIERE_NOSTALGIE_Das_Gastha us_an_der_Themse_20030903_2214511.mp2

summary of created media files:
.Video: 135071 Frames 01:30:02.840 E:\Temp\_umzurechnen\PREMIERE_NOSTALGIE_Das_Gastha us_an_der_Themse_20030903_2214511.mpv
Audio 0: 225118 Frames 01:30:02.832 6/0/0/0 E:\Temp\_umzurechnen\PREMIERE_NOSTALGIE_Das_Gastha us_an_der_Themse_20030903_2214511.mp2
=> 1759559941 bytes written...

Das sieht schon besser aus und scheint auch (fast) immer zu funktionieren. Ich habe allerdings mittlerweile 4 Fälle wo der Ton zum Ende des Film hin unsynchron wird.

Ich kann auch gerne die obige Datei (bzw. Teile davon) zur Verfügung stellen. 1,65 GB per Mail verschicken dürfte allerdings etwas schwierig werden...vielleicht reicht auch ja der Anfang bis hinter das Problem für eine Analyse? Wenn ich das mit Vidomi schneide düfte sich an dem Stream ja eigentlich nichts ändern, oder?

---edit---
Habe es soeben mal ausprobiert und mit Vidomi ein 1,62 MB großes Stück vom Anfang der Datei abgeschnitten: Das Problem bleibt dabei erhalten. Also bräuchte ich bei Interesse eine Mailadresse an die ich das schicken kann.

[dvb.matt]

-> skipped sourceframe(s) @ 00:00:00.336
kommt eigentlich dann, wenn der startPTS des FolgePackets geringer ist als die Anzahl der Syncbytes im aktuellen vorgibt.
u.U. ist diese PTS auch noch geringer als die vorhergehende.

(1) vom fehlerhaften Durchlauf 'biglog' erstellen lassen, zippen, hier posten als Anhang (~20kB)
dabei aber nur die ersten 3..4 GOPs bearbeiten (also zeitiger cut-out)

dann sehen wir weiter.. (fix oder file)

mfg

[TheHorse]

So so, da hammer also noch einen Edgar Wallace-Fan.

[Kamikaze_12]

Moin!

@dvb.matt
So, ich habe mal ein Logfile angehängt und hoffe das es das ist was Du haben wolltest (so gut kenne ich mich mit X und der Materie (noch) nicht aus).

@TheHorse
Naja Fan...aber ab und an sehen meine bessere Hälfte und ich uns die Filme gerne mal wieder an.

[equote:7d433a98b3="Edit Admin"][center:7d433a98b3]Attachment gelöscht und lokal archiviert

Lucike[/center:7d433a98b3]
Attachments-Archiv (http://www.lucike.info/page_archiv_attachments.htm)[/equote:7d433a98b3]

[dvb.matt]

..erhalten
schaun mer mal.

[dvb.matt]

Analyse:
Die von (ggrab war das? ) neu generierten PTS Daten, hier insbes. für Audio, passen nun so überhaupt nicht ins Muster.
X filtert die puren Audiodaten beim Demux in ein temp. File, aber 'verlinkt' diese mit den PTSs und den dafür geltenden Einstiegspunkten zur Suche des entsprechenden Sync-Wortes resp. Frameheaders.

Lt. Log ist ersichtlich, dass das temp.File an Pos.0 bereits mit einem passenden Sync-Wort beginnt, und alle 576bytes (entspr. M1L2-192kbps,48kHz) das nächste -ohne Lücke- folgt.
Als Presentation time (=Start der Ausgabe) für Frame0 auf Pos.0 gilt 29839 (= 0.331s)

AFAIK gelten für Frames die PTSs jeweils für den Startcode/Syncword desselben, denn nur bei diesen kann IMHO die Ausgabe starten/sich synchronisieren (bzw. ein Frame eindeutig lokalisiert werden).

Entsprechend kann bzw. sollte also ein PTS immer den Wert für den unmittelbar folgenden Startcode/Syncword annehmen.
Idealerweise als Inkrement die jeweilige präzise Spieldauer der vorausgegangenen Frames. (hier 24ms = 2160 cycles)
IMHO nicht angezeigt ist dagegen einen PTS zu setzen, der nicht auf einem Syncword, also irgendwo im Frame liegt.

Die hier ermittelten Werte lassen eher darauf schließen, dass die PTSs von der Zählweise der SCR/PCR abgeleitet wurden.
Dise ist IMHO aber bit- und nicht Syncword- orientiert.

Auszug testdatei:

PTS BytePos.
audio pes-packet 0
#0 _29839 #0 _0 /ist frame0
31999 576 /soll frame1
34159 1152 /soll frame2
36319 1728 /soll frame3 (ins folg. Paket überlappend mit 284bytes)

audio pes-packet 1
#1 _37396 #1 _2020 /ist frame4 (= next syncword bei 2304) (PTS 'verlangt' vorzeitige Ausgabe von frame4)
38479 2304 /soll frame4
40639 2880 /soll frame5
42799 3456 /soll frame6
44959 4032 /soll frame7 (ins folg. Paket überlappend mit 568bytes)

audio pes-packet 2
#2 _44954 #2 _4040 /ist frame8 (= next syncword bei 4608) (PTS 'verlangt' vorzeitige Ausgabe von frame8)
47119 4608 /soll frame8
49279 5184 /soll frame9
51439 5760 /soll frame10


Es würde nicht verwundern, wenn manche Spieler dabei nur einen leiernden Ton herausbringen wegen ständigen Resync-Versuchen.
Es nutzt also auch nichts, etwas vorne wegzuschneiden, weil es im ganzen File so ist..

Aus dem Log nicht so richtig erkennbar, scheint die Regeneration der Video-PTS Daten aber ebenso 'chaotisch' zu sein.
Daten aus grab-tools, die die Original-PTS aus dem Kanal übernehmen, sind nachweislich ok und 'standardgemäß'.


Ergebnis:
Es wird dafür keine Anpassung in X geben, weil die 'chaotischen' Ausgangsdaten keiner Regel folgen..
Wie deutlich beim Übergang von packet 1 auf 2 zu sehen ist, verweist die ist-Ausgabezeit/PTS für frame8 mit 44954 noch vor die für frame7 (normal gezählte) soll-Ausgabezeit von 44959. (1 frame versatz bei nur 8..9 frames)
(gewisse Toleranzen sind natürlich 'erlaubt')

Ich kann daher nur abraten, solch' grab-tools zu verwenden...


mfg

[Kamikaze_12]

OK, danke für die Infos!
Dann habe ich nur noch ein Problem:
Was dann zum graben nehmen? Ich habe nun mal einen Linux (Suse 8.2) Rechner als Server laufen und der bietet sich zum streamen an da er sowieso permanent läuft.
Ich habe keine Lust deswegen entweder einen Windows-PC ständig laufenzulassen oder aber statt Linux Windows auf dem Server zu installieren.

Also gesucht wird: Ein vernünftiger (standardgemäßer) Streamingserver für Linux um mit der DBox2 aufnehmen zu können.

Irgendjemand irgendwelche Vorschläge?

Ich kenne für Linux nur a) QBOPSD und b) GGrab.
Mit a) hatte ich bisher NUR Probleme und b) ist (s.o. von Matt) nicht standardgemäß...

[dvb.matt]

Was dann zum graben nehmen?
das weiß ich nicht..
viell. mal hier (http://tuxbox.berlios.de/forum/) gucken.

b) GGrab. ist (s.o. von Matt) nicht standardgemäß...
meine Analyse betrifft ja nur einen klitzekleinen Logausschnitt.
daraus kann man ja nun nicht automatisch das gesamte Verhalten herleiten, insbes. solang niemand meine Aussagen bestätigt oder widerlegt.

[skl]

Also wenn Du was zum streamen suchst, dann schau mal bei http://www.videolan.org/streaming/ vorbei. Das läuft unter mit den dazugehörigen Clienten unter Linux, Windows, OSX, PocketPC, BeOS, BSD, Solaris und QNX und akzeptiert als Quelle so ziemlich alles was ein Video ausgeben kann. Es kann zum Beispiel mpg, vob, mp3, avi, mov, ogg, mp4... streamen. Dabei kann VLS sogar mehrere Quellen gleichzeitig einlesen. Damit kann man auch DVD's streamen.
Was will das Herz mehr?
Gruß
Steffen

[Kamikaze_12]

@dvb.matt
Hi, ich fürchte aber mal das das leider der Fall sein dürfte. Egal welchen Sender ich mit ggrab streame, der effekt wenn es ans demuxen geht ist immer (!) derselbe. Also denke ich doch das es ein grundsätzliches "Problem" bei ggrab ist. Wie gesagt mit dem weiter oben beschriebenen Trick lassen sich die meisten gestreamten Sachen ohne Probleme trotzdem demuxen aber leider nicht alle.
-edit-
Ach so, in dem von Dir genannten Forum bin ich auch vertreten :D , aber zum Thema streamen unter Linux gibt es da nicht allzuviel wie es scheint...
Werde da aber trotz allem nochmal nachfragen.

@skl
Thanx, das mit dem vlc werde ich mir mal ansehen.
-edit-
Habe mich mal umgesehen. Via VLC kann ich zwar Filme vom PC auf die DBox streamen um sie dann am Fernseher sehen zu können aber hier geht es eigentlich um den umgekehrten weg: Aufnehmen der DBox Programme auf dem PC. Un das ist mit VLC nur eingeschränkt bis unmöglich.

[dvb.matt]

was ich meine:
es müßten doch schon andere drauf gestoßen sein, das ggrab Probleme macht, oder eben viell. doch nicht, oder nur in Verbindg. mit X, oder wie auch immer...

mir scheints jedenfalls so, dass häufig die grabtools Probleme bereiten, die den Strom durch eigene Zeitstempel re-synchronisieren. Und das betrifft da nicht nur die dbox...
Die, die das Original übernehmen (evtl. kleine Paketanpassungen) sind 'von Natur aus' unproblematischer.

[soletan]

Hallo,

ich bin gerade über das gleiche Problem gestolpert. ProjectX in der heutigen Version (vor wenigen Stunden geholt) erhalte ich ständig die Meldung "skipped frame @00:00:00.840", bis dahin kam Audio gut, doch es hört genau da auf ... die mp2-Datei ist entsprechend nur 20 KB groß, während meine mpv-Datei 1,5 GB hat.

Ein erster kurzer Kommentar:

Da sich nun aber manche Sender bei mir nicht sauber Streamen liessen hab ich mal die Option von JTG genutzt und mit "ggrab" gestreamt. Tolle Sache, hatte ueber 6 Stunden Daueraufnahme nicht 1 Resynch...

Das ist keine Qualität von ggrab ... in der Doku steht, dass sich ggrab nicht um's Syncen kümmert, sondern dass dem Player überlässt. Nun preist die aktuelle c't Project X als tolerantes "ReSync-Tool", weshalb ich darauf baute, dass ich auch größere Macken damit wegbekomme ... mkdvd und Konsorten versprachen gleich gar nicht, nach Fehlern noch Ton bieten zu können. Das Streamen muss unter Linux laufen, per Neutrino von der dbox in aktueller Version (4.11.2003 alexW), darum geht auch kein JTG oder WinGrab ... letzteres brachte mir in aktueller Version zu viele Resync und Mosaik-Effekte alle 4-5 Sekunden ...


Der ggrab-Stream im original lässt sich hervorragend per Nero ShowTime abspielen, ohne Fehler, Zucken oder Tonausfälle.

Ich habe mich noch nicht durch diesen Thread bis zum Ende gelesen, was ich jetzt mal noch mache ... wollte nur auf die Resync-Frage bei ggrab hinweisen. So, dann bis gleich ...

Soletan

[dvb.matt]

wie schon weiter oben geschrieben, ggrab hat scheints ne komische Eigenart TonPTSe zu schreiben (selbst wenns nichts dabei korrigiert, die Ergebnisse sind IMO schlechter als bei der Aussendung).
das Gegenteil ist hier noch nicht dargelegt worden..

[Derrick]

wie schon weiter oben geschrieben, ggrab hat scheints ne komische Eigenart TonPTSe zu schreiben (selbst wenns nichts dabei korrigiert, die Ergebnisse sind IMO schlechter als bei der Aussendung).
das Gegenteil ist hier noch nicht dargelegt worden..

Hi, meine frage hat mit dem speziellen fall nichts zu tun aber im allgemeinen vielleicht doch.

Ich bin auf der suche nach mehr information über mögliche fehler, die die verschienen streaming tools mit ihren multiplexern machen können. Dass es jeder anders zu machen scheint oder einer von dem anderen abguckt, ist da nicht so verwunderlich aber bei den PCI-kartenprogrammen (habe eine SS2) scheint es eine (für mich noch unverständliche) besonderheit zu geben.

Keins der programme scheint die PCR als clock-referenz vom TS zu verwenden. Es gibt keinen eintrag dafür. Nun könnte man meinen, dass die pcr automatisch aus dem adaptation field vom v_stream genommen wird aber es gibt ja auch fälle, wo die pcr ihren eigenen pid und stream hat. Der ist dann aber nicht bekannt und es funzt trotzdem.

Von @Marfi habe ich die information, dass es im windows durch directX vom audio abeleitet wird (mit den linux tools kenne ich mich nicht aus).

Dazu scheint die beobachtung zu passen, dass alle tools eigene DTS/PTS generieren, die mit den originalwerten aus dem TS nichts gemein haben. Scheint als würden die vom OS des rechners geliefert.

Trotzdem lässt sich das im allgemeinen genauso von z.b. projectX handeln, wie von STBs (hab noch dvb2k mit scsi) nach herkömmlicher art. Mit den üblichen fehlern allerdings, die leider nicht immer gefixt werden, weil die coder die interessanten streams meist nicht empfangen können :(

Der aktuelle anlass waren angebliche ungeregeltheiten auf dem ARD transponder, die den ton in mitleidenschaft zogen. Bis auf dass ich z.b. mit progdvb die störungen hören konnte, ist mir eigentlich nicht viel aufgefallen (höchstens fehlende systemheader u.ä. ;) ). Der TS schien in jedem fall in ordnung gewesen zu sein. Jetzt scheint sendeseitig der alte zustand wiederhergestellt, sodass keiner mehr klagt. Aber es gab wohl auch topf-user, die darüber klagten.