Moin!
Ich würde die Erweiterung von HasDecoder auch eher sein lassen. Ein Ausgabedevice weiß doch selbst, was es kann und es kann auch selbst per PatPmtParser o.ä. die passenden Infos heraussuchen.
Es sollte nicht verdauliche Daten einfach stillschweigend unter den Tisch fallen lassen. Dann kann es immer noch z.B. Ton ausgeben, aber eben kein Bild dazu etc.
Lars.
Ein Ausgabedevice weiß doch selbst, was es kann und es kann auch selbst per PatPmtParser o.ä. die passenden Infos heraussuchen.
Es sollte nicht verdauliche Daten einfach stillschweigend unter den Tisch fallen lassen. Dann kann es immer noch z.B. Ton ausgeben, aber eben kein Bild dazu etc.
Die Abhängigkeiten vergrößern das Problem anstatt es zu verbessern.
OK, dann lass ich das - ist mir eh lieber ;-).
Klaus
Genau deswegen ist dies kein MPEG2-Header, denn diese verwenden alle den Start-Code 00 00 01.
Kommt darauf an, wie man den Header sucht, DVB-Snoop findet die zumindestens.
Ich konnte bislang auch nicht finden, dass der MPEG2-Header direkt nach dem PES-Header kommen muss. Denke aber, dass sich da praktisch alle dran halten, da es sicher einige Decoder gibt die den MPEG2-Header direkt nach dem PES-Header erwarten.
Der Header ist in der aktuellen H.264 übrigens auf Seite 304 beschrieben.
Interessanterweise verwenden auch H.264 PES-Pakete die MPEG2-PES-Extension.
Das ist laut H.222 auch richtig so.
(Mit etwas suchen war eine ausreichend aktuelle Ausgabe zu finden.)
Ich komme zwar auf absehbare Zeit nicht dazu, UFOs Patch zu testten (bin mal wieder auf Tour), aber ich könnte mir vorstellen, dass die Prüfung dort viel zu häufig erfolgt und somit zu einer höheren Systemlast führt.
Das ist nur eine Abfrage pro PES-Paket und die Schleife läuft ohnehin.
Bei den zu erwartenden maximal 60 Video-PES-Paketen pro Sekunde sehe ich das sogar mit meiner aktuellen Hardware sehr entspannt 
.
Als Anmerking, iirc senden BBC beliebige viele 0 vor dem PES Startcode, ist sowas wie unser NALU Füller.
Das ist laut H.264 erlaubt (s.o.).
Das ist laut H.264 erlaubt (s.o.).
Die Frage ist, ist es auch bei Mpeg erlaubt?
Ich kann es nicht mehr nachvollziehen ob es Mpeg oder H264 Aufnahmen waren.
Johns
Die Frage ist, ist es auch bei Mpeg erlaubt?
In MPEG-2 sind beliebig viele Nullen vor einem Startcode erlaubt, solange mindestens 2 Nullen vor einer 0x01 kommen, denke ich.
Gruss,
S:oren
Anbei ein aktualisierter Patch, der das Problem behebt.
Hat jemand ein Problem mit diesem Patch festgestellt?
Hier funktioniert er einwandfrei.
CU
Oliver
Probleme hab ich bislang auch nicht festgestellt, wirklich viel getestet habe ich aber bislang nicht.
Auch die getestete PES-Aufnahme lief, genau wie das Wiedergabe von HD-Kanälen mit der FF als Empfangskarte (Karte hat den FullTS-Mod).
Versuche HD-Aufnahmen abzuspielen brachten die Karte auch nicht aus dem Tritt.
Hallo zusammen,
ich habe bis vor kurzem noch VDR 1.6 betrieben mit einer Hauppauge Nexus-S 2.2 sowie einer Tevion Cinergy 1200 (Kabel).
Es war als ein reines SD System; mit der FF hatte ich nie Probleme (auch bei einer Aufnahme von ORF war bis auf träges OSD alles ok, keine Ruckler); die Karte verfügt über keinen Full-TS Mod.
Da ich nun HD-Sender über eine Enigma2 Box schaue, soll der VDR nur noch zur Aufnahme von HD dienen, die ich dann per NFS schaue; ich habe ihn dafür mit VDR 1.7.42 ausgetattet und zusätzlich eine Tevii S470 eingebaut (die hat das Satkabel, die FF dient _NUR_ noch zur Ausgabe von SD (--outputonly) an meinen Schlafzimmerröhrentv). Nur noch mal um sicherzugehen, FULL-TS Mod ist an dieser Stelle nicht nötig, da die Karte den PES bekommt zum Anzeigen?
Nach dem Umschalten hatte ich allgemein immer ziemlich lange ein Ruckeln, was sich allerdings mit Erhöhen der PCI Latenz auf 128 für die FF beseitigen liess. Was jetzt allerdings auftritt, dass ich bei ORF immer wieder Störungen habe, es ruckelt. Signal ist in Ordnung (lief ja vorher mit 1.6er und direkt über die FF auch, FEmon auch OK). Wenn es ruckelt wird meistens TS packet not accepted in Transfer Mode ausgegeben, jedoch nicht immer. Wenn die Meldung nicht erscheint, ruckelt es "schwächer" - greift hier evtl. der Retry?
Die TS meldungen sind mir auf anderen Sendern noch nicht untergekommen, obwohl es dort teilweise auch mal stockt.
Aufnahmen scheinen, soweit ich das jetzt schon sagen kann, nicht betroffen zu sein.
Hat jemand eine Idee, woher das Ruckeln kommt und wie ich das ggf weiter Debuggen kann?
Ich verwende im übrigen Kernel 3.5.7 und die dort integrieren DVB-Treiber. Schaltet man den VDR auf einen HD Sender gibt es kein Bild, nur stockenden Ton. Kann ich daher von der Annahme ausgehen, dass die Änderungen, die UFO durchgeführt hatte dort nicht enthalten sind? Ich habe da noch keinen Blick in die Sourcen geworfen. Allerdings habe ich das Ruckeln auch, wenn ich zuvor nicht auf einem HD Sender war, aber ich weiss auch nicht, inwie fern die Karte (trotz Neustart) irgendwas "defektes" im Speicher halten kann.
PS: Sorry, eigentlich passt es nicht in den Thread, jedoch passt die ganze Diskussion nicht zum Thema Emergency Exit und hier wurde das Problem am ehesten diskutiert. Immerhin kann ich bestätigen, dass Aufnahmen offenbar nicht betroffen sind und der "neue" Mechanismus von kls funktioniert.
Grüße
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!
