Mpeg 4:2:2

[feed_x]

Hi,

 

nachdem ich hier schon häufiger rumgestöbert habe, habe ich mir den DVBViewer zugelegt. Hauptsächlich um HDTV auszuprobieren, denn die H.264 Komprimierung ist leider bei den meisten Programmen immer noch eine grosse Unbekannte, obwohl Jeder darüber spricht

 

Im Moment interessiert mich aber eine andere Frage, denn der DVBViewer-GE wird auch in DXer-Kreisen gelobt. Mit ALTDVB und anderen Programmen klappte 4:2:2 bisher eigentlich immer ohne Probleme. Der GE bringt bei bestimmten Feeds aber nur ein Ruckelbild zustande. Ich nehme den Elecarddekoder und habe damit immer alles prima sehen können. Wenn man mit dem DVBViewer aufnimmt, kann ich es hinterher auch mit Elecard abspielen aber live klappt das irgendwie nicht. Was kann man da machen? Mein System habe ich erst vor kurzem neu installiert mit den neuesten Treibern usw.

 

Gruss

 

feed_x

 

support_GE.zip

[Griga]

Wenn man mit dem DVBViewer aufnimmt, kann ich es hinterher auch mit Elecard abspielen aber live klappt das irgendwie nicht.

Das hatte Derrick auch schon festgestellt und intern zur Diskussion gestellt. Ursache sind vermutlich Timing-Probleme zwischen dem Elecard und dem DVBViewer Filter, die besonders bei 4:2:2 zum Tragen kommen. Allerdings gibt es noch zu wenig Anhaltspunkte, um das konkret angehen zu können. Insbesondere kann ich keinen solchen Stream empfangen, so dass mir Testmöglichkeiten fehlen.

 

Eine Lösung war für Derrick, im DVBViewer Filter den Latency-Wert auf 0 zu setzen (Ansicht -> Filter -> DVBSource, danach Stop/Run in der Kontrollleiste oder Ansicht -> Wiedergabe neu aufbauen, damit es wirksam wird).

 

Eine andere Möglichkeit ist die Verwendung von FFDShow als MPEG2-Videodecoder (am besten eine aktuelle SSE-Version) - der kann auch 4:2:2. Allerdings wird er nicht in der Decoder-Auswahlliste angezeigt. Praktikabel wird die Sache, indem man einen vorgefertigten Filtergraphen mit dem DVBViewer Filter & FFDShow baut und das Graph Selector Plugin aus dem Mitgliederbereich verwendet, um bei Bedarf auf ihn umzuschalten. Die dem Plugin beigefügte ReadMe erklärt alles weitere.

[Derrick]

ja, latency = 0 ist ein workaround für das problem. Der fehler tritt auf, wenn das LowDelay Flag beim video gesetzt ist. Damit scheint der DVBViewer source filter nicht klarzukommen. Dieser mode kommt aber wohl im normalen digitalen fernsehen nicht vor, sondern nur bei bestimmten studionormen. Komischerweise haben die filter anderer programme keine mühe, um auch eine normale livewiedergabe zu ermöglichen.

 

Den tip mit ffdshow möchte ich mit einem ? versehen. Trotz vieler versuche klappt die 422-wiedergabe damit bei mir nicht. Was aber auch prima funktioniert ist der vlc. Allerdings muss die applikation zum vlc streamen, was der dvbviewer_GE leider nicht beherrscht. Mit der Pro bzw. dem dvbserver lassen sich diese feeds auch wiedergeben. Ist deshalb dann aber auch eigentlich zu umständlich..

[Griga]

Damit scheint der DVBViewer source filter nicht klarzukommen

.

Sicher kommt er damit klar. Er demultiplext die Daten fehlerlos und stellt sie ordnungsgemäß für den Decoder bereit. Genau das ist seine Aufgabe. Außerdem enthält er die erforderlichen Konfigurationsmöglichkeiten, um problematische DirectShow-Konstellationen handhaben zu können

 

Wer nicht klar kommt, ist der Elecard Decoder aufgrund seines zu begrenzten Timing-Toleranzbereiches, und du, weil das Default-Timing nicht zu deinen extravaganten Ansprüchen passt. Das ist jedoch nicht maßgebend.

 

@feed_w: Nach meinen Erfahrungen läuft der DVBViewer GE auch mit Latency = 0 sauber. Man erhält damit sogar deutlich schnellere Sender-Umschaltzeiten. Die Defaultwerte sind im Hinblick auf langsame PCs und eine (empirische) Betriebssicherheit bei normalen MPEG2-Streams sehr konservativ gewählt. Dies hält AltDVB vermutlich anders.

[Derrick]

..über die formulierung "klar kommen" kann man ja reden aber was daran extravagant sein soll, versteh ich nicht. Ausserdem habe ich ja einen weg beschrieben, wie man den DVBViewer trotzdem benutzen kann.

 

Es gibt eine ganze reihe von topics, die sich aus den unterschiedlichsten gründen mit den einstellungen des source filters befassen. Das ist doch recht kompliziert. Ich bin ja auch nicht dagegen, denn wenn damit unterschiedliche hardware gleichermassen gut mit directshow funktioniert, hat es sicher seine berechtigung.

 

Doch gibt es eben manchmal betriebsumstände, die nicht optimal geregelt werden, obwohl sie aus den streams selbst resultieren. Ich erinnere an eine abweichung vom "normalen" timing zwischen ton und bild, die den DVBViewer verstummen liess, während andere noch munter weiter spielten. Auch da liess es sich mit einstellungen im filter (max. audio delay oder so ähnlich) reparieren. Bloss wenn man dran dreht, muss man ja auch wieder zurück drehen

[Griga]

Doch gibt es eben manchmal betriebsumstände, die nicht optimal geregelt werden,

Klar gibt es die. Es sind ja auch genug Komponenten beteiligt, die irgendwas unpassend handhaben können.

 

Alles dem DVBViewer zuzurechnen, was in irgendeiner Form nicht wie gewünscht funktioniert, und deshalb von den Entwicklern eine Lösung zu erwarten, ist eine verbreitete Unart. Dass ein Newbie die Aufgabenteilung zwischen Treiber, Sourcefilter, Decoder, Renderer, Anwendung und Betriebssystem nicht überblickt, ist verständlich. Wenn jedoch jemand, der sich schon seit Jahren damit befasst, es immer noch nicht geregelt kriegt, fragt man sich schon, welcher Bug da eigentlich vorliegt. Kompetenzüberschätzung, würde ich sagen. Jemand hat sich ein beträchtliches DVB-Wissen angegeignet und glaubt deshalb, er würde auch bei PC-Komponenten durchblicken, die DVB-Daten verarbeiten.

 

die den DVBViewer verstummen liess, während andere noch munter weiter spielten.

Das ist die ärgerlichste Erscheinungsform: Die Behauptung, es müsse ein Fehler im DVBViewer vorliegen, weil es bei Anwendung X ja funktioniert. Eine naive und realitätsfremde Annahme. Die Beobachtung zeigt nur, dass Anwendung X etwas anders macht, und wie sich dies in Betriebszustand A auswirkt. Dass womöglich ebendiese Änderung unerwünschte Seiteneffekte in den Zuständen B, C und D nach sich zieht, in denen sich wiederum der DVBViewer glänzend bewährt, wird ignoriert.

 

DVB-Software arbeitet in einem umfangreichzen Kontext mit einer astronomischen Anzahl möglicher Kombinationen verschiedener Zustandvariablen. Das kausale Denken trifft dabei auf seine Grenzen. Ein Entwickler kann nicht jede der Kombinationen gleichermaßen berücksichtigen. Oft ist es nicht Planung, sondern Zufall, welcher Betriebszustand in welchem Kontext bei welcher Anwendung funktioniert. Sich angesichts dieser Komplexität in die trügerische Sicherheit vereinfachender Denkmodelle retten zu wollen, ist zwar sehr menschlich, aber alles andere als realistisch.

[Derrick]

Wenn jedoch jemand, der sich schon seit Jahren damit befasst, es immer noch nicht geregelt kriegt, fragt man sich schon, welcher Bug da eigentlich vorliegt. Kompetenzüberschätzung, würde ich sagen...

 

..bezieht sich das jetzt auf den schreiber des zitats?

[Griga]

Es bezieht sich auf folgende Aussage:

 

Der fehler tritt auf, wenn das LowDelay Flag beim video gesetzt ist. Damit scheint der DVBViewer source filter nicht klarzukommen.

Die Erfassung und korrekte Behandlung solcher Flags in den Videodaten - auch unter variablen Timing-Bedingungen - ist eindeutig Aufgabe des Decoders, und nicht eines Sourcefilters/Demultiplexers.

[Derrick]

Die Erfassung und korrekte Behandlung solcher Flags in den Videodaten - auch unter variablen Timing-Bedingungen - ist eindeutig Aufgabe des Decoders, und nicht eines Sourcefilters/Demultiplexers.

Da bin ich mir eben nicht so sicher, dass das der fall ist. Man könnte an dem beispiel sagen, dass es nicht stimmt, aber das wäre natürlich zu einfach. Ohne jetzt die zusammenhänge genau nachvollziehen zu können, gehe ich davon aus, dass ein variabler puffer am eingang der kette in den dekoder mit einbezogen werden muss. Wenn man ihn raus nimmt, funktioniert es ja. Der sonderfall LowDelay=1 erfordert eine leerung unter bestimmten umständen und das scheint hier nicht vorgesehen zu sein. Dass das prinzip für andere betriebszustände vorteile bietet und ev. überlegen ist, will ich gar nicht bestreiten. Nur die absolutheit deiner behauptung für diesen fall kann ich so nicht unterstreichen.

[Griga]

Der sonderfall LowDelay=1 erfordert eine leerung unter bestimmten umständen und das scheint hier nicht vorgesehen zu sein.

Richtig. Der Decoder hat das nicht auf der Rechnung. Die Daten stehen ja bereit, aber der Decoder holt sie nicht rechtzeitig, und wenn er sie holt, ist es zu spät.

 

Die Default-Latency im DVBSource ist insbesondere auch ein Schutz gegen die nicht vorhersehbaren Pufferungs-Strategien von BDA-Treibern. Ein Extrem-Beispiel zur Verdeutlichung: FireDTV mit PID-Filterung bei Radioempfang. Der Treiber passt sich nicht an die niedrige Datenrate an. Resultat: Die Daten treffen stoßweise in Abständen von 2 Sekunden ein. Dies schafft für einen DirectShow-Graphen unakzeptable Timingverhältnisse. Er müsste viel mehr puffern, als er es normalerweise tut. Der DVBSource kann dies jedoch abfangen, wenn man Latency auf 2000 (!) oder höher stellt (plus erhöhtes Max. queued Audio) , was die Timestamps in Richtung Zukunft verschiebt und eine erhöhte Pufferung provoziert (kann man im DVBViewer Pro verifizieren - die GE nimmt ja als Workaround immer Nullpackets hinzu).

 

Beim Elecard & 4:2:2 liegt der umgekehrte Fall vor. Vermutlich hat der Programmierer nicht vorausgesehen, dass Umstände eintreten könnten, die in diesem Fall eine erhöhte Pufferung fordern. Also weiß der Decoder nicht, wo er die Frames mit den "zukünftigen" Timestamps bis zur Darstellung unterbringen soll und lässt sie fallen. Ich wette, die 4:2:2-Decodierung ist nie mit Live-Sources getestet worden, sondern nur mit Dateien.

[feed_x]

Danke für eure interessante Unterhaltung, aber so genau wollte ich es gar nicht wissen bzw. verstehe ich nur Bahnhof Delay werde ich mal auf 0 setzen, wenn wieder so ein Feed auftaucht. Jedesmal hin und her scheint mir aber nicht so prickelnd. Inzwischen habe ich vergleichen können. Der vergleich für die Feedsuche fällt - so leid es mir tut - eindeutig zu Gunsten von AltDVB aus. Dort ist alles direrkt erreichbar und besonders die Kanalverwaltung ist IMHO um Längen voraus.

 

Naja, man kann nicht alles haben. Für Couch Potatoes mit HDPC, die HDTV gucken wollen, ist der DVBViewer sicher erste Wahl. Einem DXer sind diese Eigenschaften meist weniger wichtig.