Grüne Klötze - Ursachen und Abhilfe (bish. Hoffn. auf Hilfe)

[RchdSchmidt]

Ich habe aus dem Thema "Grüne Klötze" in der Rubrik DBV-Software gelesen, daß manche DVD-Spieler grüne Klötzchen bei Bewegung zeigen, wenn der Sender, aus dem die Filme aufgenommen wurden, als VBV-Puffergröße 91 angibt. Bei VPV-Puffergröße 112 soll der Fehler nicht vorkommen.
Auch von meinen Aufnahmen haben viele VBV 91, und ich möchte meine DVDs auch dann noch spielen können, wenn ich mir mal einen neuen DVD-Spieler kaufen muß, auch wenn mein jetziger Spieler keine Klötze bringt.
Deshalb habe ich ein Programm geschrieben, das in den VOB-Dateien in den Sequenzköpfen jeder GOP die VBV-Größe durch 112 ersetzt, wenn für sie vorher 91 drinsteht.
Ich kann aber nicht nachprüfen, ob die Klötze damit wirklich verschwinden, weil mein DVD-Spieler ja keine bringt. Deshalb möchte ich einen Kollegen mit einem DVD-Spieler mit Klötzen bitten, eine so bearbeitete DVD auf seinem Spieler auszuprobieren und mir zu sagen, ob der Fehler damit weg ist. Leider scheint dieser Kollege noch krank zu sein, und so kann das noch einige Zeit dauern.
Wenn sich zeigen sollte, daß mit dem Programm die grünen Klötze tatsächlich verschwinden, möchte ich es meinen Lieblingsforen für ihren Downloadbereich anbieten.
Falls jemand das Problem unter den Nägeln brennt und er nicht so lange warten möchte, oder wenn mir jemand, der einen DVD-Spieler mit Klötzchenbildung hat, mit einem Test helfen möchte, so würde ich versuchen, ihm per Email das Programm zuzuschicken. Allerdings vorerst nur das compilierte Programm, noch keine Quellen.
Das Programm ist nur ein Kommandozeilenprogramm, aber es läßt sich in Windows leicht anwenden, indem man die Vob-Datei oder den Ordner mit Vobdateien auf das Programm-Icon zieht.
Meine Email-Adresse steht im Profil. Ich hoffe, nicht nur ich kann sie lesen.
Richard Schmidt.

[RchdSchmidt]

Inzwischen habe ich per Email eine Antwort bekommen. Der Autor macht mich darauf aufmerksam, daß auch ProjectX die VBV-Puffergröße einstellen kann. Ich habe mir daraufhin die Beschreibung angeschaut und gesehen, daß es unter Vidio2 einen entsprechenden Punkt gibt. Damit dürfte mein Programm überflüssig sein.

Hat schon jemand eine Datei, die VBV-Größe 91 enthält, mit ProjectX auf 112 umgesetzt und ausprobiert, ob damit die grünen Klötze auch wirklich verschwinden?

Richard Schmidt.

[kstroe]

Hallo,
genau das ist das Problem, egal wie nun der VBV steht, die SA Player
mit den grünen Artefakten (Klötzchen) verhalten sich immer gleich ---
nämlich ein Bild mit grünen Klötzchen anzeigen.
Erst beim Neuencodieren mit TMPG z.B. sind die Artefakte verschwunden.
Dabei kann man sogar die VBV-Größe manuell auf 91 stellen (nicht ratsam
da Bildqualität bei schnellen Bewegungen sehr schlecht) und die grünen Klötzchen sind weg.

[RchdSchmidt]

Vielen Dank für die Information.
Dann bleibt aber immer noch die Hoffnung, daß ProjectX die Puffergröße woanders einstellt und es mit meinem Programm vielleicht doch funktioniert.
Ich versuche es jedenfalls weiter.
Richard Schmidt.

[EmZwei]

Vielen Dank für den Hinweis auf die Einstellung bei Project X.

Ich habe gestern einen Film mit Project X neu bearbeitet, der vorher grüne Klötzchen enthielt und dabei die die VBV-Größe auf 112 ändern lassen. Was soll ich sagen - die Klötzchen sind weg!

Vielleicht noch am Rande: Ich verwende einen Mustek DVD-Player.

Schöne Grüße,
Matthias Greiner

[kstroe]

Hallo,

interessant, da dies bei mir scheinbar nicht funktioniert mit projektx
der vbv ändernt sich zwar aber das Resultat ist dasselbe :evil: auf
SA Player Toshiba SD230

Habe jetzt festgestellt dass die GOP - Struktur bei ARD nicht DVD konform ist, gibt jedenfalls PVAStrum. aus. (mehr als 15 Frames pro
GOP)

[dvb.matt]

Die (hier besprochene) vbv_size (global für Sequence) kann nicht unabhängig vom vbv_delay (je Frame), der Bitrate der Sequence usw. betrachtet werden.

Wichtig ist, dass der reservierte Speicher(buffer) alle notwendigen Macroblöcke (Klötzchen) zum Dekodieren je GOP (also einer temporalen Sequence) zusammenhalten kann.

Es kann praktisch vorkommen, dass ein Makroblock vom ersten I-Frame bis ins letzte Frame 'durchkopiert' werden kann (max. 1024 Frames je GOP, einige haben schon bei nur 15..30 Probs. ;) )

Wenn 'grüne Klötzchen' erscheinen, wurden halt 'Klötzchen' im Buffer tlw. ersetzt.

Man kann weiters so z.B. mit o.g. Werten experiementiern (im Original belassen, fixe höhere Werte etc.)

[Pennywize]

ich habe dasselbe problem, bei rtl sendern. mein sa ist ein seg-333

ich habe schmidt eine mail geschickt mal sehen ob es geht mit deinem programm.

mit projekt x komm ich leider nicht zurecht.


matt ich muss zugeben, so ganz verstehe ich deine antwort nicht.

interessant ist vielleicht auch, weder bei einem recoden mit dvdshrink noch davideo gehen die grünen klötzchen weg. tmpgenc stürzt bei mir ab jemand eine andere idee welches proggie man nehmen kann zum recoden??

gruß
penny

[RchdSchmidt]

Erst mal vielen Dank für die vielen Antworten.
Meinen Postkorb habe ich soeben angeschaut, und wenn ich heimkomme mein Programm per Email versenden. Bis gestern früh um 7 Uhr hatte ich nur eine Email, und an deren Autor habe ich das Programm weitergegeben. Er hat mir eine neue Email geschrieben, daß bei seinem Toshiba-DVD-Spieler die grünen Klötze auch nach dem Ändern der VBV-Größe noch kommen. Ich glaube aber weniger, daß es an der GOP-Größe liegt, denn ich bekomme beim Umsetzen mit PVAStrumento auch bei Sendern, die mit VBV-Größe 112 senden, jede Menge GOPs mit mehr als 15 Bildern gemeldet, aber bei diesen Sendern sollen ja die grünen Klötze gar nicht auftreten.
Übrigens kommt es mir so vor, daß ProjectX auch den VBV-Delay ändern kann. Ich würde ja gern selber mit verschiedenen Werten ein bißchen rumprobieren, aber ich kann das Ergebnis nicht überprüfen, weil mein DVD-Spieler sich hartnäckig weigert, die grünen Klötze zu bringen.

Ich werde trotzdem noch nicht aufgeben.

Richard Schmidt.

-----------------------------------

Hier ist die Antwort, die ich vom ersten, der mein Programm ausprobiert hat, per Email bekommen habe:

vielen Dank für die Unterstützung, das Programm macht das was es soll....

aber der Erfolg blieb leider aus. Wie ich richtig vermutet habe kann man die Größe des VBV nicht so ohne weiteres
ändern sondern man muß den VBV-Delay und die BPS-Rate mit einbeziehen, siehe auch dvb-matts Antwort im Lucike
Forum.
Scheinbar mag der Toshiba wirklich nicht solange GOPS, sodaß er den Buffer immer überschreibt, oder die Daten im Buffer sind noch
gar nicht vorhanden und er zeigt sie schon an -- eben unvollständig.
Beim Mustek User scheints ja zumindest zu funktionieren, lt. Forum.

[RchdSchmidt]

Antwort an pennywize:
Neucodieren hat große Nachteile:
1.) es dauert unheimlich lang,
2.) die Bildqualität wird schlechter.

Aber wenn ich wirklich etwas neucodieren will, nehme ich dazu BBmpeg. In diesem Paket gibt es das Programm AVI2MPEG2. Dieses kann zwar nur MPEG1 lesen, aber seit ich auf meinem Rechner den kostenlosen Licos-Decoder installiert habe, kann BBmpeg auch MPEG2 direkt verarbeiten.

Die Bildqualität von BBmpeg ist aber nicht so gut wie bei TmpgEnc.

Richard Schmidt.

[RchdSchmidt]

Ich habe wieder mal ein bißchen nachgedacht. Ich glaube nicht, daß mit dem Ändern der VBV-Puffergröße das Problem wirklich gelöst wird. Es könnte aber sein, daß der Mustek tatsächlich mit der Puffergröße nicht klarkommt (vielleicht rundet er tatsächlich aufs Vielfache von 16 ab) und daß das mit dem Problem der anderen überhaupt nichts zu tun hat.

Ich habe inzwischen mit VobEdit die GOP-Header vonVob-Dateien aus Sendern mit VBV 91 mit solchen aus Sendern mit VBV 112 verglichen. Da ist mir aufgefallen, daß der VBV-Delay bei beiden gleich ist. Deshalb glaube ich nicht, daß der VBV-Delay das Problem ist. Mir ist aber auch noch etwas Anderes aufgefallen:
Bei den Vobdateien mit VBV 91 kommt nach der Sequence Header Extension (oder so ähnlich) noch eine Sequence_Display_Extension, aber bei denen mit VBV 112 nicht. Wer weiß, vielleicht haben wir mit der VBV-Größe nur das falsche Ende einer heißen Spur verfolgt, und es ist gar nicht die VBV-Größe, sondern diese zusätzliche Sequence_Display_Extension.
Übrigens waren die Sender mit VBV 91 ARD und Super RTL, und die mit VBV 112 waren Kinderkanal, Tele5 und Boomerang. Ich werde dies noch mit anderen Sendern verfolgen.

Für mich stellt sich jetzt erst mal die Frage, ob man die Sequence_Display_Extension einfach rausschmeißen kann, und wie man das machen kann: Ob man dann noch andere Längen und Startadressen ändern muß, ob man am Ende des Pakets Nullbytes einflicken soll, oder ob man für den Sequence_Display_Extension-Block einfach etwas Anderes Gleichlanges einsetzen soll, das keine Bedeutung hat.

Gerade habe ich ReStream entdeckt, das da möglicherweise helfen kann.

Richard Schmidt.

[kstroe]

Hallo,
diesen Überlegung hatte ich auch schon, mit restream :idea: einfach
die SDE zu löschen. Hat aber nichts gebracht. :evil:

Scheinbar ist der DVB Stream von besagten Sendern in der GOP-Struktur
für manche SA-Player nicht mehr dekodierbar bzw. entstehen Überläufe
oder Synch-Probleme beim Dekodieren, sodaß sich das in der Anzeige
auswirkt (grüne Klötzchen)

Bei weiteren Möglichkeiten der Ursache bin ich noch auf Gemeinsamkeiten
gestoßen: alle Player mit dem Problem (meistens Toshiba aber auch Samsung) haben Zoran Vaddis Dekoder eingebaut. Der scheint
sehr DVD-konform zu sein -- will sagen der ist scheinbar nicht so "gutmütig" wie andere SA-Player.

[dvb.matt]

was passiert, wenn ihr die Bitrate (z.B. bei ARD/RTL) auf z.B. fixe 8Mbps für alle GOPs setzt, incl. VBV buffer auf '112' und vbv_delay '0xFFFF' ... , alles vor dem Muxen.

insbes. wenn die Fehlstellen 'willkürlich' übers ganze Bild verteilt zu sein scheinen.

vergleichsweise kann man mit der Einzelbildschaltung im SA und PC evtl. eine solche Szene lokalisieren zur weiteren Analyse.

[kstroe]

Hallo,
habe gerade eine DVD mit den vorgeschlagenen Einstellungen
gebrannt. << bitrate value in first sequence >> habe ich einmal auf
"keep original" und einmal auf <=9,8Mbps gesetzt.
An den Einstellungen habe ich auch schon probiert. Das Ergebnis ist
immer das gleiche egal was dort für Einstellungen
gemacht werden .... grüne Artefakte (Klötzchenbildung)

Die Fehlstellen sind dabei, so meine ich, immer gleich und zwar immer
dort wo viel Bewegung im Bild ist, bei Szenenwechsel, also kompletter
Neuaufbau des Bildes, ist alles grün, auch wenn man das Bild dann einfriert - Standbild.
Am PC ist davon nichts zu sehen (Powerdvd SofDVD Player) :?:

hier noch ein Auszug aus MPG2schnitt vom Sequenzheader:
mit 8Mbps Einstellungen und vbv= "112" vbv-delay=max

Sequenzheader:
Bildbreite: 720
Bildhöhe: 576
Seitenverhältnis: 3/4
Framerate: 25 Bilder/sek.
Bitrate: 8 MBit/sek.
VBV-Puffer: 224 KByte
Profil/Level: Main/Main
Farbformat: 4:2:0
Low Delay: Nein
------------------------------------
Bildheader:
Bildtyp: I-Frame
DC Prezision: 8
Bild Struktur: Frame
oberstes Bild zuerst: Ja
------------------------------------
Audioinformationen
Mpeg 1 Layer 2
Bitrate: 192 KBit/sek
Samplerate: 48000 Hz
Channel Mode: Stereo

[kstroe]

Hallo,

der Vollständigkeithalber hier auch noch die quickinfo von projectx
(gehört vielleicht auch ins projectx-forum) also nur zur Info

=> File 0: K:\test.rec (130426880 bytes)

=> File is DVB/MPEG-2 TS (Video/Audio/TTX PES)

=> demux

-> SID 0x6DCA

-> PMT 0x64 refer to these Video/Audio/Text related PIDs :

< 0x65 0x66 0x68 >

!> missing sync. byte @ 0

!> found sync. byte @ 1692

ok> PID 0x68 has PES-ID 0xBD (private stream 1) (TTX) (0x1A70 #28)

ok> PID 0x65 has PES-ID 0xE4 (MPEG Video) (0x6268 #126)

ok> PID 0x66 has PES-ID 0xC0 (MPEG Audio) (0xA24C #213)

--> PID 0x0 (PAT or others) (0x138D8 #418) -> ignored

--> PID 0x64 (PMT) (0x185F4 #523) -> ignored

-> video basics: 720*576 @ 25fps @ 0.6735 (4:3) @ 1490800bps, vbvBuffer 91

-> starting export of video data @ GOP#0

!> dropping useless B-Frames @ GOP#0 / new Timecode 00:00:00.000

packs: 27758 4% 5242944

video: fr/ct/1p/cg/og/dg 250/1/0/21/0/0

videolength: 250f @ 00:00:10.000

avg. nom. bitrate 3369478bps (min/max: 2236000/5043600)

===> new File: F:\videos\schnitt\test.m2v

--> Teletext on PID 0x68 (SubID 0x10)

--> MPEG Audio (0xC0) on PID 0x66

Audio PTS: first packet 10:54:32.377, last packet 10:54:42.865

Video PTS: start 1.GOP 10:54:32.858, end last GOP 10:54:42.858

-> adjusting audio at video-timeline

!> missing syncword @ 0, @ 00:00:00.000

!> found syncword @ 432

=> src_audio: MPEG-1,Layer2,48000Hz,stereo,192kbps,CRC @ 00:00:00.000

audio frames: wri/pre/skip/ins/add 417/0/0/0/0 @ 00:00:10.008 done..

===> new File: F:\videos\schnitt\test.mp2



summary of created media files:

.Video: 250 Frames 00:00:10.000 F:\videos\schnitt\test.m2v

Audio 0: 417 Frames 00:00:10.008 0/0/0/0 F:\videos\schnitt\test.mp2

=> 4452040 bytes written...

--- end of quick info ---

[drogon]

Mir sind im header der streams ein paar unterschiede aufgefallen, zdf geht bei mir einwandfrei, super rtl mit grünen klötzchen.
Ich habe das tool und zwei screenshots angehängt, vielleicht können die profis damit was anfangen.

mfg drogon

[RchdSchmidt]

Vielen Dank für die Versuche und Ergebnisse.
Dann hilft also offenbar weder das Setzen der VBV-Puffergröße noch das Entfernen der Sequence Header Extension.
Ich habe jetzt mal meine alten DVDs (von vor einem halben Jahr) mit VobEdit untersucht und entdeckt, daß bei BR-Alpha, Bayerischem Fernsehen, Hessen-Fernsehen und Südwest-Fernsehen damals die VBV-Größe 112 war. Bei BR-Alpha und Bayerischem Fernsehen war sie zwischendurch auch mal 109 (Anfang Dezember 2003). Vielleicht hat ja jemand, bei dem sich Klötze zeigen, eine ältere gebrannte Aufnahme von einem dieser Sender, dann würde ich ihn bitten, es mal auszuprobieren, ob die Fehler da auch schon gekommen sind.
RBB Berlin hatte schon im Oktober VBV 91.
Ich kann mir nicht vorstellen, daß alle Sender, die mit VBV 112 senden, ganz DVD-konform senden, und alle Sender, die mit VBV 91 senden, ganz unkonform senden. Deshalb glaube ich eher, daß es eine andere Ursache haben muß.
Vielleicht kann ich bei der BR-Zuschauerredaktion etwas erfahren.
Man sollte herausfinden, ob die Fehler zuverlässig immer bei Sendern mit VBV 91 auftreten und zuverlässig nie bei Sendern mit VBV 112 auftreten.
Hat jemand gegenteilige Erfahrungen gemacht?
Richard Schmidt.

[dvb.matt]

@kstroe
Lassen sich die Problemstellen auf Szenen mit nicht-DVD konformen überlangen GOPs zurückführen? (die beim Neukodieren ja IMO nicht erzeugt werden)
evtl. läßt sich präzise die Bildnummer über den Inhalt feststellen, bei dem der Effekt eintritt.

P7 hat diese aber auch und ist wohl aufm Toshi nicht problematisch, oder?

[kstroe]

@dvb.matt

Ich habe die Vermutung, daß es so ist, nur kann ich beim besten Willen
keinen Unterschied zwischen einem Stream von SAT1 (der läuft auf Toshi)
und einem Stream von RTL entdecken.
Nach mpgaz beginnen beide Streams mit einer closed GOP danach
sind die GOP´s bei beiden Streams nicht geschlossen.
(closed GOP-Flag = 0 - Ich hoffe meine Vermutung ist richtig)
Die I-P-B Frames sind in der Anzahl auf 12 oder weniger beschränkt.
Die nächste Struktur bezieht sich aber noch , wenn ich richtig verstanden
habe, auf die vorherige usw. da closed GOP=0 oder :?:

Im Toshi beginnt schon das erste Bild mit Artefakten, als ob er sich
falsch synchronisiert. Es kommt vor, das ein Bild richtig angezeigt wird nur welches das jetzt in der GOP-Struktur ist, dazu fehlt mir die Erfahrung oder Mittel. Also ist es genau umgekehrt: es wird so gut wie kein Bild richtig angezeigt.
Bei schnellem Vorlauf entstehen keine Artefakte.

Mit P7 habe ich noch nicht probiert. Vermute aber das gleiche Resultat
vbv 91 - Klötzchen, vbv 112 - ok auch wenn es damit wahrscheinlich gar nichts zu tun hat.

[RchdSchmidt]

Wenn man herausfinden könnte, bei welchem Bildtyp die Klötzchen auftreten, so könnte das sehr weiterhelfen.
Ob es sich um ein I, P- oder B-Bild läßt sich leicht mit Mpeg2Schnitt feststellen, denn der Bildtyp wird für jedes Bild angezeigt. Auch das Navigieren bildweise, GOP-weise (d.h. zum nächsten / vorigen I-Frame) oder zum nächsten/vorigen Bild, das kein B-Frame ist, ist damit sehr einfach. Allerdings muß man vorher den Film demultiplexen.
Es stimmt. Bei den meisten GOPS gehören die ersten beiden Bilder (B-Frames), die nach dem I-Frame übertragen werden, noch zur alten GOP. Aber auf dem Spieler werden die beiden B-Frames vor dem I-Frame gezeigt. In dieser Reihenfolge werden sie auch von Mpeg2Schnitt wiedergegeben.
Wenn das stimmt, daß alle Sender, die mit VBV 112 senden, keine grünen Klötze bringen, dürften überlange GOPS kein Problem sein, denn auch bei diesen Sendern werden von PVAStrumento jede Menge überlange GOPS gemeldet. Beim Kinderkanal sind es jedenfalls sehr viele.

Für die nächste Zeit habe ich folgendes vor (ich weiß aber nicht, ob ich die richtigen Adressen finde):
1.) Bei SES/Astra fragen, ob die mir sagen können, was sich bei der Umstellung von VBV 112 auf 91 geändert hat.
2.) Beim Hersteller des Zoran-Decoders fragen, ob die eine Ahnung haben, woran das liegen könnte und was man dagegen versuchen könnte.

Andere Ideen habe ich im Moment nicht. Aber vielleicht gelingt es mir, die mit rar komprimierten Informationen von Drogon herunterzuladen und zu dekomprimieren, und vielleicht fällt mir ja dann was auf.

Übrigens, auch wenn ich manchmal recht gescheit daherrede, so habe ich doch von MPEG nicht viel Ahnung. Ich versuche nur, das Wenige, was mir aufgefallen ist, auch anderen mitzuteilen. Es tut mir leid, wenn ich die Hoffnung geweckt habe, daß mit einem kleinen Programm, das die VBV-Größe ändert, das Problem beseitigt ist, aber das habe ich tatsächlich geglaubt.

Richard Schmidt.

Richard Schmidt.

[dvb.matt]

beim besten Willen keinen Unterschied zwischen einem Stream von SAT1 (der läuft auf Toshi) und einem Stream von RTL entdecken
alle RTL-nahen Progs. erfreuen uns mit 704*576, die ÖRs und P7S1media zumeist 720*576.
wichtig für den pimpeligen SA ist hier u.U. die zutreffende Einstellung auch in allen .ifo Dateien. Einige Authoringprogs. schreiben AFAIk immer 720 rein, was für erstgenannte ja eigentlich unpassend wäre..

[kstroe]

Hallo,
habe gerade eine P7-DVD gebrannt, Bitrate lt. X: 15Mbps und vbv=112
und kein Problem für den Toshi.
Film war sogar mit AC3-Stream, der auch kein Problem darstellte.

@RchdSchmidt
an die ARD habe ich schon gemailt - das war im Dezember 2003
- keine Antwort oder vielleicht auch an die falsche Adresse gegangen:
(Ard-digital oder so ähnlich)
Zoran ist ein Halbleiterhersteller der in Sachen Video so ziemlich viel
auf den Markt bringt, nur Datasheets scheint die Firma nicht zu kennen.
Nur ein Product Brief ist vermutlich verfügbar, habe jedenfalls mal den Support angemailt.
Mit Sicherheit spielt da auch noch Sofware mit und da läßt man sich ungern in die Karten schauen. (Zoran.com)

Für die Analyse der Artefakte brauch ich noch etwas Zeit.

[ego]

auch nach meinen Erfahrungen tritt das Grüne-Klötzchen-Problem nur bei bestimmten Sendern (alle RTL-Gruppe - auch Austria und Schweiz! - und alle ARD-Bouquet-Sender) und bei bestimmten stand-alone Playerrn auf (zB dual dvd-r 8900). Ich habe auch schon (fast) alles mögliche probiert: letztlichbeseitigt aber nur komplettes neu-encodieren das Problem. Andere SA-Player (zB Aldi) spielen hingegen alle meine selbstaufgenommenen DVDs ohne jegliche Probleme. Der dual dvd-r 8900 hingegen spielt nur SAT1 Pro7 ZDF 3SAT und natürlich alle Original-DVDs einwandfrei.

Offenbar ist im MPEG-Stream dieser bestimmten Sender irgendetwas nicht ganz konform oder es wird vielleicht ein zusätzliches Signal mitgesendet (?), was dann NUR bei bestimmten SA-Playern zu diesen merkwürdigen Erscheinungen führt.

Ich habs - mangels Fachkenntnisse - mittlerweile aufgegeben nach Lösungen zu suchen (neuer SA-Player gekauft), verfolge aber weiterhin mit Interesse die Diskussion und hoffe, dass es einem "Tüftler" doch noch gelingt, die wahre Ursacheausfindig zu machen UND eine (zeitsparende) Lösung zu entwickeln.

Deshalb viel Glück und Erfolg bei der Suche!

[RchdSchmidt]

Wie so oft, möchte ich mich wieder einmal für die rege Mithilfe bedanken.
Mir ist wieder einmal ein neuer Unterschied in den MPEG-Headern von einem Sender mit VBV 91 (ARD) und einem mit VBV 112 (Kinderkanal) aufgefallen. Ich habe mal je eine Videodatei von diesen Sendern mit bbvinfo von bbtool19 bearbeitet und die Ausgabe verglichen.

Bei VBV 91 kommt in der picture coding extension ist das composite_display_flag 1 (bei den anderen Sendern 0), und danach kommen folgende Angaben zum Composite Display:
v_axis
Field Sequence
sub_carrier
burst_amplitude
sub_carrier_phase

und dazu entsprechende Werte. Bei den Sendern mit VBV 112 fehlen diese Angaben.

Ich traue mich schon fast nicht mehr zu fragen, weil ich schon oft genug danebengelangt habe, aber meint jemand, daß das eine Rolle spielen könnte?

Richard Schmidt.

[dvb.matt]

die teilen eigentlich nur mit, wie das analoge Quellsignal vorlag bzw. digitalisiert wurde.
AFAIK wirkt sich der 'trick_mode' (FF,FR etc.) z.B. mit auf diese Werte aus.

[RchdSchmidt]

Vielen Dank, DVD.matt.
Leider weiß ich im Moment auch nicht weiter und habe keine Ideen mehr, aber das kann sich genauso gut schon bald wieder ändern.
Die Dateien im Rar-Archiv von kstroe konnte ich mit PowerArchiver nicht dekomprimieren, dieser meldet einen Fehler im Archiv.

Hat schon jemand nachgeschaut, ob sich die Klötze auf älteren Aufnahmen des Bayerischen Fernsehen, des BR-Alpha, des Hessischen Fernsehens (und vielleicht noch weiterer Sender, die heute mit VBV 91 senden), als dort noch mit VBV-Puffergröße 112 gesendet wurde, die Klötze auch zeigen? Wenn sich bei diesen alten Aufnahmen die Klötze nicht zeigen sollten, wäre das der Beweis, daß das mit der Umstellung auf VBV 91 passiert ist, und dann könnte uns vielleicht jemand bei SES/Astra oder den Sendeanstalten etwas Näheres sagen.

Ich wiederhole nochmals, was andere Teilnehmer dieses Forums herausgefunden haben: nämlich daß die Klötze offenbar nur bei Sendern auftreten, die mit VBV-Größe 91 senden, aber nicht bei den Sendern, die mit VBV-Größe 112 senden.

Richard Schmidt.

[kstroe]

Hallo,

das ganze mit diesen Artefakten ist eigentlich erst aufgefallen, als die DVD
Brenner erschwinglich wurden. Vorher wurde eigentlich immer neu
encoded um die grossen Video-Daten auf 2 CD zu brennen. (SVCD oder VCD) und da haben die meisten SA-Player keine Schwierigkeiten sogar der Toshiba nicht.
Meine früheste Aufnahme auf DVD stammt von 11/2003 von RTL. habe
sie mal geprüft, da ich damals noch den Pioneer SA-Player hatte und
siehe da der Toshiba bringt auch dort grüne Klötzchen.
Dateien von DVD neu encodiert --- funktioniert dann auch auf dem Toshiba Player

[skl]

Also ich habe auch einen Toshiba und der frißt das ohne Probleme

[RchdSchmidt]

Daß es auch Toshibas ohne grüne Klötze gibt, macht das Ganze noch etwas komplizierter. Da wäre natürlich interessant, welchen Typ Skl hat, und bei welchen Typen die Klötze auftreten.

Wohnt oder arbeitet vielleicht jemand von denen, bei denen sich die Klötze bei VBV-91-Sendern zeigen, in München oder im Landkreis? Ich würde demjenigen gern mal eine DVD zum Ausprobieren geben (ich hätte sie aber gern wieder zurück), die ich Mitte 2003 vom BR-Alpha aufgenommen habe und in der noch mit VBV 112 ausgestrahlt wurde.

Denn wenn man sicher sein könnte, daß der Fehler erst mit der Umstellung auf VBV 91 hereingekommen ist, könnte man vielleicht beim BR oder bei Astra erfahren, was sich dabei geändert hat.

Vielleicht wäre es sinnvoll, mal versuchsweise die VBV-Größe viel höher, also z.B. auf 160, zu setzen und zu schauen, ob die Klötze davon weggehen. Aber ich glaube es allmählich nicht mehr.

Übrigens, Neucodieren halte ich aus Qualitätsgründen für keine Lösung.

Richard Schmidt.

[dvb.matt]

außerhalb unserer 'Breiten' sind ja noch ganz andre VBV Größen an der Tagesordnung.

Es ist wohl vonnöten, tief in die Makroblockebene vorzudringen, jenseits der Header.
Das geht aber nur effektiv, wenn man bspw. 5 Sec. des orig. VOB für den SA hat und dieselben 5 Sec. über eine analoge Capturekarte wieder auf den PC gebracht (als D1 Auflös.), wenn der SA genau diese Sequenz (fehlerhaft) abspielt.

Über die Lage und Zeit der 'Klötzchen' kann man Rückschlüsse auf die Position der betreffenden (nicht dekod.?) Makroblöcke(= 'grünen' Klötzchen) ziehen.

[kstroe]

Hallo,

habe feststellen können, daß die grünen Klötzchen nur in den sog.
B-Frames auftauchen. I und P werden richtig angezeigt.
:!:

[RchdSchmidt]

Das ist eine sehr interessante Entdeckung von kstroe. Ich hatte schon mal den Verdacht, daß dort, wo die Klötze erscheinen, vielleicht erst die B-Frames und dann die nachher abzuspielenden I- oder P-Frames auf der Datei erscheinen (in Wirklichkeit sollten ja die B-Frames vorher kommen). Aber soweit ich mich erinnere, habe ich das schon einmal an einer Vob-Datei mit VobEdit überprüft und keine Bestätigung dafür gefunden.

Vielleicht könnte es aber auch so sein: Der DVD-Spieler bekommt einen I- oder P-Frame und muß sich diesen aufheben, bis der an der Reihe ist, denn zuvor kommen ja noch zwei B-Frames. Wenn der VBV-Puffer schon zu voll ist, ist aber für die B-Frames nicht mehr genug Platz da. Ich weiß nicht, ob der erste B-Frame die Unterschiede zum nächsten P- oder I-Frame enthält, oder ob er nur die Unterschiede zum zweiten B-Frame enthält. Weiß das jemand genau? Im ersten Fall (bei Bezug auf den P-/I-Frame) könnte nach der Wiedergabe des ersten B-Frame der Platz für diesen im Puffer wiederverwendet werden (ich weiß aber nicht, ob das wirklich gemacht wird). Im zweiten Fall (bei Bezug des ersten auf den zweiten B-Frame) muß aber der zweite ebenfalls im Puffer bleiben, weil er ja zur Berechnung des ersten B-Frame benötigt wird. Dann müßten also vor der Wiedergabe des ersten B-Frame sowohl der zweite B-Frame als auch der I- oder P-Frame im Puffer sein, und das könnte schon zu viel sein. Wenn aber der Puffer für die B-Frames nicht mehr ausreicht, wäre erklärbar, daß es das Bild gerade für B-Frames und nicht für die I- und P-Frames zerwuzelt. Aber das ist Spekulation. Auf jeden Fall werde ich darüber noch genauer nachdenken und versuchen, mit den BBtools dazu etwas herauszufinden.

Interessant wäre noch zu wissen, ob die Klötze bei beiden B-Frames oder nur beim ersten oder nur beim zweiten auftreten.

Richard Schmidt.

[kstroe]

Hallo,

ich glaube ich habe den Grund für die grüne 'Klötzchen' herausgefunden.

Die TS-Streams von ARD (vermutlich alle von dem Transponder - Auswertung folgt)
sowie die RTL-Gruppe (RTL, RTL2 getestet) haben in den B-Frames der GOP's sog. interpolierte Blöcke (Macroblöcke). Diese Blöcke sind im
nachfolgenden Frame in der frame sequence und im vorhergehenden
Frame in der time sequence sowie umgekehrt vorhanden.

Bei der SAT1-P7 Gruppe sind diese Blöcke nicht vorhanden.
Ich glaube so ohne weiteres kann man diese Blöcke nicht editieren d.h. neuencodieren ist die einzige
Softwarelösung - wie schon mehrfach erwähnt oder neue Hardware die diesen Umstand erkennt oder ignoriert.

Inwieweit diese besagten Macroblöcke DVD-kompatibel sind weiß ich nicht. Toshiba sagt jedenfalls, daß sie sich
strikt an die DVD-Norm halten.

[RchdSchmidt]

Alle Achtung, kstroe!
Wenn sich dagegen wirklich nichts machen läßt, wäre das wirklich sehr schade. Ich würde jedenfalls gern ein Programm schreiben, das das behebt, aber wenn es keine Möglichkeit geben sollte, das zu beheben, kann ich auch kein Programms schreiben. Aber da ich jetzt weiß, nach was ich suchen soll, gebe ich die Hoffnung noch nicht auf.

Super RTL Austria, RTL Austria und RTL2 Austria senden mit VBV-Größe 112, im Gegensatz zu ihren deutschen Pendants, die mit VBV 91 senden. Hat schon mal jemand ausprobiert, ob bei diesen österreichischen RTL-Sendern auch die Klötze auftreten? Wenn nicht, könnte man sie wenigstens bei diesen drei Sendern umgehen.

Richard Schmidt.

Nachtrag: Wie ich soeben gesehen habe, hat ego schon geschrieben, daß die Klötze auch bei RTL Austria und Konsorten auftreten. Wenn das stimmt, würde der Fehler also auch bei Sendern auftreten, die mit VBV 112 senden.

[ego]

nach meinen Erfahrungen treten auch bei RTL-Austria diese grünen Klötzchen auf. Auch das Aufzeichnungsformat (PVA, MPEG, TS) speilt dabei keine entscheidende Rolle. Immerhin scheint jetzt endlich die Ursache gefunden! Gratulation an KSTROE! Wer jetzt noch eine Lösung findet / entwickelt (schnell ohne Neucodierung) ...TOP

Hat jemand eine Idee was der Grund für diese unterschiedlichen Makroblöcke ist (bestimmte Hardware in den Sendeanstalten / Uplinkstationen) oder warum haben ausgerechnet die ARD und die RTL Gruppen, die ansonsten kaum Gemeinsamkeiten haben, diese verflixten B-Frames mit interpolierten Blöcken (Macroblöcke)? Vielleicht ändern die Sender(gruppen) das ja (auf Wunsch) auch wieder ab? (wohl eher illusorisch) ;-); ich würde sogar fast vermuten, denen ist das Problem überhaupt nicht bewusst, weil die Receiver mit den Streams keine Probleme haben und die "Handvoll" - Digitalaufzeichner zu unbedeutend sind.

NACHTRAG
gegoogelt

http://nt.eit.uni-kl.de/lehre/seminar2002_handout/mpeg1&2.pdf

vielleicht kann jemand damit was anfangen; da steht auch was über diese Makroblöcke bei der MPEG -Kodierung; für mich ist das definitiv zu kompliziert, wenngleich ich weiterhin am Thema (noch mehr an der Lösung) sehr interessiert bin.

Gruß Jürgen (ego)

[kstroe]

Hallo,

hier eine kurze Info zum Zoranchip.
Meine E-mail scheint von Zoran wieder direkt nach Deutschland gegangen
zu sein ... nun hier die Antwort:

....leider kann ich Ihnen hier nicht helfen. In nahezu allen Toshiba Playern
finden Sie ZORAN chips, Zoran hat WW einen Marktanteil von ca. 30%. Die Controller werde durch sog. Microcode gesteuert - das bedeutet
in der Regel, dass bei auftretenden Problemen, meist verursacht
durch "Regelverletzer", eine Umgehung programmiert wird.
Ob das hier der Fall ist, und ob Toshiba Updates per DVD ermöglicht, entzieht sich meiner Kenntnis. Der Chip selber, wie alle seine Nachfolger, kann mit Sicherheit alle im Standard niedergelegten Formate dekodieren

[RchdSchmidt]

Damit ist auch die Illusion geplatzt, daß der Fehler auf die Sender beschränkt ist, die mit VBV-Größe 91 und nicht 112 senden, da die RTL-Sender für Österreich mit VBV 112 senden.

Eine Frage an kstroe:

Was sind interpolierte Blöcke? Sind sie das, was ich unter Makroblöcken verstehe: Je ein Quadrat aus 8 mal 8 Pixel, die für die Berechnung des nächsten Bilds entlang einem Vektor verschoben werden können?

Wenn das so ist, kann ich mir nicht vorstellen, daß einige Sender ohne diese auskommen können und daß diese nicht DVD-konform sind. Aber es könnte natürlich sein, daß sie nur in P-Frames, aber nicht in B-Frames DVD-konform sind.

Wenn wirklich diese Makroblöcke das Problem sein sollten, fürchte ich auch, daß ich kein Programm dazu schreiben kann. Ich kann schließlich keinen neuen Encoder schreiben.

Als letzte Hoffnung bleibt jetzt fast nur noch, Astra den Fehler genau zu schildern und zu fragen, was bei den fraglichen Sendern ganz genau der Unterschied sein könnte, der solche Störungen verursacht.

Den von ego vorgeschlagenen Artikel kann ich gerade nicht lesen, weil ich hier nichts herunterladen kann, aber ich hoffe, ich schaffe es wenn ich wieder daheim bin.

Richard Schmidt.

[kstroe]

Hallo,
ja genau, es sind die 8x8 Blöcke in den B-Frames.
Ich habe das ganze auch nur herausgefunden, in dem ich bei Pixeltools
eine Demo-Version eines MPeganalyzer bekommen habe.
(Thanks to D.Kors)
Mit diesem Tool kann man sich sehr gut die Macroblöcke anschauen und
beim direkten Vergleich habe ich eben das besagte herausgefunden.
D.Kors schreibt übrigens über diesen Umstand folgendes:

....I think you'll have to decode and re-encode the entire video which of
course MpegRepair will do. To change a pattern of frames or parameters
is pretty difficult.

Dick

Also neuencodieren, übrigens wer sich für MPGRepair in der Vollversion
interessiert Kostenpunkt ca. 1000 US$.

[Derrick]

..da dürfte ein neuer standalone, der sowas ohne bocken abspielt, günstiger sein ;)

[kstroe]

Hallo,
nachdem ich jetzt diverse Streams aufgenommen habe, muß
ich leider feststellen, daß der Grund doch woanders liegen könnte.
Der ZDF Transponder sendet auch mit diesen interpolierten Blöcken,
nur sind keine grünen Klötzchen zu sehen. Dasselbe trifft auch bei 3SAT
zu.

RTL Austria hat genau wie ZDF VBV 112 - wie schon erwähnt - jedoch
zeigt der aufgenommene Stream grüne Klötzchen. Die Bitrate ist beim
ZDF mit 15Mbit im Header sehr hoch, bei RTL Austria ist diese 3,8Mbit.

Vielleicht bestehen dort die Zusammenhänge, daß der Buffer noch nicht
alle Daten hat, aber schon ausgelesen wird.

[dsa123]

Ich schreibe jetzt hier fort. Ich habe einen Toshiba-Player SD 220 E, ca. 3/4 Jahr alt. Ich kaufte ihn damals weil mein erster Player keine selbstgebrannten DVD abspielt sondern nur S-VCD. Jetzt habe ich den Toshiba und der zeigt jetzt häufig grüne Klötzchen. Ich bin enttäscht und sehe nicht ein einen dritten Player zu kaufen. Es muss eine Möglichkeit mit der vorhandenen Peripherie geben..

Ich habe eine kleine Testreihe gemacht. Das Ergebnis ist in dem anhängenden Wordpad-file aufgeführt. Kurz zusammengefaßt:
1) Alle Filme mit VBV 91 zeigen grüne Klötzchen, alle mit VBV 112 sind o.k.
2) ich habe keinen Unterschied zwischen 720x576 und 704x576 festgestellt. Es liegt wohl allein an den VBV 91.
3) Meine 16:9-Filme waren mit VBV 112 kodiert. Vielleicht ist das Zufall.
4) Umpatchen mit ProjectX von VBV 91 auf VBV 112 in Video2-Reiter bringt keine Veränderung. Der Toshiba zeigt grün.

Runterrechnen ist zwar keine akzeptable Lösung. Aber besser als gar nicht den Film aufzuzeichnen. Was wäre dann der beste Weg ?

An Pennywize:
Umkodieren geht mit rempg2 v1.5.2. Das kleine Programm wird leider seit Jahren nicht mehr weiterentwickelt. Zumindest nicht unter diesem Namen. Ich weiß auch nicht ob das in anderer SW eingebaut ist. Hier hat man die Möglichkeit den stream runterzurechnen. Ich habe das seiner Zeit immer zum Umwandeln in S-VCDS genutzt. Leider ist das Programm zum runterrechnen gedacht, und der kleinste einstellbare Wert ist 90 %. Bei S-VCDs am Fernseher betrachtet hat man da keinen Unterschied zum Origianl gesehen. Aber wenn wir jetzt schon DVDs brennen können will ich doch nicht das Bild auch nur um 10% verschlechtern.

An kstroe:
Neukodieren mit TMPGenc habe ich bisher nicht zustande gebracht. Bei mir will TMPGenc in der Testversion keinen mpg laden. Das wäre ein nicht unterstützter Codec. Irgendwo las ich, dass man da einen patch installieren muss. Ich habe aber nichts außer einem AC3-patch gefunden. Was muss man machen damit ich mit TMPGenc mal versuchen kann den Film umzukodieren ?

Kann man bei TMPGenc eine Neukodierung machen ohne dass die Qualität stark leidet ? Als Kriterium würde ich die file-Größe vorher und nachher vergleichen.

laut RchdSchmidt:
ist die Qualität bei BBmpeg nicht so gut wie bei TMPGenc. Gibt es noch andere Möglichkeiten ?

[skl]

Bei mir will TMPGenc in der Testversion keinen mpg ladenNimmDVD2AVI erstelle ein Project und lade dies als VideoSource und es geht!

Steffen

[RchdSchmidt]

Zur Bildqualität mit BBmpeg möchte ich ergänzen:
Die Erkenntnis, daß das mit BBmpeg codierte Bild nicht so gut ist wie mit TMPGENc, habe ich aus der Zeit, als ich MPEG2 noch nicht direkt mit BBmpeg bearbeiten konnte, sondern erst mit FlaskMpeg (oder war es FlaskMpg?) decodieren mußte. Seit ich den Licos-Decoder heruntergeladen und installiert habe, kann BBmpeg mit diesem direkt zusammenarbeiten, und die schlechtere Bildqualität ist mir nicht mehr aufgefallen. Aber seitdem brauche ich BBmpeg fast nur noch zum Multiplexen, denn jetzt geht es ja bei mir ohne Neucodieren. Kann aber durchaus sein, daß das Bild jetzt besser ist.

Allerdings habe ich vor Jahren in der Zeitschrift Chip gelesen, daß die Bildqualität bei BBmpeg nicht so gut sein soll, nur das Preis-Leistungs-Verhältnis ist ganz hervorragend, denn BBmpeg kostet ja nichts.

Richard Schmidt.

[RchdSchmidt]

Ich glaube, die ganze Sache ist etwas am Einschlafen. Kein Wunder: offenbar hat zur Zeit niemand mehr eine zündende Idee.
Ich werde mich auch nur mehr höchstens gelegentlich melden, aber im Verborgenen weiter experimentieren.
Ich habe mir jetzt mal die Quellen von Kino, einem MPEG2-Decoder und -Spieler, heruntergeladen und will versuchen, ob ich sie übersetzen und zum Laufen bringen kann. Dann werde ich versuchen, das Programm so zu ändern, daß es keinen decodierten Code, sondern Informationen über die Aktionen herausgibt. Ob mir das gelingt, weiß ich nicht, und es kann lang dauern.

Danke nochmals an alle, die sich hier um eine Lösung bemüht haben, vor allem an kstroe, der eine Menge Arbeit hineingesteckt hat.

Richard Schmidt.

[kstroe]

Hallo
vielen Dank für die Blumen.

leider habe ich auch keine zündende Idee mehr.
mit bbvinfo habe ich noch erkannt, daß der vbv_delay bei den
grünen Blöcke-Filmen variabel ist (vbv-Buffer=112). Das heißt er hat bei
jedem Header andere Werte.
komisch ist das X diese Werte nicht auf max. gestellt hat, bei
entsprechender Parametereinstellung.
Aber bei anderen Aufnahmen ist der vbv_buffer_delay auf max. bei
vbv-Buffer =91 und grüne Klötze.
Viel Erfolg noch an alle die das Probieren noch nicht aufgegeben
haben besonders @RchdSchmidt.

[dsa123]

ich habe auch leider nichts neues rausgefunden. Für mich steht fest, dass es am vbv 91 liegt.

In den letzten Tagen habe ich mal versucht neu zu berechen aber möglichst ohne die Qualität zu verschlechtern noch die file-Größe erheblich zu vergrößern.

Mit TMPGEnc ist mir das nicht zufriedenstellend gelungen. Wenn ich hier, wie oben beschrieben, über DVD2AVI das mpg-file lade und neu codiere wird die GOP neu berechnet. Außerdem kann sich die file-Größe erheblich ändern. Das liegt eben an den Einstellungen der 2-pass-Codierung. Das ist in meinen Augen nicht akzeptabel.

Ich meine, auch die Lösung über avi wieder zu mpg zu wandeln scheidet von vorne herein aus.

Der beste Weg ist noch über Rempg2 v1.52. Das ist Freeware. Die GOP bliebt unverändert. Irgendwie wird aber stärker komprimiert. Auf minimal 90%. Die Qualität leidet kaum merklich. Zumindest nicht auf dem Röhrenfernseher.

[dsa123]

Ich möchte aber nicht vom eigentlichen Problem abwenden.

Was für Möglichkeiten haben wir ARD und RTL auf das Problem aufmerksam zu machen ?

Ich habe u.a. einen SAT-Receiver von Thomson. Seit einen halben Jahr stürzt der regelmäßig mindestens 1x pro Woche ab. Das war früher nicht der Fall. Das Bild ist grün mit vielen Klötzchen drin. Ist das vielleicht der gleiche Grund ? Hat jemand das auch bei seiem SAT-Receiver beobachtet ? Wenn das die gleiche Ursache hat müßte es doch einen größeren Kreis betreffen.

[Oliver]

Wäre es möglich, mal einen kurzen Clip (20-30 Frames) hochzuladen, wo diese Störungen auftreten?

Bis dann, Oliver

[kstroe]

Hallo,

@dsa123
Habe auch eine E-Mail an die ARD geschickt, daß die Qualität der Bilder
sehr schlecht ist (etwas übertrieben).. prompt bekam ich eine Antwort:

vielen Dank für Ihre E-Mail vom 15. März und Ihr Interesse an ARD Digital.

Vielen Dank für Ihren Hinweis bezüglich der Bildqualität. Wir haben dies
zur Information an die zuständige Fachabteilung weitergeleitet. Es tut uns
leid, dass Sie bei einigen Programmen von ARD Digital einen
Qualitätsverlust hinnehmen mussten.

Untersuchungen namhafter Institute haben ergeben, dass mit der Datenrate,
mit der ARD Digital ausgestrahlt wird, mindestens die Qualität der analogen
Übertragungsverfahren erreicht wird. Durch fortlaufend verbesserte
Technologien (Optimierung der Kompressionsverfahren, Rauschunterdrückung
und Datenratenverteilung) können über einen Transponder (mit ca. 38 MBit/s
Datenrate) ohne Qualitätsverlust beispielsweise bis zu neun
Fernsehprogramme übertragen werden. Die Datenkompression auf MPEG-Basis,
die die ARD anwendet, ist zudem ein weltweit anerkanntes Verfahren (MPEG 2
für das Bild bzw. MPEG 1 Layer 2 für den Ton). Die Fachabteilung vermutet,
dass die von Ihnen benannten "Ruckelbilder", sofern sie nicht dauerhaft
auftreten, vom so genannten Multiplexer, dem Datenbündelungssystem,
verursacht werden.

Der Multiplexer bündelt die aus den jeweiligen (für jedes Programm
existierenden) Encodern kommenden Datenströme zu einem. Zudem reserviert er
für jede Einzelkomponente eine fixe Datenrate, die sich am Bedarf des
Programms ausrichtet (2-15 Bit/s). Das heißt, diese Datenströme sind mal
mehr und mal weniger komplex, je nach dem wie detailreich und bewegt die
digitalisierten Bilder sind. Die maximale Datenrate ist jedoch nur bei
komplexen Bildinhalten (Kameraschwenks, schnelle Bewegungen) erforderlich.
Werden auf zahlreichen Sendern gleichzeitig viele informationsintensive
Bilder ausgesendet, ist es unter Umständen möglich, dass der Multiplexer
nicht mehr alle Informationen bündeln und aussenden kann. Der Datenstrom
lässt sich in einem solchen Fall nicht mehr mit der Bandbreite vereinbaren
und "schneidet" Bits weg. Dies hat einen Informationsverlust zur Folge, der
sich womöglich in einem Störungsbild abzeichnet.

Die Fachabteilung weist darauf hin, das Informationsverluste im Multiplexer
temporär sind und nur recht selten Qualitätseinschränkungen auf einzelnen
Sendern zur Folge haben. Grundsätzlich bietet die zur Verfügung stehende
Bandbreite eine ausreichende Qualitätsgrundlage.

Zudem wurde die Bildqualität bei ARD Digital auch dadurch verbessert, dass
nun alle Programm digital per Leitung zugeführt werden.

Für Rückfragen stehen wir Ihnen jederzeit gern zur Verfügung.
Darüber hinaus erreichen Sie unsere Hotline unter der Nummer 0180 / 500 14 95.



Mit freundlichen Grüßen

Ihr ARD Digital Team

Vieleicht kann man das Thema doch mal bei der ARD ansprechen.

[TheHorse]

Zudem wurde die Bildqualität bei ARD Digital auch dadurch verbessert, dass nun alle Programm digital per Leitung zugeführt werden.Zwar jetzt offtopic zu eurem Klötzchen-Problem, aber: Bayerisches FS hat immer noch Fischchen in gelben, roten und hellblauen Flächen und Kanten. Wie die wohl bei volldigitaler Zuführung da rein kommen??? :lol:

[RchdSchmidt]

Jetzt muß ich mich doch mal wieder einmischen.
Das ist eine ganz neue Perspektive, daß auch der DVB-Direktempfang betroffen ist und nicht nur die Umwandlung von aufgenommenen Sendungen ins DVD-Format. Damit steigen meiner Meinung nach die Aussichten, daß sich jemand um das Problem kümmert.

Ich glaube, der richtige Ansprechpartner für das Problem ist Astra / SES, weil neben der ARD-Gruppe auch die RTL-Gruppe betroffen ist. Aber ich kann mich natürlich auch täuschen.

Obwohl ich bei meinem DVD-Spieler Cyberhome 402 das Problem überhaupt nicht kenne, trage ich mich mit dem Gedanken, mal an Astra zu schreiben. Wenn ich eine passende Email-Adresse finde.

Mit meinen Versuchen, den Kino-Mpeg2-Spieler zu übersetzen und damit weiter zu suchen, bin ich im Moment an einer Sackgasse angekommen, weil die Quellen viel Assemblercode enthalten und ich mir erst einen Assemblierer organisieren muß. Aber ich rechne immer noch damit, daß jemand eines Tages eine Lösung findet, zu der man ein Programm schreiben kann.

Richard Schmidt.

[Derrick]

Jetzt muß ich mich doch mal wieder einmischen.
Das ist eine ganz neue Perspektive, daß auch der DVB-Direktempfang betroffen ist und nicht nur die Umwandlung von aufgenommenen Sendungen ins DVD-Format. Damit steigen meiner Meinung nach die Aussichten, daß sich jemand um das Problem kümmert.

Ich glaube, der richtige Ansprechpartner für das Problem ist Astra / SES, weil neben der ARD-Gruppe auch die RTL-Gruppe betroffen ist. Aber ich kann mich natürlich auch täuschen.


..ob das viel sinn hat? Der dvb-empfang ist ja anscheinend von diesem speziellen problem nicht betroffen. In der ausführlichen antwort wird doch nur auf die theoretische möglichkeit hingewiesen, dass beim statistical multiplexing unter bestimmten umständen pakete gedropt werden können. Wer seinen transponder grundsätzlich zu voll packt oder die parameter nicht richtig wählt, hat damit sicher eher probleme.

Encoder und multiplexer werden aber sicher nicht optimiert, um dvd-konforme aufnahmen zu machen ;)

[kstroe]

Hallo,

@RchdSchmidt
wie meine Vermutung schon richtig lag ist SES-Astra nicht
die richtige Adresse:

an Astra:
Frage:
> Inwieweit trifft die Zuständigkeit
> für die Encodierung der DVB-S FTA
> Streams in das Mpg-TS Format auf Sie zu. Oder stellen Sie nur den
> Transponder für die einzelnen Programme zur Verfügung.
> Mit freundl Gruß
Antwort:
wir danken Ihnen für Ihre E - Mail und Ihr Interesse am ASTRA
Satellitensystem.
Bezüglich Ihrer Anfrage können wir Ihnen mitteilen, dass wir nur den
Transponder für die einzelnen Programme zur Verfügung stellen.
Wir hoffen Ihnen weitergeholfen zu haben und verbleiben
mit freundlichen Grüßen,

Ihr ASTRA - Marketing Team

Also sind die Rundfunkanstalten für die Digitalisierung alleine
verantwortlich.

Ich habe nochmals zur ARD gemailt und gefragt ob der MPG-TS
Stream gemäß ISO13818 ist; bin mal gespannt auf die Antwort.

[RchdSchmidt]

Daß offenbar auch DVB-Direktempfang vom Problem betroffen ist, habe ich einer Zuschrift von dsa123 entnommen. Allerdings habe ich dabei nicht beachtet, daß dsa123 nicht schreibt, daß der Fehler nur bei bestimmten Sendern auftritt.

Zur Antwort der ARD habe ich mir noch ein paar Gedanken gemacht. Ich glaube inzwischen auch, daß die ARD der richtige Ansprechpartner ist, weil die bei Astra ja offenbar nur die verschiedenen Video- und Audioströme zu einem Transportstrom zusammenmultiplexen.

Ich glaube auch, daß man bei der ARD das Problem mißverstanden hat. Denn es handelt sich nicht um einen kurzzeitigen geringen Bildfehler während eines gelegentlichen Kapazitätsengpasses, sondern der um eine massive Störung bei jeder Bewegung unabhängig von der Bitrate der anderen Sender im Transportstrom. Es handelt sich auch nicht um zufällige Fehler bei der analogen Zuspielung, sondern um einen reproduzierbaren Fehler. Solche zufälligen Fehler müßten auch bei allen DVD-Spielern auftreten.

Wenn kstroe nichts dagegen hat, würde ich gern mal selber an die ARD schreiben und dabei die Antwort der ARD zitieren bzw. in Teilen kopieren. Dabei möchte ich gern genau beschreiben, wie der Fehler ausschaut und unter welchen Bedingungen er auftritt.

Da ich den Fehler noch nie gesehen habe, will ich das Fehlerbild im folgenden beschreiben und bitte um Bestätigung oder Korrektur und ggfs. Ergänzung oder weitere Präzisierung. Denn je besser der Fehler beschrieben wird, umso größer ist die Aussicht, daß uns jemand zur Ursache etwas sagen kann.

Fehlerbild: Bei Bewegung im Bild erscheinen grüne Quadrate, die um die bewegten Kanten herumtanzen und dabei im Vergleich zu den übrigen bewegten Teilen verzögert erscheinen. Die unbewegten Teile des Bilds sind davon unberührt, mit Ausnahme der unmittelbaren Umgebung der bewegten Kanten. Dabei hat man den Eindruck, daß das Bild mehr oder weniger zerstückelt und falsch zusammengesetzt wurde.

Ideal wäre es, wenn jemand den Fehler z.B. auf VHS aufnehmen, eine kurze Sequenz daraus über eine TV-Karte auf den Rechner überspielen und daraus ein Bild (z.B. in jpeg) oder ein paar Bilder hier zum Herunterladen zur Verfügung stellen könnte. Dann könnte ich ein Bild, das den Fehler zeigt, an die ARD schicken. Aber das muß nicht sein.

Richard Schmidt.

[kstroe]

Hallo,

@RchdSchmidt
Ich habe nichts dagegen, diese E-Mail der ARD weiter zu verwenden.
Sagt sie doch alles und gar nichts aus.
Zur Unterstützung stelle ich zum download ein paar Bilder bereit,
die das Problem eigentlich ganz gut widergeben.
Es sind nicht nur Bildfehler sondern wie man sieht komplette Bilder
die einfach nicht angezeigt werden.

[RchdSchmidt]

Vielen Dank, kstroe, jetzt habe ich die Bilder heruntergeladen und weiß endlich, wie die Klötze ausschauen, und bin tief beeindruckt. So groß hätte ich sie mir nicht vorgestellt. Erinnert mich stark an die Quadrate in den Schnittstellen bei PVACut, nur daß sie dort schwarz statt grün sind.
Ich sehe daraus, daß ich meine Beschreibung des Fehlers für die ARD ändern muß.

Da mein Kollege, der einen Sanyo-DVD-Spieler hat, jetzt wieder da ist, bin ich gerade dabei, eine DVD mit kurzen Proben der verschiedenen Sender zu machen. Diese werde ich im zum Testen geben, und er wird mir sagen, welche Sender den Fehler bringen. Besonders gespannt bin ich darauf, wie sich die alten Aufnahmen verhalten, wo die ARD-Sender noch mit VBV-Puffergröße 112 gesendet haben. Falls diese laufen, kann ich die ARD gezielt nach den Veränderungen fragen.

So lang muß meine Anfrage noch warten.

Richard Schmidt.

[dsa123]

sehr gut die Bilder, so sieht es bei meinem Toshiba auch aus. Meist ist fast das ganze Bild grün, selten nur wenige Klötzchen. Ob die Klötze nur in bewegenten Stellen auftreten habe ich nicht beobachtet.

Meine Vermutung, dass bei mir auch der DVB-Direktempfang betroffen ist hat sich nicht weiter bestätigt. Es liegt wohl an meinem Kabel. 100% sicher bin ich aber noch nicht. Also vergeßt lieber meine Äußerungen. Ich wäre ja wohl auch der Einzige.

RchdSchmidt:
hast du bei deinem Freund getestet?
Sender o.k.: Pro7, Kabel1, BR, ZDF, 3sat, alle Filme hatten 112
Sender grüne Klötzchen: S-RTL, RTL, WDR, SWR, Phoenix, HR, alle Filme hatten 91

Es gibt noch jede Menge andere Foren. Hat jemand dort schon einmal dieses Problem gepostet ?

[RchdSchmidt]

Vielen Dank, dsa123, für diese Information. Da werde ich mein Schreiben an die ARD gleich entsprechend abändern. Gut, daß ich es noch nicht abgeschickt habe, aber ich möchte erst noch die Ergebnisse von meinem Kollegen mit dem Sanyo-DVD-Spieler abwarten. Ich habe ihm am Gründonnerstag eine DVD mit 39 mehr oder weniger kurzen Testaufnahmen von verschiedenen Sendern mitgegeben und ihn gebeten, mir das Ergebnis mitzuteilen. Besonders warte ich darauf, ob meine alten Aufnahmen von Dritten Programmen und ARD auch den Fehler zeigen, weil dort die VBV-Größe noch 112 ist. Denn wenn dort alles gut ist, kann ich die ARD gezielt nach den Änderungen an den Sendeparametern fragen. Leider habe ich noch nichts von ihm gehört. Vielleicht ist er ja über Ostern weggefahren.
Aber wenn ich ein Ergebnis habe, werde ich es gleich hier bekannt machen.

Ich habe das Problem schon im Brennmeister-Forum zur Sprache gebracht, aber nur eine Antwort erhalten, daß DVB nichts taugt, weil die Bitrate zu niedrig ist und das Bild vor dem Codieren weichgezeichnet wird.

Vielleicht wäre auch das PVAStrumento-Forum geeignet, um das Poblem anzusprechen.

Richard Schmidt.

[dvb.matt]

was an den Bildern merkwürdig ist:
Es sind nicht durchweg immer komplette Y-Blöcke (8*8px) betroffen, sondern manchmal nur Teile davon. Desweiteren im Ergebnis eigentlich den 2 Scanmodi (zigzag/altern.) widersprechend in 'grün'. Es sieht vielmehr danach aus, dass an den grünen Stellen ein Werteüberlauf ist. Und das hat mit einem Bufferproblem IMO nichts gemein. (Bsp: SCRN0029.jpg direkt über dem ersten w von www)

[RchdSchmidt]

Von meinem Kollegen, der meine DVD mit 39 Testaufnahmen von verschiedenen Sendern getestet hat, habe ich jetzt die Ergebnisse bekommen.

Die in diesem gemachten Aussagen wurden bestätigt - mit Ausnahme der Österreich-Ableger von RTL:
Mein Kollege hat sowohl bei RTL-Austria als auch bei SRTL-Austria keine grünen Klötze gesehen.
Ich habe ihn gebeten, dies nochmals zu überprüfen.
Außerdem haben sich bei meinen alten Aufnahmen von ARD, Arte (Astra, deutsch), Bayerischem und Hessischem Fernsehen und Saar-Fernsehen, sowie bei Super RTL keine grünen Klötze gezeigt. Auch bei Super RTL habe ich meinen Kollegen geben, das nochmals zu überprüfen.

Auch der Sanyo-DVD-Spieler meines Kollegen scheint einen Zoran-Dekoder zu haben. Denn ich habe im Google nach Zoran & Sanyo gesucht und einen Artikel von 2002 gefunden, daß beide künftig zusammenarbeiten.

Heute habe ich ein Schreiben an ARD-Digital geschickt - und weil ich glaube, daß diese nur fürs Programm zuständig sind, habe ich gebeten, mein Schreiben an die richtige Adresse weiterzuleiten. Ich will versuchen, mein Schreiben zum Herunterladen verfügbar zu machen. Den Anhang, nämlich die Antwort von ARD Digital an kstroe, sowie seine Bilder, die ich an mein Schreiben angehängt habe, spare ich mir dabei. Leider konnte ich die Datei nicht als .txt-Datei anhängen, sondern mußte sie komprimieren. Und weil ich unter Knoppix-Linus im Internet bin, habe ich nur den gzip und keinen winzip zur Verfügung. Ich hoffe, das stört nicht.

Ich hoffe, meine Umlaute kommen hier richtig raus, weil ich heute an meinem eigenen Rechner schreibe und nicht wie sonst in der Bibliothek. Wenn sie falsch sind, sind sie wohl auch in meinem Schreiben falsch.

Richard Schmidt.

------------------------------------------
15.4.04 Berichtigung
Von meinem Kollegen habe ich soeben eine Email gelesen, daß sich bei RTL und Super RTL für Österreich doch jede Menge grüne Quadrate zeigen. Dafür gibt es bei einer älteren Aufnahme aus Super RTL, bei der der VBV 112 noch ist, keine Klötze ("SRTL -- ausgezeichnetes Bild"). Auch bei der Aufnahme vom Bayerischen Fernsehen, wo die VBV-Puffergröße für wenige Tage 109 war, hat er Klötze gefunden, wenn auch nicht so viele. Daß es weniger Fehler waren, kann aber auch an der Art des Films (Querbeet durchs Gartenjahr) liegen.
Daraus und aus den bereits bekannten Testergebnissen schließe ich, daß der Fehler bei sämtlichen Kanälen, wo er sich zeigt, erst im vorigen Jahr hereingekommen ist, und zwar gleichzeitig mit der Umstellung auf VBV-Puffergröße 91 bzw. 109.
Richard Schmidt.

[RchdSchmidt]

Zur Stellungnahme von dvb.matt möchte ich anmerken:
Das mit den unvollständigen Y-Blöcken habe ich nicht ganz verstanden.
Wenn damit gemeint ist, daß manche Klötze im Bild 29 waagerecht grün schraffiert sind, so würde ich das mit Interlacing erklären: Wenn sich z.B. an einer Stelle nur bei den geradzahligen Zeilen Unterschiede zum nachfolgenden Bild ergeben und bei den ungeradzahligen Zeilen nicht, so erscheinen an dieser Stelle nur beim Halbbild mit den geradzahligen Zeilen die Klötze, das andere ist einwandfrei. Wenn man dann die beiden Halbbilder zu einem jpg-Bild zusammenfügt, so erscheinen die Klötze an dieser Stelle schraffiert.
Wenn aber gemeint ist, daß die Klötze zum Teil schr schmal sind, so muß ich dvb.matt Recht geben: bei 8 mal 8 Chrominanzpunkten bzw. 16 mal 16 Luminanzpunkten in einem Makroblock und einer Horizontalauflösung von 720 Punkten ergibt sich eine Breite von einem Fünfundvierzigstel der Bildbreite für einen Block (ich gehe davon aus, daß 720 Punkte gleich 720 Luminanzpunkte sind - wenn nicht, bitte ich um Berichtigung). Bei 27 cm Breite für das jpg-Bild am 15-Zoll-Monitor müßte dann ein Block knapp 5 mm breit sein. Die beanstandeten Blöcke sind aber nur ca. eineinhalb mm groß.
Zur Erklärung möchte ich mal eine wilde Spekulation zur Diskussion stellen: ich glaube, ich habe mal gelesen (könnte mich aber auch täuschen!), daß beim Codieren nach dem Erzeugen der Makroblöcke und ihrer Verschiebevektoren das sich daraus ergebende ("berechnete") Bild mit dem Originalbild verglichen wird und die Unterschiede zusätzlich übertragen werden. Falls das wirklich stimmt, könnten diese Unterschiede vielleicht als Rechtecke beliebiger Größe ausgegeben werden. Vielleicht führen diese Rechtecke bei bestimmten Sendern und Geräten ja auch zu diesen grünen Klötzen. Oder vielleicht sind es sogar nur diese Unterschiede, die die Klötze verursachen. Aber wie gesagt, das ist nur eine verrückte Idee von mir, und ich weiß nicht, ob was dran ist. Denn leider kommt es bei mir öfters vor, daß ich etwas verwechsle.

Richard Schmidt.

[dvb.matt]

was ich meinte:
es gibt IIRC zwei Y-Level : 0..255 für PC, 16..235 für TV (Beschränkung zur verbesserten Erkennung der Horizontal- und Vertikalsynchronisation im Analog-Tv)
ich hab mal div. Streams grob verglichen, die problematischen hatten weit häufiger Werte, die die "TV" Grenze überschritten.
schwarze Balken müßten theoretisch 16 haben und weiß nicht höher als 235, für z.B. eine alte 112er ARD Aufnahme mit Balken traf das zu, ebenso aktuelle Pro7 etc., was aktuelles aus dem ARD Paket ging da deutlich drüber/drunter.
praktisch soll aber der gesamte Wertebereich vom Decoder unterstützt werden.

andersrum, wenn ein verschobener/neukodierter Block fehlt/mangels Buffering nicht dekodiert wurde, kann er ja im Prinzip den vorherigen garnicht (grün) ersetzen ?!

zu den kurzen vertikalen Störungen:
jeder Block wird von links oben (mit dem durchschnittlichen Wert des Blocks beginnend) via h -> v nach rechts unten gescannt. bei interlaced (als field) enkodierten werden zur effektiveren Enkodierung die je 4 Zeilen pro field zusammengezogen, drum sind manche Blöcke danach 'halb' grün.
dennoch nach der Scanningorder eigentlich komisch, es sei denn o.g. trifft zu.

[RchdSchmidt]

Vielen Dank, dvb.matt, für die Aufklärung. Auch wenn ich nicht all[/b][/color]es verstanden habe.

Ich habe eine erste Antwort von ARD Digital bekommen. und kopiere sie gleich rein, aber erst möchte ich noch folgendes loswerden:

Jemand hat geschrieben, daß Arte auf Eutelsat den Fehler nicht bringt. Nun senden aber doch auch ARD und RTL (und vielleicht sogar RTL2 und Super RTL?) auch auf Eutelsat. Könnte es nicht sein, daß dort der Fehler ausbleibt?

Richard Schmidt.


Antwort von ARD Digital:

Sehr geehrter Herr Schmidt,

vielen Dank für Ihre ausführliche E-Mail vom 14. April und der sehr genauen Problembeschreibung.

Wir haben Ihre Anfrage an die zuständige Fachabteilung weitergeleitet.
Zu dem von Ihnen geschilderten Sachverhalt können wir gegenwärtig folgendes sagen:
Zunächst möchten wir Sie darüber aufklären, dass ARD Digital in der standartisierten
DVB-Norm ausgestrahlt wird. Die DVD-Norm unterscheidet sich von der DVB-Norm.
Für die DVD- als auch DVB-Norm bildet der MPEG-2 Standard die Grundlage. Dennoch ist
der Standard für die DVD restriktiver als der für DVB. Es ist daher nicht ausszuschließen, dass die Fehler bei der Weiterverabeitung entstehen.

Eine Überprüfung auf mehreren DVB-Decodern zeigt, dass die von uns ausgestrahlten Bilder nach dem DVB-Standard störungsfrei sind. Sie können dies vermutlich damit überprüfen, indem Sie Ihre Aufnahme mit der Software ansehen, mit der Sie sie aufgenommen haben. Die RTL Group verwendet die gleichen Video-Encoder wie ARD Digital. Die Encoder beim Tansponder 71 wurden im Oktober letzten Jahres erneuert. Dies bestätigt Ihre Beobachtung, dass der Effekt nur bei einigen Sendern auftritt.

Es wäre schön, wenn Sie uns eine Test-DVD zur Verfügung stellen könnten.

Sie können die DVD schicken an:
Kommunikation und Marketing
ARD Playout Center Potsdam
Marlene-Dietrich-Allee 20
14482 Potsdam


Für Rückfragen stehen wir Ihnen jederzeit gern zur Verfügung.

Darüber hinaus erreichen Sie unsere Hotline unter der Nummer 0180 / 500 14 95.


Mit freundlichen Grüßen

Ihr ARD Digital Team

[Airic]

Hi!


Ich hab mir den Thread mal reingezogen, da ich leider ebenfalls ein Betroffener bin :(

Mal eine andere Übereinstimmung die ich gesehen habe ...

Alle VBV 91 haben zusätzlich auch die "Intra DC Precision 8 bit".
Könnte es sein, dass manche Player mit dieser zu geringen Tiefe nicht klar kommen?


greetings
airic

[dsa123]

@ RchdSchmidt
sendest Du eine DVD an ARD ? Ich denke, es macht wenig Sinn, dass jetzt alle möglichen Betroffenen das tun.

[skl]

je mehr DVDs dort landen um so hellhöriger werden die und je mehr Zuschauer aktiv werden um so größer die Chance dass sich was tut

[RchdSchmidt]

Ich möchte noch heute meine Test-DVD an die ARD schicken. Das Verpackungsproblem ist auch schon so gut wie gelöst. Ich habe gerade eine Image-Datei für die DVD erzeugt und muß sie nur noch brennen und einsacken, noch ein kurzes Anschreiben verfassen und abschicken. Um vier Uhr wird der Briefkasten bei uns geleert, das wird sicher reichen.

Ich glaube nicht, daß es notwendig ist, daß mehrere Leute ihre DVDs schicken. Denn den Fehler sieht man ja nur, wenn man den "richtigen" DVD-Spieler hat. Und da reicht eine DVD. Die Frage ist eher, ob dort jemand einen solchen DVD-Spieler hat. Ich habe schon den Eindruck, daß man bei der ARD versuchen möchte, die Ursache zu finden. Aber wenn jemand einen konkreten Verdacht hat, was die Ursache ist, würde es nichts schaden, wenn er auch an ARD-Digital schreibt, vielleicht kommt man dann eher auf den Fehler.

Zur Antwort von Airic:
Ohne genau zu wissen, was es mit der Intra-Matrix auf sich hat, habe ich die Entdeckung von Airic zum Anlaß genommen, mal die Intra-DC-Precision der verschiedenen Aufnahmen auf meiner Sendertest-DVD mit VobEdit anzuschauen. Bei meinen Stichproben von allen Beispielen, bei denen der Fehler auftritt, ist der Wert dafür 0. Allerdings ist er bei den Beispielen, die einwandfrei abgespielt werden können, auch manchmal 0. Er variiert zwischen 0 und 2 (Beispiel für 0: Kinderkanal, Beispiel für 2: Kabel1). Da in der Vob-Datei für diesen Wert 2 Bits (also Wertebereich 0 bis 3) verfügbar sind und der tatsächliche Wert 8 bis 11 sein kann, nehme ich an, daß VobEdit immer um 8 weniger angibt.
Der Wert für die Intra-DC-Precision steht bei jedem Bild, und ich habe auch eine Aufnahme gefunden (ohne Klötze), bei der manchmal 1 und manchmal 0 drin steht.
Da also ein Wert von 8 Bits nicht immer bedeutet, daß der Fehler auftritt, vermute ich, daß das eher eine zufällige Nebenwirkung der neuen Encoder ist, ähnlich wie die VBV-Puffergröße, die ja hier auch keine Bedeutung zu haben scheint.
Jedenfalls wäre ich froh, wenn es nicht die Intra-DC-Precision ist, denn wenn sie schuld ist, könnte ich mit Sicherheit nicht den Fehler mit einem Programm beheben, denn dann könnte nur Neucodieren helfen. So habe ich aber noch Hoffnung.

Richard Schmidt.

[RchdSchmidt]

Obwohl sich seit fast 3 Wochen nichts mehr getan hat, muß ich mich doch wieder mal melden. Auch wenn sich dabei vielleicht mancher an Karl Valentin erinnert fühlt: "Und plötzlich hat das Stück immer noch nicht angefangen".

Am Dienstag vor drei Wochen habe ich an die von der ARD angegebene Adresse meine Test-DVD geschickt, aber noch keine Antwort, nicht mal eine Empfangsbestätigung erhalten. Ich hoffe, bei der ARD hat man nicht im Glauben, es sei eine Briefbombe, die DVD in die Luft gesprengt.

Ich habe zwei weitere Emails an die ARD geschickt, eine mit dem Hinweis von dvb.matt, es könnte sich um einen Werteüberlauf handeln, und eine, weil mir nach dem Abschicken der DVD eingefallen ist, daß die Techniker vielleicht die 39 Filmchen einzeln brauchen und nicht zu neun Vob-Dateien zusammenkopiert. Deshalb habe ich ihnen per Email eine Tabelle nachgeliefert, welcher Film in welcher Datei beim wievielten Byte anfängt.
Für jede Emails habe ich eine Antwort bekommen, daß man meine Nachricht an die Technische Abteilung weitergeleitet hat, und dort habe man sich sehr gefreut.

Aber lieber bekomme ich erst spät eine Antwort, mit der man etwas anfangen kann, als gleich eine, die uns nichts nützt.

Richard Schmidt.

[Mongoo]

Hallo bin neu hier und bin auch Toshiba geschädigt!
Hat wer den Yamakawa 285 Vga und wie ist da die Lage?
Grün oder Ok?
Mfg Pipe

[RchdSchmidt]

Inzwischen habe ich nochmals an ARD Digital geschrieben und gefragt, ob ich ihnen mit einer CD helfen kann, die nur genau die benötigten Filme einzeln enthält, und gestern habe ich einen Telefonanruf aus Potsdam von ARD Digital bekommen, daß die Techniker dabei sind, die DVD zu testen und zu analysieren.

Aber ich kann mir schon vorstellen, daß das noch einige Zeit dauert. Denn so einfach scheint das Problem nicht zu sein.

Jedenfall glaube ich, daß das Problem ernst genommen wird.

Wenn ich wieder was erfahre, melde ich mich wieder.

Richard Schmidt.

[RchdSchmidt]

an Mongoo

Als ich meinen DVD-Spieler umgetauscht habe (beim Media-Markt), habe ich eine SVCD mitgenommen und dem Verkäufer gesagt, daß ich ein Gerät suche, das solche Scheiben problemlos abspielen kann. Dieser hat mir sofort angeboten, meine SVCD auf verschiedenen Geräten auszuprobieren, und so sind wir auf den Cyberhome 402 gekommen, bei dem die SVCD fehlerfrei gelaufen ist. Auch bei Saturn hat man mir Ähnliches angeboten.

Ich könnte mir vorstellen, daß auch der Yamakawa-Händler bereit wäre, das Gerät mit einer selbstgebrannten DVD auszuprobieren. Aber es sollte natürlich eine sein, die den Fehler wirklich bringt.

Ich glaube fast, jeder Händler spielt da gern mit, denn damit kann er sich hinterher einen Umtausch ersparen. Aber solche Händler, bei denen man die Geräte erst bestellen muß, werden es nicht ausprobieren können. Und diese werden vielleicht auch nicht zu einem Umtausch bereit sein. Also Vorsicht.

Richard Schmidt.

[TheHorse]

Da müsste man die Player stundenlang oder wenigstens solange testen, bis die VCD oder DVD "durch" ist. Mein Grundig spielt auf Anhieb auch alle VCDs und DVDs, nur ist bei den VCDs regelmäßig nach 10 - 20 Minuten bereits Standbild angesagt, bei den DVDs schaut's besser aus, da kommt das erste Standbild erst nach einigen Stunden Dauerbetrieb mit den Eigenbau-Scheiben.
Bei Aldi 2001, Sony 300 und 400-irgendwas (stehen in der Firma bei uns, allerdings mögen da viele nur CD-RW, keine CD-R) und Cyberhome laufen die Scheiben auch im Dauerbetrieb ohne Hänger.
Aber ich will jetzt keine neue Liste von Playern anfangen, nur sagen, dass man sich auf das kurze Antesten nicht immer verlassen kann.

[Mongoo]

Hab nun einen Yamakawa gekauft!
Geht astrein!
Kein grünen Klötzte!
:-))

[dvb.matt]

auf der 'andern Seite' gibts das Grünproblem wohl auch:
Forum (http://www.dtvforum.info/index.php?showtopic=5988)
Bildchen (http://web.1earth.net/~mhk01/IMG_1429.JPG)

[RchdSchmidt]

Vielen Dank, dvb.matt, für die Links. Ich habe mich gleich im australischen Forum registrieren lassen und denen kurz geschrieben, daß wir das Problem auch haben und was bisher rausgekommen ist.
Ich hoffe, es fühlt sich niemand durch meine Aktivitäten übergangen. Aber ich denke, wenn die wissen, wie bei uns der Stand ist, könnte vielleicht auch für uns eine interessante Anregung rauskommen.
Deshalb werde ich die Leute in Australien weiter informieren, auch über die bisherigen Versuche, Bilder, Vermutungen und Ergebnisse in unserem Forum.

Von der ARD habe ich schon länger nichts mehr gehört. Ich fürchte fast, das Problem ist selbst für deren Techniker eine harte Nuß.

Vielleicht sollte ich auch mal an Zoran schreiben.

Richard Schmidt.

[kstroe]

Hallo,

habe diesen Thread weiterverfolgt und immer noch gehofft,
daß die ARD sich dazu äußert. Das scheint ja wohl nicht der Fall
zu sein.
Ich bin mittlerweise Besitzer eines Aldi SA-Player geworden und der
macht nicht solche Anstalten.
Vielleicht gibts ja irgendwann die Lösung, aber nicht, wie in diesem Thread
von mir schon gepostet, von Zoran. (@Rchd.Schmidt)
Ansonsten fällt mir auch nichts mehr ein die ´grünen Klötzchen´
wegzubekommen als ein Neukauf eines SA-Players.
Da z.B. Toshiba mit Sicherheit neue Generationen von Playern auf
den Markt wirft, könnte es sein das der dann alle Formate abspielt.
Ansonsten kann man sagen, daß es mit Sicherheit manch einer
überlegt sich einen Toshiba o.ä. SA-Player zuzulegen, wenn er dieses
Forum durchgestöbert hat. (hoffentlich vorher :lol: )

[dvb.matt]

an andrer Stelle in diesem Thread hatt ichs ja schonmal angeregt:

jemand der das Problem und die HW+SW dafür hatt, sollte die geauthorte .VOB bereitstellen und genau dieselbe Sequenz mit einer analog-Karte gecaptured (mit 720*576 25fps) z.B. als AVI, abgespielt von einem der Problem-Spieler.

dann erst kann man direkt die Makroblöcke identifizieren und debuggen um den Fehler zu finden, auch ohne die ARD..

[RchdSchmidt]

Heute habe ich folgende Antwort von ARD Digital bekommen:

Sehr geehrter Herr Schmidt,

eine Ursache für die "Grünen Klötze" ließ sich noch nicht finden. Beim
letzten Treffen mit den Encoderentwicklern diskutierten wir das Problem.
Untersuchungen auf Transport- und MPEG Ebene mit verschiedenen
Analysatoren zeigten keine Auffälligkeiten und Fehler. Das Verhalten ist
äußerst merkwürdig!

Im nächsten Schritt versuchen wir Kontakt mit den DVD-Player Herstellern
aufzunehmen. Die grünen Klötzchen konnten wir auf den DVD-Playern
"Grundig GDP-1100" und dem "Toschiba SD-140E" nachvollziehen.

Für Rückfragen stehen wir Ihnen jederzeit gern zur Verfügung.
Darüber hinaus erreichen Sie unsere Hotline unter der Nummer 0180 / 500 14 95 (12 Ct./Min).

Mit freundlichen Grüßen

Ihr ARD Digital Team

Ich habe bereits geantwortet und darauf hingewiesen, daß jemand in unserem Forum vermutet, daß genau die Geräte betroffen sind, in die ein Zoran-Decoder eingebaut ist.

Richard Schmidt.

[AutoTest]

Ein Hallo an alle,

ich habe auch so einen SA-Player der grüne Klötzchen produziert und habe nicht schlecht gestaunt, als ich vorige Woche erstmalig auf das Problem gestoßen bin. Habe daher mit hohem Interesse diesen Thread durchgelesen und bin schon sehr gespannt, ob und wann die ARD die Ursache findet und uns bekanntgibt.

Falls dann Richard oder jemand anderer ein Schnellreparier-Programm dazu schreiben kann und Testmöglichkeiten gesucht werden, stehe ich gerne zur Verfügung. Ich lege mir dazu schon mal die Problemdatei zur Seite.

Bis dann also,
AutoTest

[RchdSchmidt]

Lieber AutoTest,

es wäre sehr interessant, ob der DVD-Spieler von Skymaster auch einen Zoran-MPEG-Decoder enthält. Wenn nein, würde das gegen die Therorie sprechen, daß nur Geräte, die einen Zoran-Decoder enthalten, die grünen Flecken zeigen.

Gruß
Richard Schmidt.

[AutoTest]

Hallo Richard,
hab meinen Skymaster-Player gleich mal aufgeschraubt, um nachzusehen. Ja, da ist ein Zoran-Chip drin.

Die genaue Bezeichnung lautet:
ZR36732PQC
B3 TSM2A0210SJ
Vaddis IVLC
Drunter ist dann noch das dts- und das Dolby-Digital Logo aufgedruckt.

Die Theorie "Nur mit Zoran hat man Zores" bleibt also weiter aufrecht. :mrgreen:

[AutoTest]

Lieber Richard,
könntest du bitte dein Schreiben an die ARD auch noch per e-mail an Zoran schicken: support@zoran.com

Oder eventuell samt Test-DVD per Post an
Zoran Germany Office
Dortmund GmbH
Hohe Strasse 28
Dortmund, Germany 44139
Tel: +49-231-914442-0
Fax: 49-231-914442-2

Vielleicht kommt von dort schneller ein Tipp, woran es liegen könnte und ob eine Reparatur der Videodateien denkbar wäre.

[RchdSchmidt]

Lieber AutoTest,

Vielen Dank für den Hinweis mit dem Zoran-Decoder. Ich hoffe, mit dem Nachschauen hast Du nicht die Garantie aufs Spiel gesetzt.

Eigentlich wollte ich ja an Zoran in den USA schreiben und ein kleines Stück (1 MB) fehlerhaften Film mitschicken, damit die vielleicht mit dem Debugger nach der Ursache suchen können. Allerdings bräuchte ich dann jemand, der mir ein solches getestetes Stück zur Verfügung stellt, denn ich kann es ja nicht testen, weil bei meinem Cyberhome der Fehler nicht kommt.

Aber ich kann natürlich auch an Zoran in Deutschland schreiben. Vielleicht haben die ja auch die Möglichkeiten, das Programm zu debuggen. Und vielleicht verstehen die mich besser als die in den USA, wenn ich auf Englisch schreibe.

Eine DVD möchte ich nur auf Anforderung hinschicken, weil das einiges an Porto kostet.

Gruß
Richard Schmidt.

Hast Du schon an Zoran geschrieben und die angegebenen Adressen in der Antwort bekommen?

[AutoTest]

Hallo Richard,
gute Idee mit dem Stückchen Film. Habe daher einen VIDEO_TS Ordner mit einem 2-Sekunden-Film erzeugt, den RTL gesendet hat (gezippt ist der Ordner ca. 1,3 MB groß). Mein Skymaster zeigt damit fast nur grün. Habe den Testfilm auch gleich per mail an den zoran support geschickt (mit englischer Fehlerbeschreibung). Mal sehen, was die dazu sagen. Werde berichten, sobald eine Antwort kommt.

Leider kann ich die ZIP-Datei hier wegen des 512KB-Kontingents nicht hochladen. Falls jemand die Datei haben möchte, bitte bekanntgeben. Ich mache sie dann über einen ftp-link zugänglich.

[RchdSchmidt]

Lieber Autotest,

da darf ich sicher auf dieses Filmstückchen verweisen, falls ich selber an Zoran schreibe. Dann kann ich mir die Übertragung sparen, denn ich habe nur ein analoges Modem, und da dauern zweimal 1,3 MB (einmal holen, einmal schicken) ganz schön lang.

Ich fürchte, die Antwort wird die selbe sein wie bei kstroe, nämlich daß sich der Zoran-Decoder ganz ganau an den DVD-Standard hält. Dem möchte ich gern vorbeugen und Zoran darauf hinweisen, daß alle DVD-Spieler, die ihren Decoder eingebaut haben, die einzigen sind, bei denen DVB-Aufnahmen nicht funktionieren und daß sie ihre Kunden daran hindern, für deren Kunden Geräte zu bauen, mit denen man solche Aufnahmen spielen kann, und daß sich das eines Tages für die Herstellerfirmen nachteilig auswirken könnte. Vielleicht denken sie sich dann, daß es einfacher ist, nach der Ursache zu schauen, als sich darauf eine Ausrede einfallen zu lassen.

Gruß
Richard Schmidt.

[dvb.matt]

@Autotest
hast du eine analog Capturekarte, womit du die 2 sec. vom DVD Spieler gespielt (keine Screenshots) wieder aufzeichnen kannst (in 720*576 und mjpeg/divx o.ä.) ? (s.o. (http://forum.dvbtechnics.info/viewtopic.php?p=6162#6162))

das zusammen mit dem vorh. 1,3MB VOB Schnipsel würd mich schon interessieren.

geht das nicht, nutzt leider auch das VOB Stück nix..

bislang konnte oder wollte niemand solche Daten beisteuern, sodass wir nur 'hilflos' zusehen können und auf 'höhere Stellen' angewiesen sind..

[kstroe]

Hallo,

ich hätte da noch eine alte Elsa Erazor mit Video in Eingang.
Leider muß ich den Rechner erst wieder "aktivieren".
Soviel ich weiß schafft der aber nur 320x240 oder so,ist ein alter Celeron
Rechner. Das Problem war "damals" zuviele dropped frames bei größerer
Auflösung.
Ich probier es mal, kann aber noch was dauern bis ein Ergebnis vorliegt.

[AutoTest]

@dvb.matt
Eine ELSA Erazor hab ich auch und sehe die gleichen Schwierigkeiten wie kstroe. Könnt's auch mit dem Video-Eingang meiner analogen Hauppauge WinTV probieren. Am besten gefällt mir aber noch folgendes:
Ich werde den SVHS-Ausgang des DVD-Players an meine Videokamera (Sony PC120E) anschließen. Die kann analoge Signale in Echtzeit in DV wandeln und dann digital per Firewire an den PC übertragen. Damit krieg ich den Testfilm in bestmöglicher Qualität wieder in den PC. Das Bild hat dann auf jeden Fall 720x576 pixel. Trotzdem wird durch das analoge Signal zwischen Player und Kamera ein bisschen verloren gehen und vermutlich wird die exakte Position des Bildes nicht mehr mit dem Original übereinstimmen, da bei der analogen Ausgabe oben/unten/links/rechts vielleicht etwas weggeschnitten wird oder hinzukommt. Auch weiß ich nicht wie es mit der horizontalen Linearität aussehen wird. Pixelgenau ist die wahrscheinlich auch nicht. Außerdem macht die Kamera Halbbilder, was möglicherweise zusätzliche Artefakte ergibt.
Naja, ich mach's mal und dann sehen wir weiter, ob du etwas damit anfangen kannst. Melde mich wenn ich's fertig hab...

@kstroe
Sehr interessant wäre auch, ob dein Player mit meinem Testfilm das gleiche grüne Muster erzeugt, es also nicht irgendwie zufällig ist sondern von allen Zoran-Chips gleich falsch dargestellt wird. Werde dazu meine Dateien per ftp-link downloadbar machen. Geht aber erst am Montag.

[dvb.matt]

Video-Eingang meiner analogen Hauppauge WinTV probieren
absolut möglich, selbstverständlich auch die Sache via DV.
Die CaptureAuflösung sollte jedenfalls nicht kleiner sein als das Original.

Quali wäre nicht soo wichtig, weil 'grün' sticht ja ins Auge, und das so arg, das alle anderen 'Ungenauigkeiten' nicht so ins Gewicht fallen..
(via S-Video und DV-in sollten die 'Farbverwaschungen' zudem geringer ausfallen)

Anhand des orig. VOB's sollte sich dann aber im Capture sowohl der passende Frame als auch Y-Block wiederherstellen/skalieren lassen.

[AutoTest]

Der Testfilm ist fertig und kann von hier abgeholt werden:

ftp://autotest@195.202.155.218/root/

TEST.ZIP ist knapp 1,9MB gross und enthält den VIDEO_TS Ordner und die Datei TEST.AVI (mit DIVX 5.0.5 encodiert, ohne Ton).
(Anm.: Man sollte meinen, dass DIVX optimal komprimiert, aber der verlustfreie ZIP kann die 663KB-AVI noch weiter auf 477KB schrumpfen :shock:)

@dvb.matt
Wie ich befürchtet habe, entspricht das Capture nicht ganz dem Original. Bin schon gespannt, ob du damit was anfangen kannst. Am interessantesten ist wahrscheinlich das Stück in der Mitte, wo nach dem Schnitt der Typ mit dem Zylinderhut auftaucht. Da zieht sich das Grün etwas zurück um ein zwei Frames später wieder voll zurückzukommen.

[rfra400]

ich möchte einen weiteren Player der Liste hinzufügen.
Ich habe ein DVD / VR Kombi Geraet ORION DVD/VR 2961X
mit Zoran chip und gruenen Kloetzchen bei meinen DVB Aufnahmen.

Dabei habe ich zwei unterschiedliche Ausprägungen einmal erscheint die gesamte bildschirm grün, wird aber im bereich von Bewegungen in den richtigen Farben wieder sichtbar.

Bei anderen Aufnahmen erscheinen die Klötzchen im Bereich von (starken) Bewegungen.
Ich verfolge das Forum schon seit ein paar Wochen und hoffe immer noch auf eine Lösung durch anpassen des DVB streams.

Uebrigends ist irgend jemand das Editorial der c't 14/2004 aufgefallen?
http://www.heise.de/ct/04/14/003/
Zitat:
Selbst digitale Fernsehprogramme nagen kaum am Verkauf alter Kinofilme auf DVD: Obwohl die Filme bereits hochwertig komprimiert im MPEG2-Format ausgestrahlt werden, trifft der DVD-Fan auf wirkungsvolle Fußangeln: Die Sendeanstalten erhöhten einfach die Größe der Group-of-Pictures, sodass der Fernseh-MPEG-2-Strom erst stundenlang neu kodiert werden muss, damit die DVDs auch wirklich auf allen Playern spielen.

Gruss und Hochachtung für das bisher Geleistete

[dvb.matt]

@Autotest
die Quali ist IMO ausreichend, werd mal die nächsten Tage mit rumspielen..

zu c't:
der Erhöhung der Frames per GOP geschieht IMHO nicht mit der Absicht, den Grabbern Müh und Not zu bescheren..
(dafür sind wir einfach zu wenig :wink: )

[AutoTest]

Anmerkung zum Editorial der c't 14/2004:
Wie ich die grünen Klötzchen zum ersten Mal gesehen habe, habe ich auch an neue Kopierschutzmaßnahmen gedacht. Dagegen spricht aber, dass die ARD offensichtlich ahnungslos war und dass das Problem vermutlich auf Zoran-Chips beschränkt ist. Außerdem müsste ein Kopierschutz als solcher deklariert werden, wenn man verhindern will, dass ihn jemand umgeht.
Bislang war es völlig legal, gesendete Fernsehprogramme für privaten Gebrauch aufzuzeichnen und wiederzugeben. Daran hat die Erfindung von DVD-Brennern nichts geändert. Somit dürfte sich der absichtliche Einbau von Kopierschutzmaßnahmen für einen Sender auch gar nicht lohnen.

Was wir daher sehen (auch das mit den überlangen GOPs) sind m.E. technische Unzulänglichkeiten bzw. Notwendigkeiten.

[RchdSchmidt]

Der Kinderkanal gehört zu den Sendern, die auf allen Spielern einwandfrei laufen. Beim Kinderkanal bekomme ich aber von PVAStrumento immer eine Unmenge überlanger GOPs gemeldet (wenn ich mich richtig erinnere, sind es bei einem 25-Minuten-Film an die 100).
Deshalb glaube ich nicht, daß diese stören.

Gruß
Richard Schmidt.

[Wrzlbrnft]

Falls es etwas hilft, auch der SEG 430 DVD erzeugt diese Grünklötzchen-Bildung bei Aufnahmen von genannten Sendern. War heute leicht erschrocken und enttäuscht, als ich in diesen Player eine DVD mit SuperRTL- und RTL-Aufnahmen eingelegt hatte und mir ein fröhlicher Grünstich ins Gesicht sprang. Noch dazu, weil ich auf anderen (ebenfalls Billigst-)DVD-Playern keinerlei solche Probleme hatte.

Aufnahmen der ZDF- und ProSiebenSAT.1-Sender machten, wie hier bereits bekannt, keinerlei Probleme.

[RchdSchmidt]

Lieber Wrtlprmff,

ein Spezi von mir hat auch einen DVD-Spieler von SEG, aber der spielt meine DVDs einwandfrei, auch die von Arte aufgenommenen. Ist allerdings schon eineinhalb Jahre alt. Vielleicht ist ja SEG vor kurzem auf Zoran-Decoder umgestiegen. Wäre interessant, ob der Spieler einen Decoder von Zoran hat. Steht darüber etwas in den Technischen Daten? Aber bitte das Gerät nicht öffnen!

Übrigens, ich habe vor einer Woche von ARD Digital eine Nachricht erhalten, daß sich derzeit die Hersteller sowohl der Encoder als auch der Decoder bemühen, das Problem zu klären.

Richard Schmidt.

[Wrzlbrnft]

Leider gibt die Bedienungsanleitung keinerlei Informationen über den Decoder preis. Die Störungen sind sich jedoch exakt dieselben, wie in diesem Thread von verschiedenen Seiten beschrieben. Grüne Pixel und Quadrate an den jeweiligen Stellen mit starken Bewegungen, die auch gerne mal das ganze Bild einnehmen können, einwandfreies Bild nur bei den Keyframes/I-Frames. Und betroffen sind ebenfalls "nur" die genannten Sender (deren Programme ich aber eben trotzdem ganz gerne mitschneide :? ).

[AutoTest]

Nachdem ich letzte Woche bei Zoran urgiert habe, bekam ich gestern endlich eine "Antwort". Die haben sich das Testvideo noch nicht mal angesehen. Statt einer brauchbaren Information kam nur eine Rückfrage nach dem Hersteller des Players.
Na gut, habe ich also die entsprechenden Daten zurückgemailt und werde weiter geduldig warten (mache jetzt erst mal bis 8. August Urlaub in Kroatien)... :|

Richard hat recht, man wird etwas Druck machen müssen, um von Zoran eine Hilfe zu bekommen.

[crashpat]

Hallo Leute

Ich bin der Heinz, 36 Jahre alt (alter Knochen) und aus Gegend Altötting (80km östlich München).
Ich bin ja direkt erleichtert dass ich nicht der einzige bin mit diesem Klötzchen Problem, dachte schon ich würde mich zu blöd anstellen.

Also.... Problem tritt bei mir auf bei RTL, RTL2,SuperRTL, VOX und ARD.
Mein SA ist ein alter XORO (glaub sogar der erste) AEP-810.
Der sollte auch den Zoran drin haben wenn mich nicht alles täuscht.

Vorgehensweise: aufgenommen mit versch, Programmen (auch ProgDVB)
PVAStrumento demuxt, MPEG2schnitt geschnitten, TMPEGEnc DVD Author auf die DVD-------> Klötzchen

Probiert mit TMPEGEnc 2.5 neu zu encoden und dann ins Authoringprog.
--------> keine Klötzchen aber Video und Audio nicht mehr synchron.

Probiert vor dem demuxen mit TMPEGEnc Source Creator die ganze Datei zu bearbeiten. Der Creator bemängelt die Datei hätte kein Audio ????
Dann war ich erst mal am Ende.

Würde das gerne mal testen mit dem VBV verändern , das Projekt X macht mir aber Schwierigkeiten in der Handhabung.
Könnte mir nochmal einer auf die Sprünge helfen bitte?

Viele Grüße

[RchdSchmidt]

Lieber Crashpat,

mit ProjectX kann ich auch nicht weiterhelfen, ich habe es auch schon aufgegeben. Aber ich habe vor ein paar Monaten ein simples Kommandozeilenprogramm in C geschrieben, das in .vob-Dateien (und nur in solchen) die VBV-Puffergröße von 96 in 112 ändert und sonst alle Werte unverändert läßt. Einige haben es auch ausprobiert, aber bei keinem hat es eine Besserung gebracht. Aber einer mit einem Mustek-DVD-Spieler hat geschrieben, daß er die VBV-Puffergröße mit ProjectX geändert hat, und die Flecken waren weg. Ob das dann immer so war, weiß ich leider nicht.

Ich habe schon versucht, das Programm per Email zu schicken, aber ich habe im Profil keine Adresse gefunden.

Bei Interesse könnte ich das Programm aber komprimieren und hier im Forum zum Herunterladen bereitstellen.

Übrigens, ich wohne zehn Kilometer südlich von München.

Gruß
Richard Schmidt.

[crashpat]

Danke für die Antwort.
Dieser dämliche Klötzcheneffekt ist wirklich sowas von lästig.
Dann werden wir wohl damit leben müssen. Wer weiß vielleicht ergibt sich noch was.

Trotzdem danke

[RchdSchmidt]

Lieber Crashpat,
einige haben mein Programm, mit denen man in .vob-Dateien die VBV-Puffergröße 91 durch 112 ersetzen kann, bereits ausprobiert.
Leider hat die Änderung dieser Größe bei den meisten nichts gebracht.
Für diejenigen, die es trotzdem mal versuchen wollen, stelle ich das Programm samt Quellprogramm hier zum Herunterladen bereit - mit dem Hinweis, daß das selbe Ergebnis auch mit ProjectX erreicht werden kann.
Da mein Programm keine Bedienoberfläche hat, ist es auch sehr einfach anzuwenden: Lediglich das Icon der Vob-Datei oder des Ordners, der die Vob-Dateien enthält, auf das Icon fürs Programm ziehen.
Aber Vorsicht: Die Originaldatei wird direkt geändert, also ggfs. vorher eine Kopie anlegen!

Auch wenn ich mir nicht vorstellen kann, daß damit das Problem beseitigt wird, würde ich mich über eine Rückmeldung freuen.

Gruß
Richard Schmidt.

[crashpat]

OK. Alles klar. Ich werd das mal testen und dann Rückmeldung geben.

Danke

[crashpat]

Habs gleich getestet, aber schade das wars leider nicht.

Jetzt ist das ganze Bild grün und bei Bewegung werden die bewegten Stellen leicht besser.

Muss doch noch was anderes sein.

Bis bald

[RchdSchmidt]

Lieber Crashpat,

darf ich den Satz "Jetzt ist das ganze Bild grün" so verstehen, daß sich nach Ändern der VBV-Puffergröße doch etwas geändert hat, wenn auch zum Schlechteren?

Gruß
Richard Schmidt.

[crashpat]

Ja genau so ist es. (bei mir)

Vorher war das ruhige Bild in Orndnung (soweit jedenfalls) und bei Bewegung entstanden die grünen Klötze.
Jetzt war von Anfang an der ganze Bildschirm grün, und bei Bewegung konnte man die Umrisse der Personen erahnen (wenn auch sehr dürftig.)

Beste Grüße

[RchdSchmidt]

Lieber Crashpad,

vielen Dank, das ist sehr interessant. Wenn es möglich ist, durch Ändern der VBV-Puffergröße die grünen Stellen zu vermehren, dann könnte es ja vielleicht auch möglich sein, durch geschickte Kombination von VBV-Puffergröße und VBV-Delay die grünen Stellen zum Verschwinden zu bringen.

Leider kann ich nicht gut damit experimentieren, weil mein DVD-Spieler nie die grünen Klötze bringt.

Übrigens kann man mit meinem Programm auch ganz leicht wieder die VBV-Puffergröße auf 91 zurückstellen, falls man keine Kopie vom Original mehr hat, indem man dies als Aufrufparameter mitgibt. Allerdings klappt das dann nicht, wenn sich die VBV-Puffergröße mitten im Film geändert hat. Aber das habe ich noch nie erlebt.

Richard Schmidt.

[AutoTest]

Hallo, ich bin vom Urlaub zurück und fand wieder eine "Antwort" von Zoran im e-mail Postfach. Darin wird leider nur mitgeteilt, dass die von mir zur Verfügung gestellte Testdatei ein DIVX-File ist and daher auf meinem Player nicht abspielbar ist. Den VIDEO_TS Ordner mit der VOB-Datei haben die offensichtlich glatt übersehen! :x
Hab gleich zurückgeschrieben und nochmal erklärt was alles in der ZIP-Datei ist. Na immerhin erkennt man jetzt schon den guten Willen von Zoran, sich die Sache anzusehen.

@RchdSchmidt:
VBV-Delay? Kannst du dein VOB-Modifizierprogramm mal so abändern, dass man VBV-Buffer und VBV-Delay per Eingabe oder Commandline festlegen kann? Ich würd das gerne ausprobieren. Gibt's da vielleicht noch andere Parameter, mit denen man experimentieren könnte?

[RchdSchmidt]

Lieber Autotest,

eigentlich hatte ich sowieso vor, mein Programm entsprechend abzuändern und bereitzustellen. Ich muß aber erst suchen, wo genau der VBV-Delay steht. Leider bin ich in den letzten Tagen nicht dazu gekommen. Aber vielleicht mache ich eine Vorabversion, die nur den VBV-Delay ändert, so daß man immer beide Programme aufrufen muß, also einsfür die Puffergröße und eins für den VBV-Delay, bis ich dazu komme, beides in ein Programm zu integrieren.

Übrigens habe ich eine Kopie des Programms so abgeändert, daß man statt der VBV-Größe damit das Seitenverhältnis in allen GOPs auf 16:9 umstellen kann. Andere Parameter werden nicht geändert, im Gegensatz zub DVDPatcher, der zwangsweise auch die Bitrate ändert. Und man muß auch nichts in die Registry eintragen, wie beim AVEstensione. Allerdings steht im Quellprogramm überall noch vbv statt Seitenverhaeltnis, das muß ich erst noch ändern, wenn ich viel Zeit habe. Aber das ist nur ein Schönheitsfehler. Wenn jemand daran Interesse hat, könnte ich auch dieses Programm zum Runterladen bereitstellen.

Richard Schmidt.

[AutoTest]

...vielleicht mache ich eine Vorabversion, die nur den VBV-Delay ändert, so daß man immer beide Programme aufrufen muß...
Kein Problem. Mach's so einfach wie möglich. Es geht ja zunächst nur darum herauszufinden, ob damit überhaupt eine Verbesserung möglich ist.

...statt der VBV-Größe damit das Seitenverhältnis in allen GOPs auf 16:9 umstellen kann.
Ich würde auch das testen. Hoffe allerdings, dass es keinen Einfluss hat, denn einfache Umstellung auf 16:9 ohne Neukodierung erzeugt sicher ein verzerrtes Bild.

[RchdSchmidt]

Lieber Autotest,

ich habe mir mal mit VobEdit angeschaut, wo die Information über den VBVDelay steckt, und gesehen, daß diese nicht in den GOPs, sondern in jedem einzelnen Bild steckt. Damit ist es leider nicht in einer oder zwei Stunden zu machen. Ich habe es immer noch vor, aber es kann sich noch eine Zeit hinziehen.

Aber es müßte auch mit Restream möglich sein. Ich habe mir mal ReStream heruntergeladen, konnte es aber nicht gefragmentieren. Vermutlich ist bei der Übertragung ein Fehler aufgetreten. Aber irgendwann möchte ich es mir nochmals holen, denn soweit ich in Erinnerung habe ist es auch ein Kommandozeilenprogramm, und die habe ich besonders gern, weil man sie so bequem automatisieren kann.

Zu 16:9
Filme im 16:9-Format werden auf unterschiedliche Weise ausgestrahlt. Alle Privatprogramme und die meisten Dritten Programme strahlen einfach 4:3 mit schwarzen Balken oben und unten aus. Aber das Bayerische Fernsehen, BR-Alpha, zum großen Teil 3Sat, ARD und ZDF strahlen echte 16:9-Filme aus, bei denen das Bild auf alle 576 Zeilen verteilt wird, und dazu wird eine Kennung gesendet, daß das Format 16:9 ist. Oft wird aber die Kennung "16:9" vergessen, vor allem bei 3Sat. Oft wird erst kurz nach Beginn des Films von 4:3 mit Streifen auf 16:9 umgeschaltet, so daß die ersten Bilder noch die Kennung 4:3 haben. Aber gelegentlich bleibt die Kennung 4:3, obwohl der Film 16:9 ist und formatfüllend gesendet wird. Läßt man einen solchen Film auf 4:3, dann sind die Filme in der Höhe verzerrt. In diesem Fall muß man die Angaben in den GOP-Headern auf 16:9 umstellen. Dafür ist mein Programm. Es soll auf keinen Fall auf 16:9-Filme, die im Format 4:3 ausgestrahlt werden und bei denen die schwarzen Streifen zum Bild gehören, angewendet werden.

Ich werde das 16:9-Programm in den nächsten Tagen bereitstellen. Vorher möchte ich noch einbauen, daß man als Aufrufargument auch 3:4 angeben kann (bisher muß man dazu ein Zahl angeben, ich glaube, es ist 2), um die Aktion wieder rückgängig zu machen.

Gruß
Richard Schmidt.

[Groundskeeper Willie]

Hallo Richard,

ich verfolge die Diskussion über das Grüne-Klötze-Problem auch schon eine ganze Weile und habe selbst schon einiges ausprobiert, allerdings ohne Erfolg. Zum Thema VBV-Delay hoffe ich, Dir etwas helfen zu können.

Zuerstmal eine Beobachtung:
Die österreichischen Sender der RTL-Gruppe (zumindest RTL2 und VOX) lassen sich auf meinem Billigplayer (Mustek DVD-V600R Receiver) problemlos abspielen, die deutschen nicht.

Meinen Beobachtungen am Beispiel VOX zufolge kommen bestimmte Parameter bei beiden Streams vor (deutsch und österreichisch), z. B. die Existenz einer Sequence Display Extension, das Reinladen benutzerdefinierter Quantisierungsmatrizen pro I-Frame via Quantization Matrix Extension (kommt bei VOX Austria vor, bei RTL2 Austria nicht), die Verwendung der Cropped-D1-Auflösung (704x576) bei VOX Austria (bei allen anderen 720x576). Die Austriakanäle senden VBV-Size 112, die deutschen 91. Wie schon festgestellt, hilft das aber auch nicht viel. Diese Parameter scheinen aber alle nichts mit den grünen Klötzen zu tun zu haben.

Dann bin ich auf den Trichter mit dem VBV-Delay gekommen. Bei einer VOX Austria-Sendung war nämlich für den VBV Delay nicht etwas 0xFFFF eingestellt, sondern pro Frame ein nichtkonstanter Wert, während der entsprechende deutsche VOX-Stream auf 0xFFFF lief. Die ISO13818-2 liefert bei das Standard-Buffer-Modell eine Berechnungmodell für den VBV-Delay (abgeleitet aus der momentanen Bitrate), die hab ich allerdings nicht verwendet habe, sondern einen konstanten Wert, gemessen in 1/90000 sec-Bruchteilen (vgl. Annex C).

Wenn man sich diesen VOX-Austria-Stream im Bufferanalyzer des Analyseprogramms MProbe ankuckt, sieht man, daß der Puffer auf diese Art und Weise niemals volläuft (Abb. 1). Bei dem dt. VOX-Stream mit VBV-Delay 0xFFFF (bei MProbe als "VBR Stream" angegeben) hingegen läuft der Puffer voll, und es dauert wieder einen Frame, bis er entleert wird (Abb. 2). Da hilf es auch nichts, die VBV Size hochzusetzen (die Pufferfüllung wird links angezeigt in KByte, vgl. vbv_buffer_size*16384/8=Puffergröße in Byte), s. Abb. 3.

Also hab ich ein kleines Programm geschrieben (bitte nicht schlagen, schrecklichste Qualität, nur als Proof-of-Concept gedacht). Vorneweg: Es schafft auch nicht Abhilfe. Das Programm scannt einfach den Stream stupide noch dem Picture Header anhand des picture_start_code 0x00000100 durch und modifiziert die entsprechenden Bits im Picture Header. Auf ein weiteres Parsen hab ich verzichtet, in meinen 10MByte großen Testschnipseln haben sich beim anschließenden Streamparsen und Fehlerfinden in MProbe aber auch keine Fehler ergeben. Die Anzahl der Frames wurde richtig erkannt, 0x00000100 ist wohl als Sequence viel zu auffällig und somit hinreichend eindeutig.

Das Programm vbv_delay.c habe ich mal an das Posting, da nur 3 Attachments zugelassen werden. Der vbv_delay ist festeinkompiliert, der Dateiname und die Dateigröße auch (Inplace-Bearbeitung).

Falls Du möchtest, kannst Du mit den Ideen was ordentliches draus machen, z. B. den Wert von vbv_delay nicht konstant lassen, sondern gemäß den STD-Buffermodell berechnen.

Das Problem ist nur: Es hilft nicht.
Der Stream von Abb. 2/Abb. 3 sieht jetzt zwar im Bufferanalyzer auch so aus wie der von Abb. 1, nur die grünen Klötze kommen immer noch.

Ich vermute wirklich - wie dies schon an voriger Stelle geschehen ist -, daß es sich um ein Problem auf Macroblockebene handelt und mit dem Puffer nichts zu tun hat. Aber vielleicht helfen Dir die Ansätze etwas weiter, und Du probierst noch etwas rum.

VOX Austria/deutsches VOX sind zur Analyse übrigens sehr gut zu gebrauchen, da sie das gleiche Programm senden, allerdings aufgrund der verschiedenen Werbefenster meistens leicht zeitversetzt. Wenn man nun sich eine größere Menge Clips erstellt und diejenigen rausfischt, bei denen I-Frame auf I-Frame fällt, kann man sehr gut einen 1:1-Vergleich machen, gerade auch auf Macroblockebene. Dazu dann noch den framegegrabbten Ausgang des DVD-Players... Ich bin eigentlich immer noch davon überzeugt, daß man die Sache beheben kann. Eventuell müßte man sich dazu noch etwas Know-How über MPEG2 auf der untersten Ebene aneignen, z. B. aus den ReJig-Sourcen. Neucodieren ist nun wirklich die schlechteste Lösung und "schmeckt" mir überhaupt nicht. Leider fehlt mir die Zeit dazu... ;).

P. S.: Nicht nur zur Stream, sondern auch zur Macroblockanalyse ist MProbe perfekt geeignet. Leider gibt's das Programm nicht mehr zu kaufen, da der Hersteller Interra übernommen wurde, aber vielleicht kann man es ja mal auf dem Rechner eines Bekannten, der es zufällig hat, benutzen ;). Näheres auch per PM.
Ich glaube, es gibt nichts besseres zur Analyse (ist m. E. besser und vor allem leichter zu bedienen als MPEGRepair von Pixeltools).

P. P. S.: Brauchst Du die ISO13818-2 noch?

Grüße, G. W.


vbv_delay.c:

#include <stdio.h>
#define VBV_DELAY 20000

int main(int argc, char *argv[]){
char buffer[8];
char pict_h[8];

FILE *mpegfile;

long c=0;
long pos=0;
mpegfile=fopen("i:\\test.m2v", "r+b");

for (pos=0; pos<20508220; pos++){
fseek(mpegfile, pos, SEEK_SET);

fread(buffer, 1, 8, mpegfile);
if (buffer[0]==0x0 && buffer[1]==0x0 && buffer[2]==0x1 && buffer[3]==0x0){
c++;
pict_h[0]=buffer[0];
pict_h[1]=buffer[1];
pict_h[2]=buffer[2];
pict_h[3]=buffer[3];
pict_h[4]=buffer[4];
pict_h[5]=(buffer[5]&0xF8)|(((short)VBV_DELAY)>>13);
pict_h[6]=(unsigned char)(VBV_DELAY>>5);
pict_h[7]=(((unsigned char)VBV_DELAY)<<3)|(buffer[7]&0x7);


fseek(mpegfile, pos, SEEK_SET);
fwrite(pict_h, 1, 8, mpegfile);

}
}
printf("%d Picture Headers modified.\n", c);
};

[RchdSchmidt]

Lieber Groundskeeper Willie,

vielen Dank für die Informationen. Ich werde sicher einige Zeit brauchen, um alles zu verdauen.
Aber vorab noch eine Anmerkung: RTL, Super RTL und vermutlich auch RTL2 Deutschland senden erst seit Mitte April dieses Jahres mit einer Horizontalauflösung von 720 Punkten. Zuvor haben auch diese mit 7z04 Punkten gesendet. Aber damals ist das Problem ebenfalls schon aufgetreten.
Nur in einer ziemlich alten Aufnahme aus Super RTL, wo die VBV-Puffergröße noch 112 war, ist der Fehler noch nicht zu beobachten. Er scheint also mit den neuen Encodern, die die VBV-Puffergröße 91 benützen, eingeschleppt worden zu sein.

Gruß
Richard Schmidt.

[dvb.matt]

hallo, werd auch wieder mal ein paar Fakten/Ergebnisse einstreuen:
(anhand der Daten von @AutoTest, RTLdeu)

1) der erste I-Frame im ersten GOP ist bereits zu 99% grün, es ist ein closed GOP, der (VBV) Buffer sollte praktisch leer (neu initialisiert) sein
2) die folgenden B,P-Frames müssen zwangsläufig an den Stellen grün bleiben, wofür es keine neu übertragenden Blöcke gibt (ausserdem verschobene Blöcke zu beachten)
basics:
3) Initialisierung der Framepuffer in YUV mit Y = 128, U + V = 0 ergibt das bekannte 'matte' grün. ( U & V = 128 ergäbe erst einen Grauton entspr. Y, wenn man davon ausgeht, dass 128 die Nullstelle ist und U & V bei der Wandlung nach RGB mit Werten von +/-128 gerrechnet werden, o.a. Init-Wert also eigentlich -128 bedeutet)
4) Decodierung der 4 Y - Blöcke je einschl. unmittelbar anschliessender Addition mit o.a. Init-Wert für Y
5) Decodierung von 1* U & V Block (MPEG4:2:0) und Ermittlung der RGB Werte je Pixel aus nun komplett vorliegender Luminanz und Chrominanz
merkwürdigkeiten:
6) das parsen aller Blöcke scheint unkritisch, denn es sind ,wenn auch nur schemenhaft, die Umrisse bis in den letzten Pixel lagerichtig zu erkennen
7) die IDCT funzt auch, andernfalls würden die Schemen nicht als solche erkennbar sein (nur Pixelmisch jeweils an der linken Ecke je Block)
Frage also, warum bleibts grün:
8) der rekonstruierte Y - Wert je Pixel ist zu gering (soll +/- 128 s.o.), was aber den doch tlw. deutlichen Schemen widerspricht.
meine Tests habe das auch nicht bestätigt, es waren wenn überhaupt nur ein paar Pixel ausserhalb des üblichen Bereichs 16..235 bzw. eben 0..255.
dennoch sind die Schemen IMHO eigentlich noch zu 'schwach'
9) eher denkbar und IMO der Ansatzpunkt, die dekodierten U + V Blöcke liefern 0 (siehe 3), das ergäbe genau den Effekt.
die Blockanalyse im Decoder Model zeigt jedoch die korrekte Encodierung mit 128 (zumindest wird hier der Wert so zurückgegeben)
die Wandlung YUV -> RGB ist daher auch i.O. (nur nicht beim Zoran), sicher ermittelbar in den Letterboxstreifen (wo U & V 128 sein sollen)
10) bei den wenigen Blöcken, die aus dem Grünen normal hervorstechen, konnte ich bislang keine besonderen Abweichungen (bei den veränderlichen Variablen) zu den benachbarten grünen Blöcken feststellen.
sie sind schlicht identisch (leider..)
11) ein ähnlicher Effekt bzgl. bestimmter Blöcke lässt sich provozieren, wenn man die Blöcke auslässt (denen man einen imaginären Fehler zuschreibt), deren Werte ein festgelegtes Maximum des 'quantizer_scale' überschreiten.
leider sieht es eben nur ähnlich und beschreibt nicht das grün-Phänomen.

man sollte also m.E. bei 9) weitersuchen, was genau mit den 2 Chromablöcken beim Parsen geschehen 'könnte'.
einem (VBV) Pufferproblem im allgemeinen spricht dagegen, dass halt manche Blöcke mittendrin stimmen, und das die Y - Schemen im ganzen Bild erkennbar sind, das parsen und die IDCT also auf alle Blöcke angewandt wird

12) desweiteren sieht es danach aus, als wenn von den I-Frames (bis auf das Letzte im Vob-Bsp., wo die ja scheinbar immer um ein Halbbild überlappen) keines wiederhergestellt wird (weder Y noch U,V). Die 'Schemen' stammen IMO einzig von den übertragenen Y-Differenzwerten aus den dazwischenliegenden B-/P-Frames (ausgehend vom Mittelwert 128) und sind daher nur 'undeutliche Umrisse'.

[AutoTest]

Vielen Dank an alle, die bisher schon versucht haben, das Problem zu analysieren. Es gibt also offensichtlich nichts, was man als Problem-Auslöser leicht ausmachen könnte. VBV-Buffer dürfte es nicht sein (was diverse Tests bestätigten), Daten der Grün-Blöcke und der Normal-Blöcke unterscheiden sich nicht von einander, ...

Sieht so aus, als ob die gesuchte Problemstelle in den MPEG-Daten doch nur durch debuggen eines Zoran-Chips zu finden ist. Von Zoran kam in den letzten zwei Wochen leider noch keine Antwort. Habe heute wieder mal ein Erinnerungs-mail geschickt...

Um die Stelle die das Problem auslöst, zumindest einzugrenzen, habe ich folgenden Vorschlag:
Ich werde das kleine Testvideo mit TmpgEnc neu encodieren, was ja eine problemlos abspielbare Datei erzeugt. Danach würde ich gerne Teile des Tmpgenc-Films mit Teilen des Original-Films vermischen und dann nachsehen, ob der Fehler weg ist oder bleibt. Also z.B. die Header von TmpgEnc verwenden, aber die original Bilddaten. Wenn dann z.B. kein Fehler ist, die Header schrittweise wieder auf die Original-Header zurückpatchen bis der Fehler wieder kommt. Solange, bis der Auslöser eingegrenzt ist.

Brauche dazu aber eure Hilfe, da ich keine Ahnung habe, was man in VOB (bzw. MPV)-Dateien sinnvoll miteinander bzw. unabhängig voneinander austauschen kann und vor allem wo in den Dateien das alles steht. Ein entsprechendes Programm dazu könnte ich mir wahrscheinlich schon selbst basteln, ich brauche aber eine genaue Anleitung. Wer kann und will mich dabei unterstützen?
Vielleicht stell ich's mir auch zu einfach vor. Bitte um eure Meinung.

[Groundskeeper Willie]

Na klar, da wär ich dabei.

Ich bin nur momentan noch sehr im Klausurenstreß.
Das ist eigentlich ein ziemlich guter Ansatz, den Du da entwickelt hast. Es gibt jedoch einige Dinge zu beachten, so müssen z.B. die GOP-Längen und die IBP-Folgen gleich sein. Am besten wäre es wohl, einen Stream mit den exakt gleichen Parametern zu kodieren wie der DVB-Stream. Es gibt übrigens noch eine ganze Reihe weiterer Parameter außer den "bekannten" in den Sequenzheader, die sich allerdings nur in Spezialprogrammen wie MProbe anzeigen lassen.

Zu Deiner Frage, wie einfach das ist:
Also Grundlage für alles ist auf jeden Fall eine Einführung in die MPEG-Kodierung, gut sind z. B. die entsprechenden Kapitel aus Reimers "Digitaler Fernsehtechnik" oder Poyntons "Technical Introduction to digital video" bzw. dem Nachfolger "Digital video & HDTV". Es gibt aber noch ne ganze Reihe anderer Bücher, die sich mit Bewegtbildcodierung beschäftigen. Im Netz sollte auch was zu finden sein (als schnelle Einführung z. B. http://people.ee.ethz.ch/~ambraun/sa1/kapitel2.html).

Der nächste Schritt nach dem Grundlegenden ist dann die schon erwähnte ISO/IEC 13818-2. Da steht alles wichtige drin.

Vielleicht stelle ich mir das auch alles zu einfach vor, aber die Bitstreamsyntax sollte gar nicht so schwer sein. Jedes Element (ob Sequence Header, GOP-Header, Macrobock, etc.) hat einen eindeutigen Startcode von 32 bit. Damit sollten sich eigentlich auch so Sachen machen lassen wie einzelne Macroblöcke austauschen usw.

Als weiteren vielversprechenden Ansatzpunkt sehe ich noch die Sache mit den Chromablöcken mit 0-Werten. Das müßte nochmal genau untersucht werden.

Grüße,
G. W.

[AutoTest]

@G.W.: Danke für deine positive Stellungnahme und die Literaturhinweise. Wird aber ein paar Megasekunden brauchen, bis ich da durch bin. :wink:
Da ich mit dem Lesen von Büchern im vorigen Jahrhundert eigentlich aufgehört habe, stürze ich mich zuerst mal auf die Online-Quellen. Möchte aber gleich anmerken, dass ich sehr praktisch orientiert bin und mein Ziel möglichst direkt ohne viel Studium erreichen möchte.

Am Wochenende mach ich dann schon mal die zwei MPV-Dateien mit gleichartiger GOP-Struktur und IBP-Folgen. Ich schlage vor, dass wir nur die MPV's bearbeiten, denn in VOB's stehen ja schon wieder eine Menge Zusatzinformationen (z.B. die Audiodaten) drin, die das Handling verkomplizieren. Ich gehe derzeit davon aus, dass die Audiodaten als Problemverursacher ausscheiden (so richtig ausgetestet hat diese Annahme aber wohl noch niemand, oder?)
Die beiden MPV's werde ich dann online stellen, sodass jeder mal einen Blick reinwerfen kann.

Dann wär's schön, wenn jemand den nächsten Schritt konkret vorschlägt und mir auch möglichst genau sagen kann, was wo in der Datei steht (also z.B. "suche nach der Byte-Folge 00 10 00 00 und tausche die nächsten 3876 Byte aus").

Ach ja: Zoran hat mir heute geschrieben, dass sie das Problem mit den aktuellen Decoder-Chips (die sind ja inzwischen auch schon DivX-fähig) nicht sehen können und noch nicht dazugekommen sind, es mit der älteren Version (Vaddis IV) zu testen. Sie hoffen aber, bald mehr zu berichten. Na, immerhin schon eine interessante Information. Neue Player die derzeit gebaut und verkauft werden, dürften das Problem dann gar nicht mehr haben. Wird sich wahrscheinlich eine Neuanschaffung bald lohnen.

[AutoTest]

So, die 2 Testfilmchen stehen jetzt zur Analyse und zum Patch bereit. Ich habe das alte Testvideo mit MPEG2Schnitt nochmal minimalisiert und auf lediglich 4 Frames (I-B-B-P) reduziert und daraus dann mit TMPGEnc eine "Kopie" erzeugt. Habe alle wesentlichen Parameter (Bitrate, VBV-Buffer, etc.) gleich wie im Original eingestellt. Die Dateien haben jetzt schon eine recht überschaubare Größe.

Unten zum Download:
TEST0.MPV (104072 Byte) -> grünes Bild.
TEST1.MPV (59381 Byte) -> Normales Bild.

Hab's schon am SAP probiert. Beide Male hatte ich mit Ifoedit den gleichen Ton dazugepackt. Den kann man somit als Problemquelle ausschließen.

Habe auch schon angefangen die ISO138182 zu studieren. Enthält viele Details, was jetzt wo in den MPV-Dateien steht, konnte ich darin aber (noch) nicht finden (habe die 255 Seiten aber erstmal nur überflogen). Daher nochmal die Bitte an alle die sich mit MPV-Dateien auskennen: Könnt ihr die Header der beiden Dateien mal vergleichen. Unterscheiden sich die? Könnte man sie austauschen? Wenn ja, wo in den Dateien stehen sie?

[dvb.matt]

zu meinem letzten Beitrag will ich noch ergänzen/korrigieren:

13) es wird _kein_ I-Frame dekodiert (gepuffert?), das Bild ist komplett 'grün'.
14) siehe 12), die zwischenliegenden B/P-Frames werden dekodiert und die Änderungen (Differenzwerte bzw. komplett neue Blöcke) auf das gepufferte Bild angewandt. (zumeist ja inkorrekt grün)
* die vereinzelt richtig erscheinenden Blöcke wurden komplett neu im B/P-Frame übertragen, die Bewegungsänderungen an der Stelle waren zu groß um die bisherigen Blöcke mit Änderungen weiter zu verwenden.
* das komplett erscheinende Bild ist ein P-Frame!, der Szenenwechsel erforderte den Austausch aller Blöcke.
* der folgende I-Frame wurde nicht dekodiert (komplett grün), die zwei B-Frames dazwischen lösen das normale Bild wieder auf zum grün hin..

meine Theorie/Fehlersuche ändert sich nun also dahingehend:
warum kann der I-Frame nicht dekodiert werden? zu groß? eher nicht bei RTL und ARD.
dann doch eher ein Bufferproblem bzw. Auslöser, der diese Frames verwirft...

[AutoTest]

warum kann der I-Frame nicht dekodiert werden? zu groß?
Absolut gesehen eher nicht, relativ vielleicht (für die angegebene Bitrate von 2,9MBit). Die Originaldatei ist immerhin fast doppelt so groß wie die von TMPGEnc (bei gleicher Bitrate). Habe jetzt ausprobiert, was passiert, wenn man die Bitrate im Sequenzheader von 2,9 MBit auf 6,5 MBit ändert (ja dank des ISO138182-Dokuments kann ich das schon :D). Resultat: Keine Änderung, Bild nach wie vor grün.

Habe nun auch mit dem MPEGAnalyzzatore die TEST0.MPV mit der TEST1.MPV verglichen. Das Programm zeigt aber nicht allzuviel an. Der einzige Unterschied, den man damit sehen kann, ist eine geringfügige Differenz der Bitrate und dass in der der Original-Datei alle VBV-Delays auf FFFF stehen, während TMPGEnc verschiedene Werte rund um 3000 erzeugt hat. Da ich aber noch nicht begriffen hab, wozu das VBV-Delay eigentlich gut ist und wie es berechnet wird, kann ich da noch nicht sinnvoll dran drehen. Bin für jeden Hinweis weiterhin dankbar.

[dvb.matt]

@GW testete ja mit vbv_delay, jedoch wohl ohne Erfolg s.o.
AFAIK bedeutet 0xFFFF, der Buffer wird gefüllt mit Daten bis er voll ist (mehrere Frames drin), und dann erst wird zu dekodieren begonnen, ansonsten tuts er schon früher.

ich hab mal die picture_coding_extension gepatcht, die optionalen Einträge dort (für Decodierung nicht von Belang) sind allerdings auch in jedem Frame und ich glaube nicht das es einen Effekt hat.

bis auf den Eintrag sind die _Header_ von test0/1 gleichwertig (tmpg hat noch einen mehr mit 'eigenwerbung' ), beide haben keine neue Intra_quant_matrix, sodass das Ergänzen einer solchen IMO auch nix bringt.

Ein Unterschied gibts noch beim Wert für _quantiser_scale_ (für I-Frame), der ist bei tmpg 8, im orig. 7 im ersten Slice (kanns IMO auch nicht sein),
dann kommen ja schon die Macroblöcke..

[AutoTest]

ES HAT FUNKTIONIERT :top:

@dvb.matt: Dein Patch funzt. Erklär bitte mal genau was du mit welchen Werten gepatcht hast.

[Groundskeeper Willie]

:) Bingo!

Ich habe dazu ein kleines Programm geschrieben, daß wie in dvb.matts Datei - falls vorhanden - das composite_display_flag löscht und die darauf folgenden Werte (20 bit) ausnullt. Dauert zwar ewig, funktioniert aber:

Ich habe es an jeweils zehnsekündigen Sequenzen aus allen Sendern des RTL- und des RTL-Austria-Transponders getestet =>

Keine grünen Klötze mehr!

Es müßte sich nochmal jemand ransetzen und das Programm vernünftig neuschreiben - war als reiner Proof-of-Concept gedacht. Oder gleich in ProjectX integrieren?

Wer hätte das gedacht...
Ich hätte niemals (genausowenig wie dvb.matt) vermutet, daß es was mit dem composite_display_flag in der picture_coding_extension zu tun hätte. Ich dachte bislang, das wären rein informative Werte.

@dvb.matt: Saubere Arbeit!

<mode besserwisser="on">Ich habe doch schon immer gewußt, daß wir es eines Tages schaffen würden.<mode besserwisser="off">.

Also dann noch gute Nacht!

Grüße,
G. W.

[dvb.matt]

das ist ja ein Ding!!

krieg ich jetz auch so'n Olympia Lorbeerkranz :D

AFAIK soll so ein analoges Quellsignal (wissen wir also was die enkodieren) nach der Dekodierung weitestgehend dem Original entsprechen (TV/Farbsystem/Träger etc.)

da die B- & P-Frames diese Info auch besitzen, jedoch _nicht_ übergangen werden, kann man hier wohl von einem FirmwareBug sprechen der also beim Frametyp I vor dem ersten Slice aus dem Parsen herausspringt und auf den nächsten Pictureheader wartet.
Das erklärt auch, dass das Bild grün wird beim Eintreffen eines I-Frames, da dieser Header ja noch gelesen und der FrameBuffer entsprechend (nur halt 'leer') re-initialisiert wird..

--
achso, kann man natürlich auch gleich in Pj.X implementieren..

[Groundskeeper Willie]

Hallo,

ich glaube nicht, daß es sich um ne Firmwaresache handelt, sonst eher einen Fehler im festverdrahteten Decoder-ASIC (allenfalls Microcode).

Außerdem bin ich der Ansicht, daß die Aussage Zorans, der Chip sei DVD-kompatibel, falsch ist.

Schließlich wird in den üblichen Angaben zur DVD-Spezifikation (z. B. http://www.dvddemystified.com/dvdfaq.html#3.4, http://www.mpucoder.com/DVD/dvdmpeg.html oder http://www.mpeg.org/MPEG/DVD/Book_B/Video.html) immer nur angegeben, daß auf DVDs eine Untermenge des MPEG2-Standards bzgl. der Profile, Bitraten & Auflösungen sowie GOP-Längen enthalten ist.

@dvb.matt: Ich vermute, die haben an der Stelle der picture_coding_extension keine next_startcode-Routine eingebaut, sondern die Länge des Headers fest kodiert. Der Decoder verhaspelt sich dann um die 3 Byte, und das war' dann. Das kann man nur echt dämlich nennen.

Ich meine, ein vernünftiger Decoder sollte ein simples Flag, was er nicht kennt, einfach ignorieren und darf keinen Murks produzieren.

Leider kann ich das mit der Konformität nicht exakt belegen, da ich die DVD-Video-Spezifikation (DVD Book B) nicht habe und die sich auch nirgends auftreiben läßt (kostet 5000EUR + NDA...). Hat jemand ne Idee, wie sich das überprüfen ließe?

Die Behauptung Zorans ist IMHO Quark. Falls es wirklich so ist wie ich vermute, wären Millionen von Playern nicht DVD-konform...

Grüße, G. W.

[kstroe]

Hallo,
Glückwunsch :!:
Habe sofort meine alte Testsequenz mit dem Programm gepatched,
und keine grünen Klötzchen mehr :D

Werde weiter testen, aber das scheint wirklich der Grund zu sein.

Besten Dank

P.S.
Testsequenz war von der ARD aufgenommen

[Groundskeeper Willie]

Super, dann scheint auch ARD gefixt. Ich lasse mal den Patch über einen längeren Film laufen und werde dann berichten.

[dvb.matt]

ich glaube nicht, daß es sich um ne Firmwaresache handelt, sonst eher einen Fehler im festverdrahteten Decoder-ASIC (allenfalls Microcode).
yupp, das halt, was der Chip beim Anlegen der Betriebsspannung 'von selbst' macht .. :wink:
vielleicht gibts da ja noch irgendwo ein Register für zum einstellen..

ich glaub net, das da Unterschiede in der extension je Frame gemacht wurden, da nicht-I-Frames ja funktioniern und diese allgemein gelesen werden müssen.

praktisch finden die Angaben wohl eh nur beim Live-Enkoden Anwendung.


BTW:
wir waren schonmal sooo nah dran, bzw. @Richard hier (http://forum.dvbtechnics.info/viewtopic.php?p=4306#4306)

--
für die die Pj.X verwenden, in der nä. Ausgabe gibts'n Knopp für..

[Groundskeeper Willie]

Habe einen 120min-Film von EinsExtra getestet und 10min an verschiedenen Stellen angekuckt => läuft ohne Probleme.

[Groundskeeper Willie]

Mift! Das hätte man echt mal weiterverfolgen sollen.

Aber ich glaube, das hätte keiner gedacht, daß die PAL-Parameter damit was zu tun hätten...

@dvb.matt: Was meinst Du mit "ich glaub net, das da Unterschiede in der extension je Frame gemacht wurden, da nicht-I-Frames ja funktioniern."?

Grüße, G.W.

[dvb.matt]

weil B- und P-Frames werden _nicht_ rausgekickt (siehe Bsp. Filmchen), die haben aber ebenso die Zusatzdaten (die wir hier auch mit plattpatchen)

[Torr_Samaho]

Auch auf einem Samsung DVD-E232 scheint durch das Löschen des composite_display_flag das grüne Klötzchen Problem behoben zu sein.

Hat das irgendeinen Nachteil, dieses Flag zu löschen, oder kann man ab der nächsten X Version den entprechenden Haken bedenkenlos immer machen?

[Groundskeeper Willie]

Die Infos, die dem Flag folgen, sind dem Composite-Quellsignal entnommen. Sie beziehen sich auf bestimmte Parametern, z. B. Phasenlagen, des PAL-Signals.
So wie z. B. die Austastlücken auch wird das Composite-PAL-Signal sowieso auf digitalem Wege im PAL-Encoder neu generiert.
Der Signalweg in den Decodern hab ich mal versucht zu skizzieren, wobei ich die Sync-Erzeugung weggelassen habe.

Deshalb: IMHO kann man das Flag bedenkenlos ausnullen.

Grüße, G. W.

[dvb.matt]

Deshalb: IMHO kann man das Flag bedenkenlos ausnullen.
Ich meine auch.
wobei hier noch der Vorteil ist, dass selbst bei fehlerhafter Detektion des Flags der nächstfolgende Header durch die 'Nullung' _nicht_ beschädigt wird, da es dort eh 0 sein muss..

[Groundskeeper Willie]

Genau. Zumal die Startcodes byte-aligned sind und vor ihnen lt. ISO 13828 eine beliebige Zahl von Null-Bytes stehen kann.

Grüße, G. W.

[RchdSchmidt]

Das war wirklich eine großartige Leistung von DVB.matt. Vielen Dank.

Leider konnte ich mich wegen familiärer Gesundheitsprobleme in der letzten Zeit nicht an der Diskussion beteiligen, aber ich hoffe, das wird bald besser. Wenn dann noch Bedarf an einer Änderung meines primitiven VBV91-Killerprogramms auf das Composite Flag bestehen sollte, werde ich dies gern versuchen.

Richard Schmidt.

[AutoTest]

Wenn dann noch Bedarf an einer Änderung meines primitiven VBV91-Killerprogramms auf das Composite Flag bestehen sollte, werde ich dies gern versuchen.
Danke, zahlt sich aber nicht wirklich aus, da ja schon das Programm von Groundskeeper Willie zur Verfügung steht und dvb.matt baut's auch schon ins nächste Pj.X ein. Denke mir, dass es auch Wiljo in PVAStrumento einbauen wird, sobald er dazukommt. Im Offeryn-Forum hab ich jedenfalls schon einen diesbezüglichen Erweiterungswunsch deponiert.

Ich frage mich übrigens, ob ich Zoran auf das composite_display_flag hinweisen soll, oder ob es besser wäre die selbst draufkommen zu lassen. Bisher kam von denen ja keine Unterstützung. Ich tu vorerst mal nichts. Schreibt mir bitte Eure Meinung.

[dvb.matt]

IMO wär es auf jeden Fall angebracht, ein kleines z.B. .exe Tool zu haben, das bereits erstellte DVD-Strukturen/VOBs dahingehend bearbeitet, ohne neu authoren zu müssen. (vom ripp und neu brennen abgesehen)

wenn das @GW's .exe macht, iss ja schon alles da.. :wink:

ob ich Zoran auf das composite_display_flag hinweisen soll
wenns die neuen Chips besser 'draufhaben', würde Z. wohl eh nicht handeln..

aber die ARD könnte man informieren (warn ja kommunikativer) und sie könnten bei der Gelegenheit gleich die Daten weglassen :D (wenn'se denn nicht wirklich 'irgendwo' gebraucht werden, was wir nicht erahnen)

[Groundskeeper Willie]

Mein "Programm" sollte auch mit VOBs umgehen können, diese sind schließlich auch nur MPEG2-Programstreams mit Zusatzinformationen.

Das Problem ist nur die Geschwindigkeit. Für ein 2GB-File hat es testweise eine halbe Stunde gebraucht. Ich werd mich in Kürze nochmal dransetzen.

Grüße, G. W.

[dvb.matt]

bei .vob sollte's ja net vorkommen, aber man sollte ein Augenmerk darauf richten, dass diese Header durch einen übergeordneten PES-Header geteilt werden könnten.

k.A. ob das andere allgemeinbekannte Patcher auch abhandeln.

[Groundskeeper Willie]

Oha, danke, hätt ich vergessen. Wäre arg ausgegangen ;) Muß ich mal schauen, wie ich das gehandelt kriege.

[AutoTest]

@G.W.:
Um es für DVD-Strukturen auszulegen, wäre es schön, wenn es gleich ein ganzes Titleset oder einen ganzen VIDEO-TS Ordner bearbeiten könnte, statt nur einzelne Dateien. Bei der Gelegenheit sollte auch die Suchfunktion beschleunigt werden (größere Teile der Datei in den Speicher einlesen und dort Stringsuche anwenden).
Dann wäre da noch ein GUI für Dateiauswahl, Fortschrittsanzeige und Abbruchmöglichkeit und die Unterstützung von Dateien >4GB, ....... :roll:

Möchte dich aber nicht von deiner Klausur ablenken. Wie weit bist du da denn?

[Groundskeeper Willie]

@dvb.matt:
Ich kenn mich nur mit "normalem" MPEG aus, wieso sollte es bei VOBs nicht sein, daß der dieser Startcode durch das Zerteilen des Video-ES in mehrere PES-Pakete zerteilt wird?

Hast Du ne Spec für VOB zur Hand?

Grüße, G. W.

[steini]

Vielen Dank an alle!

Beobachte auch schon seit einiger Zeit diesen Thread - bin leidgeprüft ...

Mein Player ist ein Toshiba SD-140E

Aber Dank X 0.81.8 klappt´s jetzt!!! :D

DANKE

Steini

[dvb.matt]

@GW
AFAIK startet da jedes Picture mit einem neuen PES-Paket (wie bei TS),
daher ist in den 2048 bytes noch genug Platz, um unzerteilt zu bleiben :wink: (dank den padding packets..)

ohne padding und bei fixen Paketgrößen kommts irgendwann zu dem Effekt. (kommt auf den Muxalgo an)

[Torr_Samaho]

Ich habe getest, ob delete_cdf auch bei vobs funktioniert: Ein vob File, mit TMPEG DVDAuthor aus ES erstellt, habe ich mit delete_cdf behandelt und neu gebrannt. Beim Ergebnis sind die grünen Klötzchen nur fast verschwunden, es gibt hin und wieder noch einzelne Frames, bei denen sie noch vorhanden sind.

Das gleiche vob File habe ich dann mit dem neuen X (und der "patch c.d.flagged infos of pictures" Option) gedemuxt und neu geauthort. Hier sind alle grünen Klötzchen verschwunden.

So ganz scheint delete_cdf also nicht mit vobs zurecht zu kommen.

[Groundskeeper Willie]

Hallöchen,

schade, daß es nicht klappt, aber in VOBs sind ja noch ne ganze Menge zusätzliche Sachen drin. Ich schätze auch, daß diese grünen Klötze nicht durch das composite_display_flag-Problem hervorgerufen werden, sondern daß delete_cdf irgendwas anderes kaputtrepariert. Und daß dann grüne Klötze auftreten, ist aus allerlei andere Streamfehlern bekannt.

Schlechte Nachricht:

Ich habe momentan überhaupt keine Zeit, sowas (effizient!) zu programmieren. Vielleicht in ein paar Wochen wieder... Oder findet sich jemand anderes???

Grüße, G. W.

[RchdSchmidt]

Werde mal schauen, ob ich es übers Wochenende schaffe, meinen vbv91killer so umzubauen, daß er die composite_display_flags aus den .vob-Dateien killt. Das Problem ist nur: das composite_display_flag ist offenbar in allen Bildern enthalten und nicht nur in den GOPs. Da mein Programm mit lseek direkt an die Stellen springt, wo etwas zu untersuchen oder zu ändern ist, und da dies bei allen Bildern erforderlich ist, sind viel mehr Sprünge nötig, was das Programm langsamer macht. Aber ich denke, mit meinem 666MHz-Rechner sollten 2 GB damit in weniger als 15 Minuten zu bearbeiten sein, mit einem modernen Rechner entsprechend schneller.

Richard Schmidt.

[KlaFre]

Hallo,

ich verfolge diesen Thread schon seit einigen Wochen. Ich habe einen Samsung DVD S224 und hatte eben dieses "GrüneKlötzchenProblem" und da ich meinen DVDBrenner auch neu habe, dachte ich zuerst an ein Brennproblem und habe mir auch schon einige Rohlinge geschossen. Durch eure Arbeit hab ich dann erfahren, daß ich nicht alleine mit dem Problem bin.

Und jetzt habe ich auch noch eine Lösung !! :) :) Super. Ich habe jetzt mit dem neuen ProjectX 0.81.8 einen DVB Stream (ZDF) bearbeitet und es war ein voller Erfolg. Die DVD läuft ohne grüne Klötze

Nochmals meinen herzlichen Dank für eure Arbeit


Klaus

[dvb.matt]

ZDF (zumindest auf Astra 19°E) war/ist davon garnicht betroffen.
ob's auf Hotbird oder DVB-T anders ist, weiß ich nicht.

betroffene 'Kandidaten' haben im akt. Pj.X Vorschaubild nunmehr rechts unten "cdf" zu stehen.

[KlaFre]

Hallo,

gleich im ersten Posting schon Mist geschrieben :x

Ich hab noch mal nachgeschaut, es war tatsächlich nicht im ZDF sondern im WDR

Gruss

Klaus

[WinniePooh]

Hallo Experten,

ich verfolge dieses Thema auch schon etwas länger mit Interesse, da ich von dem selben Problem betroffen bin.

Toll, wie sich die Experten hier an Lösungswege herantasten, dickes Lob!!

Nun habe ich vor einigen Wochen einen Film auf ARD aufgenommen und mit der neuen ProjectX Version (0.81.8 ) demuxt.
Fast alle grünen Klötze sind verschwunden, nur vereinzelt tauchen noch welche auf. Habt Ihr diesen Effekt auch oder sind bei Euch alle Klötze verschwunden?

Gruß Winnie

[dvb.matt]

inwieweit _vereinzelt_ ? sekunden-,minuten-,stundenweise..

bei bisherigen Berichten war die einhellige Meinung, _alle_ wären weg,
wenn die Option genutzt wurde..

'verfälschte Klötzchen' entstehen aber auch durch Übertragungsfehler allgemein, die mit diesem Prob. hier nichts zu tun haben, aber ähnlich aussehen..

[WinniePooh]

Hi Matt,

inwieweit _vereinzelt_ ? sekunden-,minuten-,stundenweise..

Also ich sag mal so alle 5 Minuten ein aufblinken, offenbar bei bewegten Bildübergängen (nicht unbedingt besonders harte).
Werde mir das nochmal genauer ansehen und berichten.

Gruß Winnie

[dvb.matt]

mit der Einzelbildfortschaltung am SA sollte geprüft werden, ob an den Stellen ein _ganzes_ Bild 'grün' ist, so wie hier beschrieben. (I-Frame wurde beim Dekodieren ausgelassen)

andernfalls gibts da wohl noch ein anderes Problem.
hier wurde aber auch berichtet, dass eine Pufferänderung ztw. auftretende Klötzchen verschwinden ließ.

[RchdSchmidt]

Ich bin mit meinem Programm zum Löschen der Composite_Display_Flags in den vob-Dateien schon recht weit gekommen. Allerdings konnte ich nicht die fraglichen Stellen direkt anspringen, sondern mußte sequentiell nach der Einleitung der Extentions (0x000001b5) suchen. Aber erstaunlicherweise dauert das nicht besonders lange: auf meinem Rechner ca. 300 MB pro Minute, das würde für eine 4,3 GB-DVD etwa eine Viertelstunde ausmachen.

Leider ist noch ein kleiner Fehler drin, den ich erst suchen und rausmachen muß: In einigen (nicht in allen) Paketen, in denen die Headers von zwei Bildern enthalten sind (z.B. als BB oder BP von VobEdit angezeigt), wird nur das erste Composite_Display_Flag gelöscht, aber nicht das zweite.
Außerdem ist mir aufgefallen, daß manchmal der Picture-Extension-Satz wegen des Paket-Endes einfach abgeschnitten wird, und hier muß ich schauen, ob das Paket nicht einfach im nachfolgenden Paket fortgesetzt wird. Das könnte erklären, daß die Zahl der gelöschten Flags geringfügig niedriger ist als die von PVAStrumento gemeldete Zahl der Bilder.

Ich hoffe, daß ich es heute noch hinbekomme und hier zum Runterladen einhängen kann.

Richard Schmidt.

[sweety]

Bei mir funktioniert es einwandfrei mit 0.81.8. Keine grünen Klötze mehr. Herzlichen Dank für die Lösung des Problems.
Sweety

[RchdSchmidt]

Jetzt habe ich die erste Version meines Programms zum Löschen der Composite_DIsplay_Flags aus den vob-Dateien fertig. Ich bitte um reges Testen.
Der Kurz-Modus funktioniert noch nicht richtig. Aber der wird ja vorerst nicht gebraucht.
Ich bitte, das Programm für jede vob-Datei zweimal aufzurufen: einmal, um die Flags zu löschen, und einmal, um zu prüfen, ob keine mehr gefunden werden.
Ich bitte auch um Test des Zeitverhaltens. Meiner Meinung nach reicht die Geschwindigkeit.
Anwendung auf eigene Gefahr!

Nachtrag 9.9.04:

Bitte beachten:
Das Programm ändert direkt die Originaldateien. Gerade in der Erprobungszeit ist deshalb bei Filmen, die nicht mehr wiederhergestellt werden können, dringend zu empfehlen, vorher eine Kopie anzufertigen.

Das Programm ist ein Kommandozeilenprogramm. Es braucht nicht installiert zu werden. Zur Anwendung am besten das Icon fürs Programm oder für eine Verknüpfung darauf an eine gut erreichbare Stelle plazieren und die zu bearbeitende Vob-Datei (oder einen Ordner, der die zu bearbeitenden Vob-Dateien enthält) auf dieses Programm-Icon ziehen (Drag & Drop).

Wenn jemand mein Programm ausprobiert, würden mich folgende Punkte besonders interessieren:

1.) Ist die Zahl der Korrekturen gleich der Zahl der Bilder im Film? Diese wird z.B. von PVAStrumento beim Demultiplexen ausgegeben, kann aber auch leicht aus der von MPEG2Schnitt angezeigten Länge berechnet werden.
2.) Wird beim erneuten Bearbeiten der selben Datei 0 Korrekturen ausgegeben? Wenn nicht, wäre das ein Hinweis darauf, daß an der falschen Position korrigiert wurde.
3,) Wie ist das Zeitverhalten? Reicht die Geschwindigkeit aus? Wenn nicht, wüßte ich allerdings nicht auf Anhieb, wie ich sie drastisch reduzieren könnte.

Richard Schmidt.

[kstroe]

Hallo,
habe mittlerweile ziehmlich viele Streams auf Toshiba SA Player
getestet. Es ist durchweg erfolgreich.

Interessant ist jedoch, daß mein ausgemusteter Pioneer Player
die DVD gar nicht mehr abspielt .... er lädt und lädt und nichts passiert.

(Vielleicht ist er ja auch jetzt ganz defekt, Originale spielt er aber noch)

Der Tevion Player spielt alle DVDs ab. Scheinbar brauchen Pioneer
Player bei existierender Display Extension dieses Flag ???

Will damit sagen, daß das Problem für Toshiba und andere Player
gelöst ist, jedoch grundsätzlich das Composite Flag löschen, kann man
scheinbar auch nicht.
Gibt´s da Erfahrungen ??

[sweety]

Habe heute 3 DVDs mit grünen Klötzen mit Richards Programm "behandelt". Bin gerade am Überprüfen der 1. Disk. Keine grünen Klötze mehr. Habe einen Toshiba, der früher grüne Klötze zeigte, i. O., 2. Player älterer Thomson: zeigte vorher keine Klötze. Disk lässt sich problemlos abspielen.
An Richard. Herzlichen Dank. Anmerkung, die vielleicht umzusetzen möglich wäre: Ein File-Auswahlbox, Kommandozeile ist ein bisschen lästig. Ist aber nur ein Schönheitsfehler. Hauptsache, das Programm macht, wofür es geschrieben wurde.
Sweety

[AutoTest]

Interessant ist jedoch, daß mein ausgemusteter Pioneer Player die DVD gar nicht mehr abspielt .... er lädt und lädt und nichts passiert.
Liegt vielleicht am verwendeten DVD-Rohling. Habe hin und wieder auch so ein Problem auf meinem SA. Er kommt mit manchen Rohlingen (insbesondere -RW) nicht zurecht und stürzt dann (ähnlich wie ein PC) ab. Muss dann aus/einschalten, dann klappt es meistens wieder.
Hast du mehrere DVDs probiert? Kann der Pioneer keine einzige reparierte mehr abspielen?
Womit hast du denn die Filme behandelt (Matt's Pj.X, Richard's Compositekiller oder G.W.'s delete_cdf)?

[RchdSchmidt]

Lieber Sweety,

vielen Dank fürs Ausprobieren.
Allerdings würde mich auch noch folgendes interessieren (ich habe vergessen, es beim Download reinzuschreiben, aber ich hole es gleich nach):

1.) Ist die Zahl der Korrekturen gleich der Zahl der Bilder im Film? Diese wird z.B. von PVAStrumento beim Demultiplexen ausgegeben, kann aber auch leicht aus der von MPEG2Schnitt angezeigten Länge berechnet werden.
2.) Wird beim erneuten Bearbeiten der selben Datei 0 Korrekturen ausgegeben? Wenn nicht, wäre das ein Hinweis darauf, daß an der falschen Position korrigiert wurde.
3,) Wie ist das Zeitverhalten? Reicht die Geschwindigkeit aus? Wenn nicht, wüßte ich allerdings nicht auf Anhieb, wie ich sie drastisch reduzieren könnte.

Es wäre auch gut, wenn jemand einen Film, der trotz gelöschtem Composite_Display_Flag noch gelegentlich Klötze zeigt, auch mit meinem Programm behandeln würde und schauen würde, ob dieses etwas zum Korrigieren gefunden hat.

Den Vorschlag mit der Dateiauswahlbox kann ich nicht aufgreifen, weil ich mich mit der Windows-Ressourcen-Programmierung kaum auskenne. Das Ganze ist wegen der Aktionstabellen für mich unheimlich kompliziert und undurchschaubar.

Aber ich bin der Meinung, das braucht es gar nicht. Es ist doch ganz einfach, das Icon für die zu bearbeitende Datei oder für den Ordner mit den zu bearbeitenden Dateien auf das Icon für mein Programm oder eine Verknüpfung darauf zu ziehen (Drag & Drop). Das ist meiner Meinung nach weniger Arbeit, als sich in einem Dateiauswahlfenster erst durch die Ordner zu hangeln. Ich finde, wenn man keine Oberfläche braucht, ist ein Kommandozeilenprogramm besser als jede Oberfläche.

Richard Schmidt.

[sweety]

Die Zahl der Bilder kann ich nicht mehr ermitteln, da ich nur mehr die VOBS habe. Beim zweiten Durchlauf zeigte er für jede VOB 0 an. Ich hoffe, dir damit gedient zu haben.
Sweety

[kstroe]

Hallo,
@autotest

Du hattest recht es lag am Rohling, also Entwarnung.

Mein RW-Rohling war wohl doch zu viel gelöscht und wieder
beschrieben worden. Beim ersten mal beschreiben, vor langer
Zeit, lief er jedenfalls auf dem Pioneer. Jetzt nicht mehr.

@Richard
Habe das Programm, das die VOB "behandelt" auch heruntergeladen.
Testbericht folgt noch.. habe momentan etwas wenig Zeit dafür.

[Ozymandias]

Kann man eigentlich auch .mpv Dateien "reinigen"? Ich habe die Aufnahmen halt schon demuxt, aber noch nicht weiterverarbeitet.
ProjectX zeigt mir in der Schnittvorschau meiner .mpv Dateien unten rechts "cdf" an (ist das eigentlich eine "sichere" Anzeige oder nur ein Indiz?), compositekiller scheint aber in .mpv Dateien nichts zum Löschen zu finden.

[dvb.matt]

Kann man eigentlich auch .mpv Dateien "reinigen"?
man kann, z.B. diese nochmal mit Pj.X 'demux'en.
je nach Ausgangsmaterial (sequence_end_code vorhanden oder nicht) kann aber die letzte Bildsequenz (~500ms) verlorengehen.

unten rechts "cdf"
nach bisherigen Erkenntnissen gibts dann definitiv auf 'empfindlichen' Playern die Klötzerchen.

compositekiller scheint aber in .mpv Dateien nichts zum Löschen zu finden.
es schien erstmal 'wichtiger', eine win-optimierte .VOB Variante zur Verfügung zu haben.

[RchdSchmidt]

Vielen Dank, Sweety.
Daß beim zweiten Durchlauf 0 Korrekturen herauskommen, ist eine sehr wichtige Information, denn wenn etwas Anderes herauskommt, würde das bedeuten, daß an der falschen Stelle korrigiert wurde und damit möglicherweise der Film beschädigt wurde. Bei meinen Tests ist auch 0 herausgekommen. Ich hoffe, daß viele diesen Test ebenfalls durchführen.

an Ozymandias:
Stimmt. Der Compositekiller ist nicht für .m2v-Dateien ausgelegt, er kann nur .vob-Dateien. Ich könnte ihn vielleicht so ändern, daß er auch m2v-Dateien kann, aber darin sehe ich keinen Sinn, denn erstens gibt es dafür ja schon andere Programme, und zweitens könnte man damit nur Dateien bis 2 GB bearbeiten, denn lccwin, dessen Compiler ich benütze, kann keinen lseek mit Integer64. Dazu bräuchte ich jemand, der Microsoft VIsual Studio hat (natürlich mit Lizenz) und mir das Quellprogramm übersetzt.

Richard Schmidt.

[cutthemovie]

es schien erstmal 'wichtiger', eine win-optimierte .VOB Variante zur Verfügung zu haben.
Hallo,
hatte ebenfalls einige grüne Klötzchen-DVDs. Auf dem Grundig GDP 9425 traten die Klötzchenfehler auf, auf dem Grundig GDP 6150 ließen sich dieselben DVDs einwandfrei abspielen.
Habe davon zwei DVDs nochmal mit der neuen ProjectX-Version (0.81.8.01) demuxt und erneut auf DVD gebrannt.
Die eine zeigte vorher einen komplett grünen Bildschirm, bei der anderen waren es nur vereinzelte Klötzchen an den Stellen, an denen sich der Bildinhalt schnell ändert.
Die Fehler wurden in beiden Fällen behoben! Vielen Dank an alle Beteiligten!

Noch einen klitzekleinen Vorschlag an den Programmautor: In den gelben Kurzhilfetext für das Feld "patched c.d. flagged infos..." das Wort Composite_Display_Flags mit unterbringen damit man die Abkuerzung "c.d." spaeter noch zuordnen kann. Ansonsten: Spitzenprogramm!!!

Gruß
cutthemovie

[dvb.matt]

Habe davon zwei DVDs nochmal mit der neuen ProjectX-Version (0.81.8.01) demuxt
grad' um ein Re-Authoring von einst 'verhunzten' DVDs zu vermeiden, wäre die .exe zu bevorzugen.
demuxen und nochmal authoren ist hier IMO unangebracht und würde _ich_ auch nicht tun..

das Wort Composite_Display_Flags mit unterbringen
ich glaub ja weniger, dass dies zu mehr Aufklärung beitragen würde :wink:

[RchdSchmidt]

Ich habe jetzt mein compositekiller-Programm (das zum Putzen von Vob-Dateien) selber mit einigen Filmen ausprobiert und auch durch Dateivergleich die Unterschiede untersucht, die mein Programm beim Umsetzen einbringt, und bin mit dem Ergebnis sehr zufrieden: Es wird genau dort geändert, wo ich es haben wollte.

Trotzdem warte ich gespannt auf die Ergebnisse derer, die das Programm schon ausprobiert haben.

Ich habe jetzt eine erweiterte Version gemacht, die den Aufruf in Prozeduren erleichtert, und werde diese bald zum Runterladen bereitstellen.

Übrigens glaube ich, daß man nach dem Ändern von Vob-Dateien mit dem compositekiller die Ifo-Dateien nicht nochmals erzeugen muß, weil dieses Programm ja keine Bytes einfügt und keine Bytes entfernt. Aber ausprobiert habe ich es noch nicht.

Eine Kleinigkeit gibt es aber noch, und weil ich dazu eine Frage an dvb.matt habe, werde ich das in einer neuen Antwort beschreiben.

Richard Schmidt.

[RchdSchmidt]

Frage an dvb.matt:

Mein compositekiller für .vob-Dateien löscht normalerweise wie gefordert nicht nur das Composite_Display_Flag, sondern nullt auch die 20 Bits danach aus. Aber etwa bei jedem tausendsten Bild liegt das Flag so knapp am Ende eines Pakets, daß ein Teil dieser 20 Bits schon im nächsten Paket liegt. In diesem Fall nulle ich nur bis zum Ende des Pakets aus. Ich denke mir, wenn das Composite_Display_Flag eh gelöscht ist, werden die Pal-Parameter sowieso nicht ausgewertet, und da macht es nichts aus, wenn noch ein paar Bits stehen bleiben. Kommt ja auch nur ganz selten vor.

Ist diese Überlegung richtig, oder muß man doch damit rechnen, daß die nicht ausgenullten Bits im Fortsetzungspaket Schwierigkeiten machen? In diesem Fall würde ich natürlich versuchen, auch die restlichen Bits im anderen Paket zu löschen.

Vielen Dank im voraus.
Richard Schmidt.

[dvb.matt]

die Antwort gibts schon hier (http://www.offeryn.de/phpbb/viewtopic.php?t=661)

[AutoTest]

Lieber Richard,
ich habe mit deinem Compositekiller nun ein paar Tests gemacht und kann folgendes berichten:
1. Der Kurztest (prinzipiell eine sehr gute Idee) funktioniert leider nicht richtig. Wenn beim Scan ein gesetztes c.d.flag gefunden wird, bricht das Programm ab und meldet es wäre nichts zu tun. Umgekehrt, wenn beim Scan nichts gefunden wird, wird anschließend die ganze Datei bearbeitet. Irgendwo im Kurztest dürfte da etwas verkehrt herum programmiert sein.

2. Bei einem Testfilm, den ich zuvor schon mit dem neuen PVAStrumento bearbeitet hatte um die c.d.flags zu löschen, findet der Compositekiller eine Stelle die nach gesetztem c.d.flag aussieht und nullt sie aus. Das Problem dabei: Diese Stelle kommt in der MPV-Datei gar nicht vor und ist daher erst bei der VOB-Erstellung (mit IfoEdit) entstanden. Leider kenn' ich mich mit VOB-Dateien noch zu wenig aus um beurteilen zu können, wie diese Stelle entstehen könnte und was sie wirklich bedeutet. Unten ein screenshot eines hexdumps davon. Vielleicht hat jemand eine Erklärung dafür. Merkwürdig sind insbesondere die Folgebytes 92 99 3A usw., denn nach einer picture coding extension sollte ja eigentlich das nächste extension start code prefix (00 00 01) kommen.

Daher Achtung: Wenn in VOB-Dateien Bytefolgen mit 00 00 01 B5 8... vorkommen können, die gar keine picture coding extension sind, dann könnte es natürlich passieren, dass man da etwas kaputtrepariert. Vielleicht ist's ja aber auch nur Datenmüll? Von den Audiodaten stammt die Stelle jedenfalls auch nicht. Auch in der MPA-Datei kommt die Bytefolge nicht vor.

Deine Frage, ob man immer alle 20 Bits nach dem c.d.flag ausnullen muss, würde ich unbedingt mit ja beantworten. Der Zoran-Chip geht scheinbar fest davon aus, dass nach dem Byte mit dem c.d.flag sofort der nächste start code kommt. Wenn da keine Nullen kommen, verhaspelt er sich und produziert ein grünes Bild.

[RchdSchmidt]

Vielen Dank für die Hilfe beim Test.
Das Korrigieren der nächsten 20 Bits auch bei geteilten Extensions habe ich schon eingebaut.
Der Kurzmodus funktioniert in der neuen Version schon seit Tagen. Ich hatte die Returnwerte verwechselt.
Leider weiß ich nicht, wie ich gezielt nach Extensions suchen kann. Deshalb suche ich nach dem Code 00 00 01 B5.
Audiopakete wertet mein Programm überhaupt nicht aus.
Ist der Code 00 00 01 B5, der durch IfoEdit hereingekommen ist, auch mit VobEdit sichtbar, und steht dort auch etwas vom Composite_Display_Flag?

Richard Schmidt.

[dvb.matt]

Leider weiß ich nicht, wie ich gezielt nach Extensions suchen kann. Deshalb suche ich nach dem Code 00 00 01 B5.
diese Extension folgt ausschließlich und unmittelbar dem Picture Header [00 00 01 00 xx xx xx xo oo] mit max. 9 Bytes (wird lt. deinen Sourcen glaub ich nicht abgefragt).

der Hexdump
00 00 01 E0 07 EC 81 00 00 01 B5 8A
ersteres wäre der PES-Header (eines normalen Folgepakets) ohne Extension (len=0), letzteres bereits der/das? Payload.

[RchdSchmidt]

Ich laß mir das mal durch den Kopf gehen.
Trotzdem ist hier schon mal die neue Version meines compositekillers - mit der Einschränkung, daß nur nach 00 00 01 B5 gesucht wird.
Richard Schmidt.

Nachtrag: Diese Version ist veraltet. Die derzeit (21.9.04)neueste Version ist 0.3 und steht auf einer der nächsten Seiten bereit.
R. Schmidt.

[AutoTest]

Ist der Code 00 00 01 B5, der durch IfoEdit hereingekommen ist, auch mit VobEdit sichtbar, und steht dort auch etwas vom Composite_Display_Flag?
Bräuchte dazu erst mal einen Tipp, wie ich die Stelle in VobEdit überhaupt finden kann. Eine Bytefolgensuchfunktion gibt's dort ja nicht, oder?. Ich weiß ja nur die Adresse in der gesamten Datei und VobEdit zeigt nur die LBA-Nummer und die relativen Adressen innerhalb der LBAs an. Haben alle LBAs eine konstante Größe?

Tipp nicht mehr notwendig, hab's gefunden. LBA=konstant 2kByte. Unten der Screenshot aus VobEdit. Die fragliche Bytefolge ist kein Startcode, sondern stammt direkt aus den Daten eines Mpeg-Frames!!! Ich hoffe das hilft dir, Richard.

Anm.: Im screenshot sieht man bereits, wo der compositekiller ausgenullt hat. Da ist im Frame nun sicher was kaputt.

[Pennywize]

Hi,

ich konnte aus verschiedenen Gründen den Thread leider nicht weiter verfolgen, und habe jetzt alles nachgelesen.

Herzlichen Glückwunsch an alle (bes an. DVBmatt) zur Problemlösung. Ich habe auch gleich die neue Version von Project X compiliert und eine Aufnahme von VOX (Deutschland) eingeladen. Er zeigt mir unten im Vorschaufenster auch schön in der Satuszeile an, VBV91 und CDF.

Jetzt meine Frage: Muss ich sonst noch etwas einstellen oder "killt" PX das Flag automatisch bei diesen Files.

Danke für die Info

Gruß
Penny

[dvb.matt]

nicht automatisch (weil ist ja eigentlich konform).
Knopp bei Kartei <video> "patch c.d.flag...." muss AN, und wirkt auch nur bei demux.

[Pennywize]

danke, dann probieren wir es mal.

[RchdSchmidt]

Schön, daß ich bei Lucike wieder reinkomme.
Zum Gif-Bild mit dem Hex-Dump möchte ich anmerken:
Die Zeile mit 00 00 01 b5 fängt mit der Position 810 (hex.) an. Das Paket hat bei 800 angefangen. Das erste Byte der Zeile ist also das siebzehnte Byte des Pakets.
Mein Programm überliest aber die ersten 23 Byte jedes Pakets, danach liest es die PES-Länge, und wenn diese nicht 0 ist, werden noch weitere Bytes überlesen.
Die Auswertung des Pakets beginnt also frühestens mit dem 24. Byte, also mit Byte 23 (dezimal) des Pakets.
Im Beispiel gehören in der Folge 81 00 00 die Bytes mit Wert 81 00 noch zu den überlesenen, das zweite 0-Byte ist die PES-Länge.
Die Auswertung beginnt mit 01 b5, aber das wird nicht als Extension erkannt, weil die beiden 0-Bytes am Anfang fehlen.
Wenn diese Nullbytes aber am Ende des vorigen Videopakets stehen, so wird die Extension sehr wohl erkannt und untersucht. Aber das gehört sich ja auch so.

Meine bisherigen Tests lassen mich glauben, daß es nicht notwendig ist, nach dem Picture Header zu suchen. Denn bei mir war stets die Zahl der Änderungen gleich der Zahl der Bilder.

Wenn sich aber durch das Berücksichtigen des Picture Headers die Gefahr, daß irgendwann mal ein Bild dabei ist, wo an der falschen Stelle geändert wurde, drastisch verringern läßt, so will ich dem nicht im Weg stehen.

Ich habe deshalb mein Programm schon so geändert, daß es vorher den Picture Header sucht. Ich bin zur Zeit noch am Testen. Aber bisher hat sich zu der Version, die den Picture Header ignoriert, beim Binärvergleich der Umsetzergebnisse kein Unterschied gezeigt. Ich will erst noch eine Menge Filme umsetzen und vergleichen, bevor ich die neue Version (0.2) zum Runterladen zur Verfügung stelle. Ich werde die neue Version aber sicher bald freigeben.

Bei mir ist der Compositekiller jedenfalls schon länger ins Produktionsscript fest eingebaut.

Leider geht mir wegen Überhitzung zur Zeit dauernd der Monitor aus. Deshalb will ich versuchen, die Frage von Autotest, wie man das Composite-Flag findet, blind zu beantworten.
Im rechten Fenster von VobEdit stehen bei MPEG Frame die MPEG Details, oder so ähnlich. Darunter stehen solche Dinge wie der Picture Header oder die verschiedenen Extensions. Unter anderem auch das Composite_Display_Flag. Es können aber Teile ganz in der Ausgabe fehlen, wenn sie in der Datei nicht vorhanden sind oder erst im Fortsetzungs-Videopaket folgen.

Richard Schmidt.

[AutoTest]

Mein Programm überliest aber die ersten 23 Byte jedes Pakets
Ja, das müsste funktionieren (zumindest bei meinem Testfilm). Ich werde es dann mit der Version 0.2 testen sobald du sie zur Verfügung stellst.

die Frage von Autotest, wie man das Composite-Flag findet...
Danke für den Hinweis. Mir war zuerst nur nicht klar wie die Adresse aus dem Hexdump mit Vobedit zu finden ist. Nachdem ich dann aber sah, dass alle Pakete stets 2048 Byte groß sind, konnte ich's mir leicht ausrechnen.
Noch eine Frage: Funktioniert der Composite-Killer auch mit anderen Paket-Größen? Bei VCD und SVCD dürften es ja 2324 Byte sein.

[RchdSchmidt]

Jetzt habe ich doch beim Testen noch einen Fall gehabt, wo die alte Version zwei Korrekturen mehr gemacht hat als Bilder vorhanden waren. Bei der neuen Version hat es genau gestimmt.
Außerdem habe ich noch ein paar Fehler gefunden und korrigiert.
Deshalb stelle ich die neue Version 0.2 jetzt zur Verfügung und entferne die Version 0.1.
Bitte Version 0.1 nicht mehr verwenden.

Richard Schmidt.

Nachtrag:
Leider geht der verkürzte Modus hier nicht. Bitte diese Version nicht mehr verwenden. Version 0.3 siehe unten.

Richard Schmidt.

[RchdSchmidt]

Tut mir leid, daß ich schon wieder mit einer neuen Version des Compositekillers kommen muß.
Aber heute früh ist mir eingefallen, daß ich mit der letzten Änderung verhindert habe, daß im verkürzten Modus erkannt wird, daß etws korrigiert werden muß. Und offenbar habe ich auch vergessen, das neu compilierte Programm auf den Namen ...kurz zu kopieren. Und so habe ich mit der alten Version den verkürzten Modus getestet und den Fehler nicht entdeckt.

Richard Schmidt.

Hier ist Version 0.3 des Compositekillers.

Nachtrag: Fast nie ergibt der Vergleich zwischen dem Ergebnis der Version 0.1 (normaler, nicht verkürzter Modus) und der neuen Version (normaler oder verkürzter Modus) irgend einen Unterschied. Nur einmal hat die alte Version zwei Korrekturen zu viel gemeldet. Aber auch das sind schon zwei Unterschiede zu viel. Hier möchte ich Karl Valentin zitieren: "Die Sicherheit geht über die Seltenheit". Allerdings ist das Programm mit der Version 0.2 etwas langsamer geworden.
Die Zahl der Bilder stimmt bei mir in Version 0.3 bisher immer genau mit der Zahl der Korrekturen überein.
Die Dateien zum Herunterladen stammen von heute früh (21.9.04, ca. 7:30) und wurden nicht verändert.

Richard Schmidt.

[AutoTest]

Hallo Richard,
hab jetzt die Version 0.3 des Compositekillers an meinen Testfilmen ausprobiert. Damit funktioniert nun alles erwartungsgemäß.

Übrigens: Kann man eigentlich den Titel eines Threads ändern? Statt "Grüne Klötze - Hoffnung auf Hilfe" müsste es ja nun eigentlich "Grüne Klötze - Ursache und Abhilfe" oder so ähnlich heissen.

[RchdSchmidt]

Lileber Autotest,
vielen Dank fürs Testen. Freut mich, daß es jetzt richtig läuft.

Ich kann ja mal versuchen, den Titel zu ändern. Wie es geht, weiß ich allerdings noch nicht. Ich hoffe, die anderen Teilnehmer finden den Beitrag dann noch.

Richard Schmidt.

[RchdSchmidt]

Mir ist aufgefallen, daß seit einer halben Woche keine neue Antwort mehr eingetroffen ist. Habe ich etwa durch Ändern des Titels etwas angestellt, so daß der Beitrag blockiert ist?

Richard Schmidt.

[steini]

Mir ist aufgefallen, daß seit einer halben Woche keine neue Antwort mehr eingetroffen ist. Habe ich etwa durch Ändern des Titels etwas angestellt, so daß der Beitrag blockiert ist?

Richard Schmidt.

Nö - schaut nicht so aus :)

Dein compositekiller bzw. X scheint aber auch für alle problemlos zu funktionieren :D

Steini

[[Sunny]]

Vielen herzlichen Dank allen an diesem Thread und der Problemlösung Beteiligten. Ihr habt mir persönlich und vermutlich einer ganzen Reihe von (bis vor kurzem verzweifelten) Anwendern einen Stein vom Herzen gerollt, dafür gebührt Euch mein Respekt und mein Dank.

Um diesem Thread die Aufmerksamkeit zukommen zu lassen, die ihm gebührt, habe ich mir erlaubt, darauf im DVDBoard aufmerksam zu machen und eine Zusammenfassung Eurer Erkenntnisse - sozusagen "am lebenden Objekt" zu formulieren: Thread (http://www.dvdboard.de/forum/showthread.php?s=&threadid=77162), FAQ-Artikel (http://www.dvdboard.de/faq/index.php?action=artikel&cat=10&id=152&artlang=de).

Herzlichen Glückwunsch Euch allen zu dieser produktiven Gemeinschaftsarbeit!

P.S.: Richard, ich habe Dir in diesem Zusammenhang eine Mail geschrieben - nur für den Fall, dass Du sie nicht erhalten hast.

P.P.S.: Beitrag geändert, da der FAQ-Link nicht mehr funktioniert hat.

[RchdSchmidt]

Vielen Dank für Euere Lebenszeichen. Freut mich, daß der Thread noch funktioniert.
Danke auch für das rege Interesse an meinem Programm.
Die Email von Sunny werde ich mir gleich anschauen.

Richard Schmidt.

[Charles]

Hallo Richard Schmidt,

ich konnte mit Deinem CompositeKiller meine Aufnahme "The Wall" von Eins Festival perfekt reparieren. Die DVD war übrigens mit Muxxi (Mplex/DVDAuthor-GUI) erstellt worden. Der SA ist ein Toshiba SD210E...
Ich danke Dir für die Bereitstellung dieses Tools. 8)

Und ich danke natürlich auch allen anderen, die an diesem Thread beteiligt waren. Ich ziehe meinen Hut vor Euch, eine tolle Leistung!

@all
Habt ihr den "patch c.d.flagged infos of pictures" jetzt generell in ProjectX eingeschaltet oder schaltet Ihr das nur bei Bedarf ein?

Grüße
Charles

[AutoTest]

Habt ihr den "patch c.d.flagged infos of pictures" jetzt generell in ProjectX eingeschaltet
Ich hab's in Pj.X und PVAStrumento generell eingeschaltet. Ich habe nirgends einen Hinweis gefunden, dass man mit den Informationen, die mit dem cdf übertragen werden, irgendwas sinnvolles anfangen könnte.

[Charles]

Danke für die Info, werde ich wohl auch machen...

Grüße,
Charles

[mabs]

Hallo,

ich hatte auch das Problem ( http://forum.tuxbox.org/forum/viewtopic.php?p=230749#230749 ), da ich kein Windows benutze habe ich den Compositekiller von Richard Schmidt für Linux angepaßt, Download ist möglich unter http://konahina.de/cdf/

[ChiefB]

Hallo,

ich habe gestern mal beide Varianten (windows+linux)
getestet, allerdings ohne Drag und Drop manuell für
jede vob-Datei einzeln auf den entsprechenden Konsolen
im Kurzmodus. Anschließend mit Linux gebrannt, Ergebnis:
Ganz gut, vorher hatte ich ein mehr oder weniger komplett
grünes Bild und jetzt habe ich ab und zu mal ein paar grüne
Klötzchen mit ein paar Rucklern bzw. Sprüngen. Der Player
ist ein Grundig GDP 9425 (49€ bei Saturn). Das ist zwar im-
mer noch nicht perfekt, aber schon ein gewaltiger Fortschritt.
Vielleicht liegts auch daran, dass ich das nicht mit Drag und
Drop gemacht habe, aber eigentlich bearbeitet der composite-
Killer doch eh nur die vobs, oder? Vielleicht sollte ich das Gan-
ze auch mal komplett unter windows testen, also inkl. authoring
und brennen?! Oder einfach einen neuen Player ;-)



Gruß

C

[dvb.matt]

ab und zu mal ein paar grüne
Klötzchen mit ein paar Rucklern bzw. Sprüngen
wenns vorher nicht ruckelte an den Stellen (möglicherweise in dem Grün nicht auszumachen ;) ), wäre es ein Indiz für Änderungen an ungewollter Stelle, also spaßenshalber wirklich mal neu demultiplexen (mit Patch) und authoren (ohne Patch).

[ChiefB]

Yeah, jetzt hat's geklappt:
Zuerst mit ProjektX und dem Häkchen bei "patch composite"
die vdr-Dateien demuxt. Dann mit mplex wieder remuxt und
schließlich mit ProjectX das mpg wieder zu vdr konvertiert.
Danach weiter mit vdrsyncpl und cdrecord-ProDVD. Keine
Ruckler, keine grünen Klötzchen *jubel*
Ich hatte vorher zuerst geauthort und dann den compositekiller
mehrfach(!) über die vobs laufen lassen. Der hat bei allen vobs
anfangs so um die 60000 und am Ende schließlich ca. 300
Korrekturen gemeldet, die auch nach wiederholtem Aufruf -egal ob
mit Kurz-Modus oder ohne- nicht weniger wurden. Ich vermute mal,
dass das genau die waren, die man dann noch sehen konnte,
zwar deutlich weniger, aber eben nicht null!

Ok, die schon gebrannten "grünen" DVDs muss ich jetzt noch mal
mit dem compositekiller bearbeiten, aber alle zukünftigen Aufnah-
men werden so auf jeden Fall die gewohnte Qualität haben.

Ein großes Lob an alle Programmierer. Ihr habt's echt drauf, weiter
so :-)

[RchdSchmidt]

Das mit den fehlerhaften DVDs tut mir leid.

Am Drag & Drop kann es nicht liegen. Dies ist nur eine vereinfachte Methode, um den Namen der Vob-Datei ans Programm zu übergeben.

Daß beim wiederholten Bearbeiten der selben Datei immer noch Korrekturen gemeldet werden, ist ein Hinweis darauf, daß zwar korrigiert wurde, aber an der falschen Position. Diesen Fehler würde ich gern suchen und rausmachen, aber ich habe keine Idee, wie das passiert, und dafür bräuchte ich mehr Informationen, z.B. ein Stückchen von einer Datei, bei dem der Fehler auftritt. Eine einzige GOP mit einem Fehler würde mir schon reichen. Es könnte am Authoring-Programm liegen, dessen Format vielleicht in einem wesentlichen Punkt von dem Format abweicht, das IfoEdit generiert.

Es könnte aber auch am Sender liegen. Aber wenn es einer der RTL-Gruppe oder der ARD-Gruppe (samt Dritten Programmen, Arte und Phoenix) war, dürfte es nicht am Sender liegen, denn die gehen bei mir einwandfrei.

Übrigens, die Stelle, die nicht richtig bearbeitet wird, läßt sich vielleicht so leicht finden: Wo die grünen Klötze auftreten, sofort auf die Anzeige am DVD-Spieler schauen. Dann die Vob-Datei mit VobEdit öffnen und in den Navigationspaketen die Zeit suchen, die der DVD-Spieler beim Fehler angezeigt hat. In deren Umgebung jedes Bild im linken Fenster anklicken und im rechten schauen, ob hier irgendwo das Composite_Display_Flag gesetzt ist.

Richard Schmidt.

[RchdSchmidt]

Inzwischen ist mir eine Idee gekommen, was die Ursache sein könnte.
Mein Verdacht ist, daß Dieses Exemplar des Programms mit einem anderen Compiler als lccwin oder Visual C++ übersetzt wurde, und daß dieser Compiler nicht automatisch so viele Bytes liest, wie angefordert wurden, sondern nur bis zu BUFSIZ. Und diese Größe ist meistens 512.
Ich bin gerade dabei, eine neue Version zu machen, die sowohl für Linux als auch für Windows geht, aber unter Linux konnte ich nicht compilieren, weil sich in den Includedateien ein paar Unverträglichkeiten gezeigt haben. Ich muß erst noch ein paar Änderungen einbauen, damit es auch dort geht. Diese neue Version berücksichtigt BUFSIZ.

Ich hoffe, damit klappt es dann.

Richard Schmidt.

[RchdSchmidt]

Hier ist die Version 0.4 des Compositekillers. Sie hat gegenüber der Version 0.3 den Vorteil, daß das selbe Quellprogramm sowohl für Windows als auch für Linux verwendet werden kann. Außerdem wurde die Puffergröße BUFSIZ berücksichtigt. Damit hoffe ich, daß das Problem verschwindet, das ein Anwender berichtet hat. Ich bitte ihn, seine Dateien mit dieser Version nochmals umzusetzen und das Ergebnis hier mitzuteilen.
Die neue Version wurde mit einem neuen Compiler übersetzt, der auch die Funktion readdir beherrscht (siehe Datei Liesmich.txt).
Die neue Version habe ich erfolgreich ausprobiert, möchte sie aber noch mit meinen laufenden Umsetzarbeiten testen. So lange bitte ich, sie mit Vorsicht zu genießen.

Richard Schmidt.

[ChiefB]

Ok, ich habe jetzt erstmal nur den neuen compositekiller_Linux
getestet, leider gleiches Ergebnis:

1. VDR-Aufnahme mit vdrsync.pl remuxt und geauthort.

2. Einmal "compositekiller_Linux" mit allen vobs: ca. 65000 Korrekturen

3. Nochmal "compositekiller_Linux" mit einem vob: 413
Korrekturen

4. Nochmal "compositekiller_Linux" mit gleichem vob: 413
Korrekturen

Eigentlich kann ich mit ProjectX die grünen Klötzchen vollständig
entfernen, aber kürzlich ist daraufhin das vdrsync-Script mit
einem "no TS Header found at GOP" abgeschmiert und ich musste
das Windows-Tool ifoedit bemühen, womit das Authoring dann
funktioniert hat. Da ich aber lieber ohne ProjectX und vor allem
ohne irgendein Windows-Programm auskommen würde, wäre der
compositekiller genau die richtige Lösung.
Ich werde heute abend nochmal die aktuellen Quellen mit dem gcc
übersetzen und dann weiter berichten.

Gruß

C

[RchdSchmidt]

Lieber ChiefB,

vielen Dank fürs Ausprobieren. Tut mir leid, daß es wieder nicht gegangen ist. Es ist schon merkwürdig. Bei mir ist immer die Zahl der Korrekturen gleich der Zahl der Bilder, und beim erneuten Aufrufen des Programms werden immer 0 Korrekturen ausgegeben. Vielleicht liegt es am Authoring-Programm, daß dieses etwas produziert, mit dem ich nie gerechnet hätte. Ich fürchte, da bleibt nur noch der Weg, daß ich ein Stück Film, in dem der Fehler auftritt, selber ausprobiere und mit dem Debugger den Fehler suche. Dürfte ich um ein solches bitten? Möglichst kurz, weil ich nur ein analoges Modem habe und die Übertragung elendig lang dauert. Meine Email-Adresse ist in meinem Profil zu finden. Ich möchte sie an dieser Stelle nicht angeben, damit ich nicht ein Opfer von Spam-Post werde.

Vielen Dank im voraus.
Richard Schmidt.

[RchdSchmidt]

Von ARD Digital habe ich jetzt folgende Antwort auf mein Schreiben erhalten:

Sehr geehrter Herr Schmidt,

die Untersuchungen für die Ursache der "grünen Klötzer" konnten wir
abschließen. Vielen Dank für Ihre sehr nützlichen Informationen. Ihr
letzter entscheidender Hinweis, dass der Zoran-Dekoder mit dem gesetzten
"Composite-Display" im MPEG Header Probleme hat, konnte nachvollzogen
werden.

Unser Encoderhersteller hat in seiner aktuellen Encoderserie die
Software angepasst und setzt von nun an das Composite-Display-Flag nicht
mehr. Wann die neue Software übernommen wird, können wir Ihnen leider
nicht mitteilen. Die Qualitätsprüfungen stehen noch aus. Leider gibt es
für die in Potsdam (Tr. 85) eingesetzten Encoder kein Software Update.

In Ihrem Forum lass ich, dass Sie einen "Composite-Display-Flag-Killer"programmiert hatten und dass es eine neue Funktion im Java- Demuxer
"ProjectX" gibt. ProjectX konnten wir in Verbindung mit VDR-Aufnahmen
erfolgreich testen.

Mit freundlichen Grüßen

ARD Playout Center Potsdam


Ich hatte ARD Digital damals unter anderem mitgeteilt:

ein Mitglied des Lucike-Forums, nämlich dvb.matt, hat offenbar die Ursache für die grünen Klötze gefunden:

das Composite_Display_Flag ist auf 1 gesetzt. Dieses scheint bei DVD-Spielern mit Zoran-Decoder den Fehler auszulösen. Wird das Flag in allen Bildern auf 0 gesetzt, so verschwinden angeblich die Klötze.


Richard Schmidt.

[hagge]

Mein Verdacht ist, daß Dieses Exemplar des Programms mit einem anderen Compiler als lccwin oder Visual C++ übersetzt wurde, und daß dieser Compiler nicht automatisch so viele Bytes liest, wie angefordert wurden, sondern nur bis zu BUFSIZ.
Hallo Richard,

das kann es eigentlich nicht sein, denn die Funktion read() *muss* entsprechend viele Bytes wie angefordert zurückliefern, ganz egal wie groß BUFSIZ ist. BUFSIZ ist nur ein Indiz dafür, welche Blockgröße intern besonders effizient verarbeitet wird.

Gruß,

Hagge

[RchdSchmidt]

Lieber Hagge,

Diesen Hinweis, sowie auch einen Teil aus Deiner persönlichen Nachricht werde ich in die nächste Version einbauen.

Lieber ChiefB,

ich habe an Dich eine Email mit einer Version zum Testen geschickt und bitte Dich, sie auszuprobieren. Ich hoffe, ich habe auch die richtige Adresse erwischt.

Gruß
Richard Schmidt.

[ChiefB]

das Teil heisst zwar .zip, ist aber eigentlich ein .vob, also am besten nach
dem Downloaden umbenennen.

[RchdSchmidt]

Hierist die neue Version:
Compositekiller Version 0.5
Nachdem mir ChiefB eine Testdatei zur Verfügung gestellt hat, war der Fehler schnell gefunden: Bei ihm war die PES-Header-Länge nicht 0, sondern 13. Leider hat mein Programm diese nur beim Lesen, aber nicht bei der Einstellung der Schreibposition berücksichtigt. Dieser Fehler ist jetzt behoben.
Auch diese Version ist für Linux geeignet.
Diese neue Version habe ich an ein paar Beispielen ausprobiert. Die Ergebnisse weisen bei mir keine Unterschiede zur Vorgängerversion auf (bei mir ist die PES-Headerlänge immer 0). Ich werde diese Version aber in den nächsten Tagen noch gründlicher testen und dann hier berichten.
Ich bitte ChiefB, die neue Version auszuprobieren und zu schreiben, ob der Fehler auch bei ihm weg ist.
Ich danke ChiefB für seinen Hinweis auf den Fehler und für seine Testdatei, sowie Hagge für einige wertvolle Hinweise zu meinem Quellprogramm, die zum Teil ebenfalls in dieser Version berücksichtigt wurden.

mit besten Grüßen
Richard Schmidt.

Nachtrag 24.12.04
Ich habe inzwischen 2 DVDs (aufgenommen von dritten Programmen und dem Ersten) mit insgesamt ca. 8 GB mit der neuen Version (0.5) bearbeitet und zum Vergleich eine Kopie der Originaldatei auch mit Version 0.3 und vergleichen lassen, dabei haben sich keine Unterschiede gezeigt. Das nochmalige Bearbeiten mit dem Programm hat stets 0 Korrekturen gebracht. Die Zahl der Korrekturen war immer gleich der Zahl der Bilder.
Ich denke, damit kann ich empfehlen, künftig die Version 0.5 zu verwenden.

Ich wünsche allen ein frohes Weihnachtsfest.
Richard Schmidt.

[RchdSchmidt]

ChiefB hat mir bereits geschrieben, daß bei ihm mit der neuen Version der Fehler nicht mehr auftritt (ein paar grüne Klötze bleiben übrig, zusammen mit Rucklern, und wenn man das Programm nochmals über die selbe vob-Datei laufen läßt, kommen nicht 0 Korrekturen heraus.).
Der Fehler schlägt gandenlos zu, wenn die PES-Header-length nicht 0 ist. Dann werden mit den alten Versionen Bytes mit 0 überschrieben, wo nichts geändert werden soll.
Bei meinen Filmen habe ich eine PES-Header-Länge>0 noch nie festgestellt, deshalb habe ich den Fehler auch nie gehabt, auch grüne Klötze gibt es bei mir nie, weil mein DVD-Spieler diese nicht kann.
Wenn jemand mit dem Programm Probleme haben sollte, bitte ich um eine Nachricht.

Ich denke, heute werde ich die ersten Filme mit der neuen Version putzen und das Ergebnis mit der alten Version vergleichen, abgesehen von meinem Testfilm, den ich schon gestern ausprobiert habe.

Richard Schmidt.

[RchdSchmidt]

Hier ist die Version 0.6 des Compositekillers. Diese unterscheidet sich von Version 0.5 nur dadurch, daß die neue Version automatisch eine Datei nur zum Lesen öffnet, wenn das Öffnen zum Schreiben trotz Änderung der Schreibrechte fehlgeschlagen ist. Die neue Version eignet sich deshalb auch zum Feststellen, ob die Dateien von einer älteren DVD überhaupt Composite_Display_Flags enthält und deshalb auf die Platte geladen werden muß.
Eigentlich sollte diese Leistung schon seit Version 0.2 drin sein, aber das habe ich wohl übersehen.
Wer auf dieses Prüfen der DVD verzichten will, kann genau so gut weiterhin die Version 0.5 verwenden.
Wer eine ältere Version als 0.5 hat, sollte die neue Version verwenden, weil die älteren Versionen einen Fehler enthalten, der zuschlägt, wenn die Vob-Dateien mit einem Authoring-Programm erzeugt wurden, das PES-Header-Längen ungleich 0 verwendet.
Die neue Version habe ich seit Weihnachten zu Testen selber im Einsatz und damit schon viele DVDs erzeugt. Es hat sich noch kein Fehler gezeigt. Deshalb empfehle ich diese Version (0.6) oder die gleich zuverlässige Version 0.5.
Auch die neue Version besteht aus einem Programm für Windows und einem für Linux und ist nur für vob-Dateien geeignet.
Die Bedienung hat sich nicht geändert: In Windows wie bei den älteren Version am besten die Vob-Datei oder den Ordner mit den Vob-Dateien auf das Programm-Icon ziehen.

Richard Schmidt.

[Local Hero]

Hier ist die Version 0.6 des Compositekillers. Richard Schmidt.

Hallo Richard Schmidt,

vielen, vielen Dank für diese tolle Programm! Es funktioniert perfekt und hilft enorm. Ich würde mich freuen, wenn es weiter entwickelt wird.

[hagge]

Hallo Richard,

auch ich muss mich herzlichst bedanken. Manchmal läuft das Leben schon seltsame Wege. Das Thema "grüne Klötze" hat mich bisher nie selbst betroffen, und so hatte ich den Thread nur sporadisch verfolgt und hin und wieder mal geschaut, was es neues gibt. Rein aus Neugier hatte ich mal Dein Tool runtergeladen, reingeschaut und Dir ja sogar ein paar Tipps zur Optimierung geschickt.

Nun kommt's: meine Eltern haben einen neuen DVD-Player, und als ich ihnen ein paar meiner selbstgebrannten DVDs ausgeliehen habe, meinten sie auf einmal, dass sie die gar nicht anschauen könnten, alles sei nur komplett grün. Da musste ich natürlich sofort an diesen Thread hier denken, habe das Compositekiller-Tool nochmal runtergeladen und die Files der DVD damit konfrontiert. Und tatsächlich wurden jede Menge Stellen gefunden und korrigiert.

Das Ergebnis war perfekt. Der Toshiba-Player meiner Eltern zeigt nun ebenfalls ein perfektes Bild an. Super!

Also nochmals vielen Dank!

Tschau,

Hagge

[RchdSchmidt]

Lieber Local Hero, lieber Hagge,

vielen Dank für die positiven Rückmeldungen. Nach dem Fehler mit der vergessenen Header-Länge tut es gut zu lesen, daß das Programm auch bei Anderen funktioniert.

Eigentlich habe ich nicht vor, das Programm groß weiterzuentwickeln, außer wenn sich noch Fehler zeigen oder sich die Encoder- und Decoderhersteller neue Gemeinheiten einfallen lassen sollten.

Aber wenn mir noch nützliche Kleinigkeiten einfallen sollten, die schnell zu programmieren sind und die Bedienung erleichtern, würde ich sie wohl noch einbauen.

Gruß
Richard Schmidt.

[hagge]

Eigentlich habe ich nicht vor, das Programm groß weiterzuentwickeln, außer wenn sich noch Fehler zeigen oder sich die Encoder- und Decoderhersteller neue Gemeinheiten einfallen lassen sollten.
Du kannst ja noch ein wenig warten, ob sich doch noch ein paar Probleme zeigen. Wenn nein, kannst Du ja mal irgendwann mit der Versionsnummer auf 1.0 gehen, damit andere wissen, dass das Tool nicht mehr im Experimentierstadium ist, sondern zufriedenstellend funktioniert.

Gruß,

Hagge

[elgringo22]

herzlichsten dank an alle beteiligten für die gefundene lösung und insbesondere eure hartnäckigkeit!

bin nur durch zufall damit konfrontiert worden, und zwar, nachdem ich aus bequemlichkeit die aufnahmen mit dvbviewer im mpg-format gemacht und direkt - ohne mit x zu demuxen - weiterverarbeitet habe.

stand vor einem rätsel und habe einige rohlinge deswegen "verbraten".

jetzt kann ich die bereits authoreten dvds retten, die quell-mpgs habe ich aus platzgründen nämlich schon gelöscht.

meine hochachtung!!!

[RchdSchmidt]

Seit Anfang Juni ist mir aufgefallen, daß einige ARD-Sender (z.B. Das Erste, Bayerisches Fernsehen, BR-Alpha) kein Composite_Display_Flag mehr su senden scheinen. Jedenfalls ist der compositekiller bei neueren Aufnahmen von diesen Sendern arbeitslos, er meldet, daß es nichts zu korrigieren gibt.

Andere Sender, z.B. RBB Berlin, senden das Flag noch.

Richard Schmidt.

[mattes3]

Eigentlich habe ich nicht vor, das Programm groß weiterzuentwickeln, außer wenn sich noch Fehler zeigen oder sich die Encoder- und Decoderhersteller neue Gemeinheiten einfallen lassen sollten.


Hallo Richard,

ich habe das Programm auf Mac OS X portiert. Angehängt findest Du die geänderte Source und das Binärprogramm für Mac OS X. Die Versionsnummer habe ich noch nicht hochgezählt - ich weiß nicht, wie Du das handhaben möchtest.

Das Composite-Flag ist in einer RTL-Aufnahme aufgetaucht, mit EyeTV auf dem Mac aufgenommen, von einem Terratec-DVBT-Empfänger im USB Stick.

Gruß
M.

[RchdSchmidt]

Lieber mattes3,

tut mir leid, daß ich Deine Antwort erst jetzt entdeckt habe.

Es freut mich, daß das Programm jetzt auch auf einer weiteren Plattform zur Verfügung steht. Vielen Dank. Es freut mich auch, daß das Programm offenbar immer noch verwendet wird.

Daß Du meine Versionsnummer weiter verwendest, ist in Ordnung, Du hast ja .macosx an den Namen angehängt, und daß diese Portierung von Dir stammt, kann ja jeder lesen. Falls Du eine weitere Version zur Verfügung stellen solltest, schlage ich vor, Du zählst die letzte Ziffer einfach hoch und hängst daran ebenfalls .macosx an.

Richard Schmidt.