An die Autoren der Grab-Programme

Beitrag von **petgun** » Mittwoch 18. Dezember 2002, 18:10

Hallo,
bei meinen Experimenten den Resyncs auf den Grund zu gehen, bin ich auf das

_Alle_21_Sekunden_einen_Resync_hab_Phaenomen_

gestossen. Wenn ich versuche

SFB1,
EinsExtra,
EinsFestival,
EinsMux,
MDR-Fernsehn,
NDR-Fernsehen,
ORB-Fernesehen,
Suedwest-RP

zu streamen habe ich <Nervensaege:ON> neben den Resyncs wegen zu hoher Datenraten <Nervensage:OFF> periodisch alle 21 Sekunden einen Resync! Was haben diese Sender gemeinsam zu der Tatsache dass sie alle auf dem gleichen Transponder liegen? Imho eine Audio-Technik die euren Multiplexer periodisch aus dem Tritt bringt. Beim starten gibt's bei Ngrab/Wingrab die Meldung:

'... invalid audio frame: not a layer I or layer II'

and thats all! Bei allen anderen Sendern gibt's diese Meldung, und ensprechend dazu auch die periodischen Resyncs, _nicht_

TuxVision geht damit besser um als Ngrab/Wingrab. Bei TuxVision fehlen nur ein zwei Bild-Frames aber der Ton laeuft normal weiter (keine spaetere Asynchronitaet!) waehren bei Wingrab/Ngrab Bild und Ton komplett fehlen. Ich weiss nicht wie sich die Linuxprogramme bei diesen Sendern verhalten.

Aus meiner Sicht ist das ein Schuh der nur Euch wie angegossen passt....den DEV's der BOX-Soft passt er imho nicht.
Ich hoffe Das Ihr Euch das mal anschaut und evtl einen Patch dafuer rausbringt...wer weiss, vielleicht beheben sich damit ja auch andere Fehler....

gruss,
peter

--
Überlegen macht überlegen. (Antoine de Saint-ExupÃ©ry)

Beitrag von **BSE** » Freitag 20. Dezember 2002, 18:10

@petgun
Sorry, aber der von die beschriebene Effekt ist bei mir nichteinmal
ansatzweise nachzuvollziehen (TuxVision).
Laufen auf deinem Rechner evtl. noch andere Prozesse die periodisch
zuschlagen koennten ?

- Bernd

Beitrag von **petgun** » Freitag 20. Dezember 2002, 19:41

hi,
bin froh dass ich eine Antwort bekommen habe!

> Sorry, aber der von die beschriebene Effekt ist bei mir nichteinmal
> ansatzweise nachzuvollziehen (TuxVision).

ok, dann eben nur auf meiner Kiste...merkwuerdig finde ich dann nur die Meldung:

'... invalid audio frame: not a layer I or layer II'

und die Tatsache das _kein_ Programm die separate (Audio PES) *.m2a Datei (und nur die _von diesen Sendern_) als gueltigen Audio-Stream anerkennt, was natuerlich bei einigen Programmen an einem fehlenden Codec auf meiner Kiste liegen koennte...nee, ich bilde mir ein alle bekannten, guten und auch teuren Programmen, die dafuer in Frage kommen, zum testen genommen zu haben...und auch mit Graphedit mir versucht habe was zusammenzubasteln...nach der De/Installation aller moeglichen Audio-Codecs.

@all

hat keiner von Euch den oben beschriebenen Effekt bei den _8_ Sendern ?

@BSE

> Laufen auf deinem Rechner evtl. noch andere Prozesse die periodisch
> zuschlagen koennten ?

wie erwaehnt geht Dein Programm besser damit um...fehlende Video-Frames sind schwerer auszumachen als fehlende AUdio u. Video Frames...aber selbst ohne Lupe ist der Effekt bei mir deutlich zu sehen und bei aller Phantasie kann ich mir nicht vorstellen das dieser Effekt mit der 'Zensur' dieser Sender, irgendetwas mit _selektiven_ periodischen Prozessen auf meiner Kiste zu tun haben soll. Ich bin mir sicher, dass sich der Audio-Stream dieser Sender, von allen anderen Sendern unterscheidet und das eure Programme damit (nur auf meiner Kiste???) nicht fehlerfrei umgehen koennen...gibt's so was wie einen Audio-Stream-Analysator ?

@all

bitte schreibt ob das bei Euch fehlerfrei funktioniert...und wenn ja, welchen Audiocodec ich dafuer installieren muss, damit das bei mir wenigstens mit der Wiedergabe/Weiterverarbeitung klappt...ganz zu schweigen von der Fehlkonfiguration die bei mir zu den Resyns fuehrt....ihr habt _alle_ (bei Linux ??) diese Fehler....bitte ueberzeugt mich vom Gegenteil!!

Danke fuer die Antwort/en,
peter

--
"Zwischen Wahnsinn und Verstand ist oft nur eine duenne Wand"
(Daniel Duesentrieb)

Ich habe ein Analyse-Programm für sowohl MPEG-2 VIDEO als auch MPEG-1 AUDIO I/II/III. Wenn's möglich ist, dann schick mir einfach mal einen solchen fehlerhaften Audio-Stream (2 Min ca. 3 MB) an meine Mail-Adresse. Ich selbst habe auf dem genannten Transponder keine Fehler im Audio gefunden.

Beitrag von **petgun** » Samstag 21. Dezember 2002, 03:32

hi,

>Ich habe ein Analyse-Programm....dann schick mir einfach..

danke! ich schick Dir ein *.m2a File zu und bin gespannt was Dein Programm dazu sagt....was ist das fuer ein Programm?

> Ich selbst habe auf dem genannten Transponder keine Fehler im Audio gefunden.

ob die Fehler haben weiss ich nicht, sie unterscheiden (andere Samplingfrequenz ?) sich imho nur von dem Rest der Audiostreams und fuehren auf meiner Kiste zu den beschriebenen Fehlern besonders bei Ngrab und Wingrab mit periodischen Resyncs und eben zu der Startmeldung:'... invalid audio frame: not a layer I or layer II' bei der Ausgabe als program stream file. Also irgendwas gefaellt den Programmen jedenfalls nicht an dem Format.

gruss,
peter

--
Es gibt genau 3 Arten von Mathematikern:
Solche, die zaehlen koennen, und solche,
die es nicht koennen.

@petgun,
die Liste der oben genannten Programme haben alle eine Besonderheit: Es sind die einzigen, (die ich bisher gesehen hab) die Audio-Frame-Grenzen nicht auf PES-Paket-Grenzen haben!

Grabben kann ich die allerdings problemlos...

Beitrag von **petgun** » Samstag 21. Dezember 2002, 14:59

hi,
danke fuer den Hinweis:

> die Liste der oben genannten Programme haben alle eine Besonderheit: Es sind die
> einzigen, (die ich bisher gesehen hab) die Audio-Frame-Grenzen nicht auf
> PES-Paket-Grenzen haben!

ok! Vielleicht kannst Du mal erklaeren was das nach Deiner Meinung fuer ein Bedeutung haben koennte. Hast Du eine Erklaerung dafuer, warum es gerade auf meiner Kiste zu den beschriebenen Effekten fuehrt? So wie ich Eure Programme verstanden habe, braucht ihr zum Muxen keinen speziellen Codec, sondern macht das komplett selbststaendig. Meine Vermutung das es am OS liegen koennte mit der Benutzung spezieller DLL's (zB. quartz.dll) die Ihr vielleicht zur Synchronisation braucht ist zumindest bei XP(SP1) und W2k(SP3) ein Schuss in den Ofen...bei mir ist der Effekt bei beiden Betriebsystemen...Win98 und Linux habe ich noch nicht getestet.
BTW hoert sich so ein *.m2a File nach umbenennen in *.mp3 zB. auf Winamp etwa so an wie die Files die ich mit Deinem GGrab bei allen Sendern bekomme...Gezwitscher mit sehr kurzen nur sehr schwer verstaendlichen Audioframes in chaotischer Reienfolge.

Ich kann mir immer noch nicht vorstellen das dieser Effekt nur auf meine Kiste sein soll, deshalb noch mal die Bitte an evtl. interessierte Mitleser das mal zB. mit einer kurzen Sequenz von EinsMux unter WingrabZ/Ngrab zu testen: Bei der Ausgabe als gemuxtes pes-streamfile gibt's bei mir die beschriebenen periodischen Resyncs und bei getrennter Ausgabe, kann kein mir bekanntes zum muxen geeignetes Programm, mit dem Audiofile was anfangen.

Vielleicht ergibt die Analyse von Hopper2304 ja noch mehr Aufschluesse.

gruss,
peter

--
X-No-Sig: no

Beitrag von **petgun** » Sonntag 22. Dezember 2002, 13:50

hi,
von ewigen Zweifeln geplagt habe ich mir einen anderen Rechner ausgeliehen:
AMDK6 500Mhz mit Windows ME und 3com 10/100 Netzwerkkarte.
Nur WingrabZ installiert und versucht EinsMux zu streamen mit dem _gleichen_ Ergebnis wie oben beschrieben....eine persoenliche Box, OS, Netz-'Zensur' bezogen auf diese 8 Sender kann ich mir einfach nicht vorstellen ;-)

Ich verstehe es nicht mehr und bin eigentlich wieder nur sehr enttaeuscht von der selektiven Wahrnehmung und dem mangelnden Interesse der meisten _User_ hier....nach dem Motto 'was interessiern mich die 8 Sender, von denen streame ich sowieso nicht'

Ausdrucklich nehme ich die DEV's von dieser Kritik aus: BSE und Gandalfx haben zumindest versucht den Effekt nachzustellen (_danke dafuer_) und Elminster ist zZt. in Australien. Unter TuxVision ist der Effekt schwerer festzustellen und ich nehme an das Gandalfx den Test unter Linux mit seinem GGrab gemacht hat....und da gibt's den Effekt, wie auch 'tonsel' geschrieben hat, anscheinend nicht.

@User

die DEV's koennen fuer uns die Software nicht verbessern, wenn wir nicht versuchen moeglichst exakte Fakten und Fehlerbeschreibungen dazu beizutragen...und der Fehler eines einzelnen Users (so sieht das hier im Moment aus, bin mir aber sehr sicher das ich nicht alleine davon betroffen bin) wird dabei natuerlich (und fuer mich absolut verstaendlich) erst mal abgelegt und hat keine hohe Prioritaet. Deshalb nochmal die Bitte an Euch alle, einen kleinen nur 5 Minuten dauerenden Streamtest mit zB. EinsMUX und wingrab/Ngrab zu machen und das Ergebnis hier zu posten. Mir geht's wirklich nicht um eine Bestaetigung meiner Experimente, hole sofort den 'Systemoptimierungsschraubendreher' wieder aus der Schublade _und bin still_ wenn hier nur einer von Euch (bitte mal eine genaue Konfigurationsbeschreibung posten) schreibt, dass er den Effekt unter _Windows und Ngrab/Wingrabz_ nicht hat.

gruss,
peter

--
Man kann von niemand mehr erwarten als man ihm
gibt. Auch vom Leben nicht. [Curt Goetz]

Also petgun, hier die von Dir erhoffte Antwort.

Ich habe die Audio-Daten zuerst mal analysiert und mich dann doch intensiver mit EinsMuxx geschäftigt um das ist dabei herausgekommen.

Wie Gandalfx schon gesagt hat, sind die Sender der ARD die (auch nach meinen Infos) einzigen Sender, die die Audio-Pakete über PES-Grenzen senden. Ist laut Spezifikation erlaubt. Nun, was heisst das? Wir Du vielleicht weisst bestehen MPEG-1 Layer II Audio-Dateien aus Paketen mit einer Grösse von 576 Bytes (bei 192 kbps). Diese werden in grösseren Paketen, den PES-Paketen gespeichert, die eine Grösse bis zu knapp 64 KB haben können, aber auch 1 Byte lang sein können. In diesem werden die Audio-Pakete abgelegt. Alle anderen Sender legen so z.B. 8 Audio-Frames in ein PES-Paket ab und schiessen es anschliessend. Das ARD Playout-Center allerdings schliesst ein PES-Paket mitten in einem Audio-Frame und setzt dieses im nächsten PES-Paket direkt fort. Wenn WinGrabZ nun an einer Stelle mit dem streamen beginnt, landet es zuerst auf einem "halben" Audio-Paket, deshalb die Meldung "invalid audio-frame".

Elminster müsste also das ARD-Feature integrieren und beim ersten Audio-Paket einfach die Warnung unterdrücken.

Das weitere Problem mit den Resyncs kann ich nun auch bestätigen. Obwohl der Channel gerade mal nur 2 MBit/s pro Sekunde übertreten fehlen unglaublich viele Daten. Ich streame Direkt mit 6 MBit/s fehlerfrei, also ist das ein Problem. Das liegt definitiv nicht am Netzwerk, oder an Computer. Es scheint also ein Problem bei der dbox zu sein. Entweder ist die Frequenz stark beeinträchtigt oder aber, meine alte Vermutung, die Bitrate ist zu niedrig. Ich glaubte mal früher, dass je niedriger die Bitrate wird, desto mehr Fehler treten auf. Eine schlechte Implementation des Streaming-Moduls streampes auf Seiten der dbox. Allerdings hatte sich das dann im Laufe der Zeit gebessert.

Ich werde mal dem Problem weiter nachgehen und von Sendern wie Classica aufnehmen. Die haben, glaub ich, die kleinste Bitrate (320x576)

Beitrag von **petgun** » Montag 23. Dezember 2002, 11:25

hi,

@Hopper2304

vielen Dank fuer Deine Antwort, die genaue Erklaerung und die Muehe die Du Dir gemacht hast!

> Elminster müsste also das ARD-Feature integrieren und beim ersten Audio-Paket
> einfach die Warnung unterdrücken.

ich hoffe er liest hier noch mit und schaut sich Deine Analyse mal an wenn er aus Australien zurueck ist....ich pers. kann auch etwas laenger auf einen ARD-Patchwarten, jetzt, da ich dank Deiner Arbeit weiss, dass ich mir das alles nicht nur eingebildet habe ;-) Traurig finde ich nur, das es wahrscheinlich kaum ein User registrieren wird wenn der Patch kommt, genau so wie es jetzt kaum einer registriert hat das es diese Fehler gibt...Du und ich werden es registrieren und uns dafuer bedanken!

> Das weitere Problem mit den Resyncs kann ich nun auch bestätigen....

you made my day!!

> Obwohl der Channel gerade mal nur 2 MBit/s pro Sekunde übertreten fehlen
> unglaublich viele Daten....Entweder ist die Frequenz stark beeinträchtigt oder
> aber, meine alte Vermutung, die Bitrate ist zu niedrig..

?? das wirklich Daten fehlen haette ich allerdings nicht gedacht....hoeren kann ich das jedenfalls nicht wenn ich Audio/Video getrennt aufnehme. Bei den vermurksten, schon gemuxten Aufnahmen mit den Resyncs, ist das klar...Audio und Video-Frames landen beim Muxen im Papierkorb

Einen Zusammenhang zwischen zu niedrigen Bitraten und Uebertragungsfehlern habe ich bisher allerdings noch nicht festgestellt....werde ich in Zukunft auch mal drauf achten.

Kannst Du mir/uns (vielleicht lesen hier ja doch noch mehr interessierte User mit) noch verraten mit welchem Programm solche Analysen moeglich sind? Ich habe mir einen Wolf gesucht und bisher nix brauchbares gefunden.

Nochmals vielen Dank,
peter

--
Gib mir die Gelassenheit, Dinge hinzunehmen, die ich nicht ändern kann; gib mir den Mut, Dinge zu ändern, die ich ändern kann, und gib mir die Weisheit, das eine vom anderen zu unterscheiden. (Friedrich Christoph Oetinger)

@alle

Aufgrund der vielen Nachfragen: Analysiert habe ich die Audio- und Videodaten mit einer Erweitung von VirtualDub, die ich selbst geschrieben habe. So kann ich ENDLICH Mpeg-2 Dateien in VirtualDub einlesen und sauber schneiden, framegenau schneiden. Leider ist die Schnittstelle noch nicht perfekt, wird also bis zur public release noch 2-3 Monate dauern.

Beitrag von **petgun** » Montag 23. Dezember 2002, 15:44

hi,

> Analysiert habe ich die Audio- und Videodaten mit einer Erweitung von
> VirtualDub, die ich selbst geschrieben habe. So kann ich ENDLICH Mpeg-2
> Dateien in VirtualDub einlesen und sauber schneiden, framegenau schneiden

@all

bitte lasst Euch diesen Satz auf der Zunge zergehen und erkennt was das fuer uns bedeutet:

Endlich das Programm wonach viele von uns bisher vergeblich gesucht haben und wer VirtualDub kennt, wird noch mehr begeistert ueber diesen Zusatz von Hopper2304 sein. Ich pers. hoere jedenfalls auf zu suchen und freue mich jetzt schon auf die Erweiterung.

Vielen Dank fuer diese Ankuendigung,
peter

--
Ich hasse diesen Römer namens Status Quo!
[Ray Bradbury: Fahrenheit 451]

Habe alles gründlich gelesen und habe endlich jemanden gefunden, der wohl auch das Problem hat. Da ich nicht so ein Incider bin, konnte ich nur erkennen, das ich wohl warten muss, bis das Problem seitens der Dev's gelöst ist.
Das Erste läuft aber einwandfrei.

Warum laufen Tuxvision und DBoxtimer bei mir nicht mehr??

Gruss

@petgun

So kann ich ENDLICH Mpeg-2
> Dateien in VirtualDub einlesen und sauber schneiden, framegenau schneiden

Naja, geht doch mit DVD2AVI & VFAPI schon recht lange und auf nem schnellen Rechner auch sehr sehr flott.

C'ya,

Christian

Beitrag von **petgun** » Mittwoch 1. Januar 2003, 22:46

Hi,

@Computerhenne2

>und habe endlich jemanden gefunden, der wohl auch das Problem hat..

wir haben alle das Problem und noch schoener ist es wenn das Problem dann auch von den DEV's bestaetigt wird....dann gehe ich naemlich davon aus, das sie sich auch irgendwann darum kuemmern. Um die Prioritaet kannst Du Dich kuemmern ;-)
Fuer mich ist der Fall damit erledigt...und ich bin sicher das sich dieses Problem noch dieses Jahr in bester Helmut Kohl Problem-Aussitzmanier von alleine loest:

Hinweis an die DEV's:
Die ARD soll in diesem Jahr (Maerz) ein neues 'PlayoutCenter' bekommen wo es diese Besonderheit mit dem Stream angeblich nicht mehr gibt! Also koennt Ihr Euch um wichtigers kuemmern...vielleicht um UDP-Unterstuetzung..;-)

>Das Erste läuft aber einwandfrei

stand auch nicht auf der Liste ;-)

@Christian

> geht doch mit DVD2AVI & VFAPI schon recht lange und auf nem
> schnellen Rechner auch sehr sehr flott

..ja, aber leider fehlt immer noch ein MPG-Copycode und 'recht flott' ist relativ..dauert mir pers. alles viel zu lange und ich moechte sehr gerne das _Orginal_ auf DVD brennen. VDubMod ist auch noch Alpha aber ich hoffe da wird noch einiges kommen.

Gruss,
peter

--
Gestern standen wir kurz vor dem Abgrund, heute sind wir schon einen
Schritt weiter! [Walter Ulbricht]

@petgun
Was willst du denn? Wenn es dir nur um das einlesen von MPEG2 in VirtualDub geht, dann geht das bereits jetzt problemlos...
Was du mit MPG-Copycode und VDubMod meinst ist mir rätselhaft, aber auch irrelevant, da die Lösung mit DVD2AVI nicht nur universeller, sondern sicherlich auch schneller ist... als eine jetzige komplette Neuentwicklung.

Bzgl. Original auf DVD brennen, siehe auch den anderen Thread hier im Forum. Nahezu alle Streams von der DBOX sind nicht DVD-konform (und die wenigen müsste man auch noch remuxen/als VOB verpacken); im Original auf DVD brennen geht von daher in 99% aller Fälle nicht.

C'ya,

Christian

DBOX sind nicht DVD-konform

Das stört aber viele Player auch nicht und spielen es trotzdem ab. Man muss nur das Authoring Tool überreden den nicht konformen Stream zu nehmen.

Beitrag von **petgun** » Donnerstag 2. Januar 2003, 00:21

hi,

> Was du mit MPG-Copycode und VDubMod meinst ist mir rätselhaft, aber
> auch irrelevant, da die Lösung mit DVD2AVI nicht nur universeller,
> sondern sicherlich auch schneller ist... als eine jetzige komplette
> Neuentwicklung

als eine Neuentwickling schon...ich schreibe mal wie ich eine _DVD_ erstelle und glaube nicht dass die Methode die Du beschreibst schneller geht:

1.: Mit Ngrab/Wingrab/TuxVision als program-file streamen
2.: Mit Vidomi schneiden und unter Verwendung des _MPG-CopyCode_ abspeichern
3.: Mit PVAstrumento demuxen
4.: Mit IFO-Edit eine DVD erstellen

dabei findet _keine_ Transkodierung statt und die Qualitaet ist genau wie das Orginal. Leider kann Vidomi zZt. nur einen Schnitt bei Verwendung des CopyCodec und kann nicht _framegenau_ schneiden und genau das und noch vieles mehr (auch Schritt 3) wird VDubMod koennen wenn's fertig ist...es fehlt eigentlich nur noch dieser CopyCodec in der jetzigen Version die unter http://virtualdubmod.sourceforge.net/ im Netz zu finden ist....das ist eine Weiterentwickling von VirtualDub um MPG's ohne den Frameserverkram einlesen und bearbeiten zu koennen plus Muxer/Demuxer usw. Schau's Dir doch einfach mal an..

Gruss,
peter

--
Um klar zu sehen, genügt oft schon ein Wechsel der Blickrichtung.
[Antoine de Saint-ExupÃ©ry]

Ah... jetzt versteh' ich worauf du hinaus willst... Du willst ein direktes "schneiden" auf "Dateiebene"...
Aber framegenau müsste doch aufgrund der Natur von MPEG gar nicht möglich sein (B- oder P-Frames brauchen doch ein I-Frame...), oder?

Dafür könnte man dann in der Tat ein VirtualDub mit nativen MPEG2-Support gebrauchen...

dabei findet _keine_ Transkodierung statt

Wenn man standard-konform bleiben will, aber nur eben bei Streams in 704*576 oder 720*576... denn 480*576 gehört eigentlich nicht zum DVD-Standard.

Ansonsten hab' ich z.Zt. noch keinen DVD-Brenner und muss eh' immer SVCD verwenden und da die meisten Streams dafür scheinbar zu hohe Bitraten haben, muss ich immer transkodieren. Naja, kann ich wenigstens noch ein paar Hinweise und so mit einfügen oder das Senderlogo rausrechnen...

C'ya,

Christian

Beitrag von **PeterB** » Donnerstag 2. Januar 2003, 05:13

Hallo ersteinmal und vor allen Dingen ein gesundes neues Jahr,

zum zweiten, sorry das ich mich jetzt erst wieder melde, aber private Gründe.

petgun, wenn es dir nicht all zu viel ausmacht, würde ich mich gerne mit in diesen Thread, mit einigen weiteren Beobachtungen einklinken. Wenn nicht gewünscht, eben bescheid sagen und ich lösche meinen Beitrag.

So, nachdem mir das alles nicht so plausibel einleuchtete, mit den ReSyncs, bei einigen so gut wie keine, bei anderen von Anfang an bis zum Ende, habe ich getestet bis zum Umfallen, zudem auch mit verschiedenen DVB Empfängern und Rechnern. Mir ist dabei aufgefallen, daß die Kombi dBox2 mit Linux Derivat und "Streamen" die meisten Fehler (sogar ganz üble Fehler) hat/produziert. An der Leistung der dBox2 kann es meines erachtens nicht liegen, da das streamen mit einer dBox1 1a klappt und diese Geräte (von der leistung her) schwächer ist. Die absolut unanfälligste Streamlösung ist die über eine DVB Karte in einem PC, sofern man sich an die Angaben der Hersteller und Infos der "Freaks" hält.

Meine Aussage stütze ich auf folgenden Beobachtungen :

Streams die mit der dBox2 (tuxbox) und z.B. ngrab aufgenommen wurden und keine weiteren ReSyncs, als am Anfang den einen haben, haben eine regelrechte Flut von GOP Errors, also dieses 15 or more Frames in a GOP. Bearbeitet man nun diese Streams, mittels ds.jar, PVAStrumento, TMPGEnc usw. sind die Resultate eher ernüchternd als betrachtungswürdig.
Es wurde häufig gesagt, daß besonders premiere absichtlich diese "Fehler" einbringt, als Copyschutz bis hin zur Theorie, daß es an der Fähigkeit der Mitarbeiter mangelt.
Komischerweise haben dBox1 oder DVB PC Karten Streams nur wenige dieser GOP Fehler, gleiche Sendung, am gleichen Signal abgegriffen und jeweils mit identischen Rechner gestreamt. Auch wenn die Geräte an den PCs getauscht wurden, waren nur wieder die dBox2 Streams so gravierend Fehlerhaft.

Durch drei sehr nette Menschen bin ich an 3 DVDs mit Teilstreams gekommen, die einmal die Roversion, bevor er durch den Hardware Realtimeencoder gejagt wurde, dann kurz bevor er an den Uplink geschickt wird, dann wenn er als Downlinkfile, vor der Einspeisung in den Verteiler kommt und nochmals bevor, nachdem er durch einen weiteren Verteiler kommt - bekommen. Und siehe da, die GOP "Fehler" waren erst nach dem Downlink, aber sehr gering vorhanden, so wie sie eben in der Anzahl auch in etwa mit den dBox1 und DVB PC Karten Streams über einstimmen.

Aufmerksam auf diese Sache bin ich durch folgende Beobachtung geworden - ich habe mir in diversen Cut/Edit Programmen einen dBox2 Stream Step for Step angeguckt und staunte nicht schlecht, als das Bild (also der Film) plötzlich ein kleines Stück nach hinten hopste um dann normal ein Stückchen weiter zu laufen und zuletzt einen großes Stück nach vor hüpfte. Und genau an diesen Stellen wird auf der GOP Fehler gemeldet. Inkl. dem "knacken" im Audio. Seltsamerweise reagieren einige dBox2 bei solchen GOP Stellen etwas heikel - manche machen dann dicht und es kommt beim Streamingprogramm zu einem ReSync - weil an diesen Stellen auch ein extremer Peak in den Datenraten ist, der aber Real gar nicht vorhanden ist. So als ob ein Zähler oder so "Amok läuft".
Wenn es hingegen ein Stream mit niedriger Auflösung, wenig Bewegung und so ist, kommt es nicht Zwangsläufig zum ReSync.

Wie gesagt, es sind meine Beobachtungen und ich kann es nicht beurteilen, da ich nur die bÃsherigen Endresultate erlebe. Nur meinte ein Bekannter von mir, der in der Branche arbeitet, es wäre eine Lösung, wenn es z.B. ein reines Grundimage und Erweiterungsimage nur fürs streamen geben würde. Also keine Spiele, Schnickschnack,verschiedne GUIs und so on. Einfach Fernsehen und Streamingserver - mehr nicht.
Ansonsten, so seine Ansicht, auf dBox1 mit vernüftigen Image und SCSI Anschluß umsteigen, falls nicht das Geld für eine reine DVB PC Lösung da ist.

Es soll sich nun auch kein Entwickler angepinkelt fühlen, da die Grundidee der tuxbox eh eine andere war und jenes ganze jetzt hier eher ein Selbstläufer ist

. Nur finde ich es auch etwas seltsam, daß viele Entwickler sich zu Halbgöttern erhoben haben, weil sie nun einmal etwas von Linux und so verstehen und keine Kritik, Anregungen, Vorschläge "ertragen" dulden. User die sehr viele Probleme haben, werden ersteinmal als Dumm/Noob hingestellt - nur die Fehler sind ja da, selbst bei den alten Hasen vom Fach.

Würde mich freuen wenn irgendwann einmal die Ursache für diese ganzen Streamingprobs gefunden werden

.

Und bitte macht nun kein Flamewar oder wieder "oh der hat es gewagt, den hauen wir nun platt"

.

Beitrag von **Tschups** » Donnerstag 2. Januar 2003, 06:09

@PeterB

....danke für diesen Beitrag. !
Du hast genau das angesprochen was ich denke und teilweise auch schon schrieb.
Ich kann Dir nur zustimmen

CU Tschups

Beitrag von **petgun** » Donnerstag 2. Januar 2003, 12:22

Hi all,

zur Analyse der Streams nehme ich den 'MoonlightMpeg Stream Explorer' (http://www.moonlight.co.il) mit dem ich diese 'Huepferei' auch sehr gut beobachten konnte...inklusive dem Effekt:

> Wenn es hingegen ein Stream mit niedriger Auflösung, wenig Bewegung
> und so ist, kommt es nicht Zwangsläufig zum ReSync.

Mitlerweile denke ich allerdings das uns ein spezielles optimized StreamImage da weniger helfen wird...eine spezielle Optimierung wird generell wirksam werden...die Spiele und der andere 'Schnickschnack' fallen beim Streamen imho nicht in's Gewicht...was ihr selber mit 'top' waehrend des streamens beobachten koennt. Auf der Box ist noch genuegend Platz und es gibt imho nur zwei kritische Prozesse waehrend des streamens: keventd und streampes....allerdings gibt's nicht immer den Zusammenhang zwischen CPU-Last, hohen Datenraten und Resyncs...das gilt es fuer mich noch genauer zu testen.
Was mich stuzig macht ist die Feststellung von PeterB (schoen das Du wieder da bist):

> Komischerweise haben dBox1 oder DVB PC Karten Streams nur wenige
> dieser GOP Fehler...

da imho ein grosser Teil der Sourcen fuer's streamen von den DVB-PC-Karten Autoren stammt...zum Teil allerdings von Anno Dunnemal. Die DVB-PC-dBox1-Loesungen haben allerding kein Netzwerk dazwischen, womit wir wieder bei dem Thema sind was hier immer wieder zu Kontroversen fuehrt. Imho muss an Beidem optimiert werden, an den stream relevanten Sourcen und auch am Netzwerk. Beim Netzwerk tut sich doch inzwischen was und die Umstellung auf UDP wird sich sicher positiv auswirken...vielleicht schaffen die DEV's ja auch noch FullDuplex...mir gibt immer nur zu denken wenn ich hoere das FTP-Transfer bis zur maximalen Transferrate _kein_ Problem macht, woraus ich schliesse das die Hardware der Box eigentlich nicht das Problem sein kann.

Den 'Halbgoettern in Linux' geht's so wie den anderen Halbgoettern die wir alle kennen....langsam aber sicher kommen sie alle runter von ihrem Olymp und machen es wie Gott...sie werden Mensch! Wir sind nix ohne sie, aber sie sind auch nix ohne uns!

Wir sollten uns weiterhin bemuehen konstruktiv an den Problemen mitzuarbeiten und uns nicht gegenseitig anpinkeln...dann gibt das auch was mit dem fehlerfreien streamen....dieses Jahr ist das Jahr der Box...hat mir mein Orakel verraten...und ich glaube, das wir am Ende dieses Jahres mindestens so gut wie die DVB-PC-Karten und Dbox1 User streamen koennen...und Glaube versetzt Berge ;-)

Das Wort zur Box kam heute von,
peter

--
[Per aspera ad astra!]"Über rauhe Wege hinauf zu den Sternen".
Seneca (4 v.Chr.-65 n. Chr.)

Beitrag von **petgun** » Donnerstag 2. Januar 2003, 17:23

Hi all,
jetzt wird's doch sehr unangenehm mit dem 21-Sekunden Problem und ich bitte die DEV's recht herzlich das Problem doch nicht auszusitzen:

Mein geliebter Referenzsender RTL mit der bisher immer konstanten Datenrate von ca 4500Kbit/sek, produziert jetzt auch diese periodischen Resyncs! Vieleicht haben die das Schrott-Playoutcenter eines der 8-Sender gekauft oder was auch immer. Fest steht das die Datenrate jetzt niedriger und aehnlich dynamisch wie bei vielen anderen Sendern ist und jetzt das 21-Sekunden Problem auftritt..natuerlich mit der bekannten Eingangsfehlermeldung:

16:52:54.831 [AudioProcessor0] invalid audio frame: not a layer I or layer II frame

Jetzt moechte ich nicht in der Haut der DEV's stecken...denn ich befuerchte das der Druck von uns Usern doch ein wenig groesser wird...ich find's allerding auch ziemlich beschissen das ich jetzt RTL nicht mehr fehlerfrei mit Ngrab/Wingrab aufnehmen kann....vielleicht sind's ja ueber Nacht auch noch mehr Sender geworden die sich einen neues Playoutcenter vom Flohmarkt gekauft haben...

gruss,
peter

PS:Ich hoffe hier liest ueberhaupt noch einer mit....
--
Gestern standen wir kurz vor dem Abgrund, heute sind wir schon einen
Schritt weiter! [Walter Ulbricht]

So auch mal wieder hier

@peterb
Der Vergleich mit der DBOX1 ist natürlich ein Vergleich von Äpfeln mit Birnen. Diese hat ja einen SCSI-Port, der direkt am Bus hängt, dessen Bandbreite ist vielleicht 3-4mal so groß wie der des 10MBit-Netzwerkports. Mal abgesehen von wesentlich geringeren Latenzzeiten und so weiter...
Ist also kein wirkliches Argument.

@petgun

dabei findet _keine_ Transkodierung statt und die Qualitaet ist genau wie das Orginal. Leider kann Vidomi zZt. nur einen Schnitt bei Verwendung des CopyCodec und kann nicht _framegenau_ schneiden und genau das und noch vieles mehr (auch Schritt 3) wird VDubMod koennen wenn's fertig ist...

Heute im Zug kam mir die Erleuchtung

Sowas gibt es auch schon und zwar kann das TMPGEnc unter File -> MPEG Tools -> Cut & Merge. Schneiden wie du lustig bist, OHNE Transkodieren, habs jetzt nicht bei gemuxten DBOX-Streams getestet (die einzelnen frisst er nicht), aber bei VCD & SVCD funktionert es problemlos.

C'ya,

Christian

Beitrag von **Tschups** » Freitag 3. Januar 2003, 05:10

Hi all

Ich kann Petgun's entdeckung nur bestätigen.

RTL lief bis dato problemlos. Sei gester oder vorgestern, hat RTL auch diese periodische Sync's

Schade ich hatte gedacht mit der neuen Ngrab Version sind die Sync's eingeschränt worden, und jetzt das.

Geht das schon wieder los?

CU Tschups