VDR Portal

Quoted from "FireFly"

Quoted from "Freddy"

Wann kann eigentlich dieser Fall eintreten?

Wenn der Kernel meint, der IRQ kommt vom Device, für den der Treiber zuständig ist, aber die HW dahinter hat gar keinen ausgelöst. Kann IMHO nur bei shared Interrupts kommen, evtl. reicht der Kernel die Interrupts auch an alle Treiber weiter, die diesen IRQ registriert haben bis ein Treiber signalisiert, das er ihn behandelt hat.

Danke für die Info, FireFly. Ich hätte folgende Kandidaten:

Trifft es auch bei Message Signaled Interrupts zu? Denn laut cat /proc/interrupts ändert sich bei 16 nichts:

Bevor ihr noch ewig mit EAGAIN in PlayTsVideo kämpft:

Es ist vollkommen normal, dass EAGAIN in PlayTsVideo auftritt. Die Funktion heißt aus gutem Grund WriteAllOrNothing: -1/EAGAIN ist genau der "or nothing" Teil! Der Aufrufer der PlayTs-Funktion ist verpflichtet, auf EAGAIN zu reagieren, und die Daten später noch einmal anzubieten.

Bei Wiedergabe von Aufzeichnungen füttert VDR das Device so lange mit Daten, bis die Play-Funktionen mit EAGAIN signalisieren, dass sie voll sind. Würde man dann einfach Daten verwerfen, würde er in Festplatten-Lesegeschwindigkeit durch die Aufnahme jagen, und fast nichts anzeigen.

Im Transfer-Modus kommen die Daten genau in dem Tempo vom Sender, wie sie die Karte wiedergibt. Damit beide die exakt gleiche Geschwindigkeit einhalten, synchronisiert sich das Ausgabedevice mit der Program Clock Reference des Senders. Daher sollte EAGAIN in dieser Situation überhaupt nicht auftreten. Wenn es hier dennoch so massiv auftritt, ist es meiner Meinung nach eher ein Hinweis darauf, dass das Ausgabedevice seine Wiedergabe gar nicht begonnen hat. Ein Versuch eines Workarounds wäre, einfach nochmal die notwendigen Kommandos an die Karte zu schicken, die die Wiedergabe starten sollen.

Als - vermutlich nicht zusammenhängende - Randnotiz: Mir ist schon mehrfach aufgefallen, dass manchmal die Umschaltung zwischen Play und Pause fehlerhaft ist, und bei Play nur der Ton losläuft, das Bild aber nicht. Selbst beim Umschalten von Pause auf Live-Modus habe ich das schon beobachtet. Ein 'harter' Sprung im Videostream (Seek der Aufnahme oder Senderwechsel) hilft dann.

Gruß,

Udo

Hi,

eine Quelle habe ich für "unknown interrupt source" gefunden: ISR_FE_READY_MASK wird nicht berücksichtigt. Muss man hier noch irgendwas (anders) machen, als das, was in dem if-Block für unbekannte Interrupts passiert?

@Udo: danke für die Infos , wo lernt man sowas?

Ich kämpfe immer noch gegen osd bzw. data timeouts...

Quoted from "Urig"

Im Transfer-Modus kommen die Daten genau in dem Tempo vom Sender, wie sie die Karte wiedergibt. Damit beide die exakt gleiche Geschwindigkeit einhalten, synchronisiert sich das Ausgabedevice mit der Program Clock Reference des Senders. Daher sollte EAGAIN in dieser Situation überhaupt nicht auftreten. Wenn es hier dennoch so massiv auftritt, ist es meiner Meinung nach eher ein Hinweis darauf, dass das Ausgabedevice seine Wiedergabe gar nicht begonnen hat. Ein Versuch eines Workarounds wäre, einfach nochmal die notwendigen Kommandos an die Karte zu schicken, die die Wiedergabe starten sollen.

Danke für die Hinweise! Hast Du eine Idee, welches Kommando das sein könnte?

Quoted from "Urig"

Als - vermutlich nicht zusammenhängende - Randnotiz: Mir ist schon mehrfach aufgefallen, dass manchmal die Umschaltung zwischen Play und Pause fehlerhaft ist, und bei Play nur der Ton losläuft, das Bild aber nicht. Selbst beim Umschalten von Pause auf Live-Modus habe ich das schon beobachtet. Ein 'harter' Sprung im Videostream (Seek der Aufnahme oder Senderwechsel) hilft dann.

Bei mir passiert es auch gelegentlich, dass nachdem ich auf Pause gedrückt habe, die Aufnahme noch mehrere Sekunden weiter läuft und dann erst pausiert.

Quoted from "Urig"

Bevor ihr noch ewig mit EAGAIN in PlayTsVideo kämpft:

Es ist vollkommen normal, dass EAGAIN in PlayTsVideo auftritt. Die Funktion heißt aus gutem Grund WriteAllOrNothing: -1/EAGAIN ist genau der "or nothing" Teil! Der Aufrufer der PlayTs-Funktion ist verpflichtet, auf EAGAIN zu reagieren, und die Daten später noch einmal anzubieten.

Bei Wiedergabe von Aufzeichnungen füttert VDR das Device so lange mit Daten, bis die Play-Funktionen mit EAGAIN signalisieren, dass sie voll sind. Würde man dann einfach Daten verwerfen, würde er in Festplatten-Lesegeschwindigkeit durch die Aufnahme jagen, und fast nichts anzeigen.

So weit richtig.

Quoted

Im Transfer-Modus kommen die Daten genau in dem Tempo vom Sender, wie sie die Karte wiedergibt. Damit beide die exakt gleiche Geschwindigkeit einhalten, synchronisiert sich das Ausgabedevice mit der Program Clock Reference des Senders.

Das ist falsch. Für das Ausgabedevice ist Transfermode das gleiche wie Wiedergabe von der Platte. Nix mit PCR!

So war es bei der alten FF-Karte (und ich vermute, hier ist es genauso):
Die Karte läuft mit ihrer internen STC. Die Clock-Abweichung zwischen Sender und Wiedergabe wird durch Pufferung in VDR bzw. Treiber ausgeglichen.

Quoted

Daher sollte EAGAIN in dieser Situation überhaupt nicht auftreten. Wenn es hier dennoch so massiv auftritt, ist es meiner Meinung nach eher ein Hinweis darauf, dass das Ausgabedevice seine Wiedergabe gar nicht begonnen hat. Ein Versuch eines Workarounds wäre, einfach nochmal die notwendigen Kommandos an die Karte zu schicken, die die Wiedergabe starten sollen.

Meine *Vermutung* ist, daß beim gepatchten Plugin die Daten an die Karte ausgegeben werden, wenn sie diese gar nicht annehmen kann. Dann laufen die Ringbuffer in VDR und Treiber über. Artefakte sind das Ergebnis.

Daher mein Vorschlag, in so einem Fall die Daten wegzuwerfen. (Damit der Ringpuffer in VDR geleert wird.)
Sollte klar sein, daß man dies nur im Transfermode machen darf, nicht bei Wiedergabe einer Aufzeichnung!

Quoted

Als - vermutlich nicht zusammenhängende - Randnotiz: Mir ist schon mehrfach aufgefallen, dass manchmal die Umschaltung zwischen Play und Pause fehlerhaft ist, und bei Play nur der Ton losläuft, das Bild aber nicht. Selbst beim Umschalten von Pause auf Live-Modus habe ich das schon beobachtet. Ein 'harter' Sprung im Videostream (Seek der Aufnahme oder Senderwechsel) hilft dann.

Ich vermute, daß bei der A/V-Synchronisation noch irgendetwas faul ist. Manchmal fehlt ja auch der Ton.

CU
Oliver

Ich habe versucht, alles mögliche auszugeben, die ich im Treiber ausgeben kann Nun, wirklich schlauer bin ich nach 14 Stunden rumprobieren immer noch nicht. Das einzige, was aus den Logs ausgeht, ist, dass nach einiger Zeit im Interrupt-handler die Ereignisse ISR_DATA_MASK und ISR_OSD_READY_MASK nicht mehr eintreten, dadurch die WaitQueues nicht mehr aufgeweckt werden, was letzendlich zu den timeouts führt. Hat jemand eine Idee, wo die Ursache liegen könnte? Ich habe sogar die Anzahl Bytes zusammengezählt, die erfolgreich übertragen werden, bevor es zum timeout kommt. Es sind aber doch recht unterschiedliche, mal um die 16 MB, mal 26 MB.

Quoted from "UFO"

Es ist vollkommen normal, dass EAGAIN in PlayTsVideo auftritt. Die Funktion heißt aus gutem Grund WriteAllOrNothing: -1/EAGAIN ist genau der "or nothing" Teil! Der Aufrufer der PlayTs-Funktion ist verpflichtet, auf EAGAIN zu reagieren, und die Daten später noch einmal anzubieten.

Daraus ergeben sich mir ein paar Fragen:
-Ist es denn so, dass die PlayTs Funktion der normalen device.c verwendet wird?
-Wird das Verhalten, die Daten noch einmal anzubieten, nicht sowieso durch die Funktion "cTransfer::Receive" in der transfer.c abgedeckt (100x10ms warten...)?

Quoted from "UFO"

Meine *Vermutung* ist, daß beim gepatchten Plugin die Daten an die Karte ausgegeben werden, wenn sie diese gar nicht annehmen kann. Dann laufen die Ringbuffer in VDR und Treiber über. Artefakte sind das Ergebnis.

Was können wir tun, um Deine Vermutung zu bestätigen und der Ursache auf den Grund zu gehen?

Quoted from "UFO"

Daher mein Vorschlag, in so einem Fall die Daten wegzuwerfen. (Damit der Ringpuffer in VDR geleert wird.)
Sollte klar sein, daß man dies nur im Transfermode machen darf, nicht bei Wiedergabe einer Aufzeichnung!

Sollte dafür dann die transfer.c geändert werden oder gibt es eine Art Flag, falls in der PlayTsVideo eine Aufzeichnung verarbeitet wird?

Quoted from "Freddy"

Ich habe versucht, alles mögliche auszugeben, die ich im Treiber ausgeben kann Nun, wirklich schlauer bin ich nach 14 Stunden rumprobieren immer noch nicht. Das einzige, was aus den Logs ausgeht, ist, dass nach einiger Zeit im Interrupt-handler die Ereignisse ISR_DATA_MASK und ISR_OSD_READY_MASK nicht mehr eintreten, dadurch die WaitQueues nicht mehr aufgeweckt werden, was letzendlich zu den timeouts führt. Hat jemand eine Idee, wo die Ursache liegen könnte? Ich habe sogar die Anzahl Bytes zusammengezählt, die erfolgreich übertragen werden, bevor es zum timeout kommt. Es sind aber doch recht unterschiedliche, mal um die 16 MB, mal 26 MB.

Guck Dir mal die Funktion "static irqreturn_t saa716x_ff_pci_irq(int irq, void *dev_id)" in der "saa716x_ff_main.c" an. Nimm mal in Zeile 1277 die Kommentierung raus, vielleicht siehst Du dann mehr.

Quoted from "Mr_T"

Quoted from "UFO"

Es ist vollkommen normal, dass EAGAIN in PlayTsVideo auftritt. Die Funktion heißt aus gutem Grund WriteAllOrNothing: -1/EAGAIN ist genau der "or nothing" Teil! Der Aufrufer der PlayTs-Funktion ist verpflichtet, auf EAGAIN zu reagieren, und die Daten später noch einmal anzubieten.

Daraus ergeben sich mir ein paar Fragen:
-Ist es denn so, dass die PlayTs Funktion der normalen device.c verwendet wird?

Ja, denn es gibt keine gleichnamige Methode in dvbhdffdevice bzw. dvbddevice.

Quoted

-Wird das Verhalten, die Daten noch einmal anzubieten, nicht sowieso durch die Funktion "cTransfer::Receive" in der transfer.c abgedeckt (100x10ms warten...)?

Es liegt imho nicht daran, daß die Daten nicht nocheinmal angeboten würden. Afaik macht VDR dies doch sowieso.

Quoted

Quoted from "UFO"

Meine *Vermutung* ist, daß beim gepatchten Plugin die Daten an die Karte ausgegeben werden, wenn sie diese gar nicht annehmen kann. Dann laufen die Ringbuffer in VDR und Treiber über. Artefakte sind das Ergebnis.

Was können wir tun, um Deine Vermutung zu bestätigen und der Ursache auf den Grund zu gehen?

Quoted from "UFO"

Daher mein Vorschlag, in so einem Fall die Daten wegzuwerfen. (Damit der Ringpuffer in VDR geleert wird.)
Sollte klar sein, daß man dies nur im Transfermode machen darf, nicht bei Wiedergabe einer Aufzeichnung!

Sollte dafür dann die transfer.c geändert werden oder gibt es eine Art Flag, falls in der PlayTsVideo eine Aufzeichnung verarbeitet wird?

Sorry, um dies alles korrekt zu beantworten, müßte ich mir die Sourcen im Detail vornehmen und einiges ausprobieren. Dann kann ich mir das Wochenende gleich abschminken. Kommt nicht in Frage, das letzte ging schon für DVB-Treiber drauf. Ihr müßt das schon selbst machen.

Was man noch ausprobieren könnte:
Fängt sich das ganze, wenn man in femon auf den anderen Tuner umschaltet?

CU
Oliver

Wie kommt ihr denn darauf, dass die Overflows nur im Live-TV auftreten.

Wenn ich zb etwas SyFy oder Disney Channel (womöglich auch auf anderen SDTV-Sendern) aufnehme und dabei die Taste 4 oder 6 gedrückt halte um eine Marke zu verschieben bekomme ich die selben Overflows wie ihr.

Quoted from "UFO"

Das ist falsch. Für das Ausgabedevice ist Transfermode das gleiche wie Wiedergabe von der Platte. Nix mit PCR!

So war es bei der alten FF-Karte (und ich vermute, hier ist es genauso):
Die Karte läuft mit ihrer internen STC. Die Clock-Abweichung zwischen Sender und Wiedergabe wird durch Pufferung in VDR bzw. Treiber ausgeglichen.

... und wieder was gelernt.

Letztlich kann der Clock der Karte und der des Senders aber doch nie 100% synchron sein, d.H. es muss zwangsläufig irgendwann zu einem frame drop oder zu einem fehlenden frame kommen, oder?

Quoted

Daher mein Vorschlag, in so einem Fall die Daten wegzuwerfen. (Damit der Ringpuffer in VDR geleert wird.)
Sollte klar sein, daß man dies nur im Transfermode machen darf, nicht bei Wiedergabe einer Aufzeichnung!

Das macht ja der transfer mode: Nach 100 Versuchen bzw. 1 Sekunde verwirft er das Paket. So wird man natürlich nicht viele Daten los, vermutlich wird daher der Receiver eher Daten verlieren.

Quoted from "Mr_T"

Daraus ergeben sich mir ein paar Fragen:
-Ist es denn so, dass die PlayTs Funktion der normalen device.c verwendet wird?
-Wird das Verhalten, die Daten noch einmal anzubieten, nicht sowieso durch die Funktion "cTransfer::Receive" in der transfer.c abgedeckt (100x10ms warten...)?

Im Wesentlichen, ja.

Um den Weg der Daten mal nachzuzeichnen:

• cTransfer ist die Kombination eines cReceiver und eines cPlayer.
  
• Der cReceiver ist üblicherweise an ein cDvbDevice angehängt
  
• cDvbDevice öffnet das Quelldevice, und übergibt den filehandle an ein cTSBuffer
  
• cTSBuffer lässt in einem Thread (cTSBuffer::Action) einen 2Mb-cRingBufferLinear aus dem Device lesen (cRingBufferLinear::Read(int FileHandle...)). So lange der Buffer voll ist, wird auch nichts gelesen. cTSBuffer reagiert aber auf ein EOVERFLOW des Device ("driver buffer overflow on device 2"), falls der Treiber überläuft.
  
• Der Thread von cDevice (cDevice::Action) holt über cDvbDevice::GetTSPacket() die Daten aus dem cTSBuffer ab, und übergibt sie an die zugehörigen cReceiver mittels Receive(), und damit auch cTransfer::Receive.
  
• cTransfer::Receive übergibt die Daten unmittelbar an cPlayer::PlayTS - mit der 100x-Wiederholen Schleife.
  
• Ein cPlayer wiederum ist immer mit einem Ausgabedevice verbunden, hier mit dem cDvbHdFfDevice.
  
• cPlayer::PlayTs ist nur eine Weiterleitung an cDevice::PlayTs, welches ein wenig Streamanalyse macht, und die Daten unmittelbar auf PlayTsVideo und PlayTsAudio etc. verteilt.
  
• cDvbHdFfDevice::PlayTsVideo und -Audio übergeben die Daten dann per Filehandle an den Treiber der 6400.
  

Der einzige Buffer ist also der des Receivers. Durch die 100x wiederholen und das sleep bleibt der cDevice-Thread nahezu stehen, und holt nur 1 Paket pro Sekunde vom cTSBuffer ab. Dieser muss also vollaufen, und so bald dieser voll ist, läuft auch der Treiber selbst über. So bald die 100 Versuche durch sind (TS packet not accepted in Transfer Mode), wird ein Paket verworfen, es entsteht Platz für ein Paket in cTSBuffer, und cTSBuffer versucht, weiter aus dem Device zu lesen. Dabei fällt dann auf, dass der Treiber übergelaufen ist (driver buffer overflow on device 2).

Man könnte höchstens noch auf das EOVERFLOW mit einem Leeren des cTSBuffer reagieren, damit wieder normal Daten abgeholt werden. Nur, so lange das Ausgabe-Device keine Daten annimmt, wird sich die Situation dadurch auch nicht bessern...


Gruß,

Udo

Quoted from "Urig"

Quoted from "UFO"

Das ist falsch. Für das Ausgabedevice ist Transfermode das gleiche wie Wiedergabe von der Platte. Nix mit PCR!

So war es bei der alten FF-Karte (und ich vermute, hier ist es genauso):
Die Karte läuft mit ihrer internen STC. Die Clock-Abweichung zwischen Sender und Wiedergabe wird durch Pufferung in VDR bzw. Treiber ausgeglichen.

... und wieder was gelernt.

Letztlich kann der Clock der Karte und der des Senders aber doch nie 100% synchron sein, d.H. es muss zwangsläufig irgendwann zu einem frame drop oder zu einem fehlenden frame kommen, oder?

Völlig richtig. Allerdings sind die Pufferkapazitäten im Vergleich zur Abweichung so groß, daß dies erst nach sehr langer Zeit auftritt.
Wichtig ist natürlich, daß man die Ausgabe zum richtigen Zeitpunkt startet (Ringbuffer weder zu leer noch zu voll).

Quoted

Quoted

Daher mein Vorschlag, in so einem Fall die Daten wegzuwerfen. (Damit der Ringpuffer in VDR geleert wird.)
Sollte klar sein, daß man dies nur im Transfermode machen darf, nicht bei Wiedergabe einer Aufzeichnung!

Das macht ja der transfer mode: Nach 100 Versuchen bzw. 1 Sekunde verwirft er das Paket. So wird man natürlich nicht viele Daten los, vermutlich wird daher der Receiver eher Daten verlieren.

Falls man wirklich 1s warten muß, erfolgt zwangsläufig ein Pufferüberlauf - erst in VDR, dann im Treiber.
Und wenn gleichzeitig aufgezeichnet wird, ist die Aufnahme beschädigt.

Normalerweise sollten die 100 Versuche nicht zum Tragen kommen, es sei denn, es ist etwas faul.

CU
Oliver

Quoted from "MegaV0lt"

Ich habe nun mal ein 2 Minuten Stück geschnitten, wo eine zweite Tonspur (ENG) zugeschaltet wird (nach ca. einer Minute). Am VDR entstehen Bild- und Tonstörungen beim Abspielen. Der Fehler ist wohl in der Aufnahme schon drin, weil mit VLC der selbe Effekt zu sehen und Hören ist. Der Mediaplayer hingegen stürzt ab.

Die Datei enthält "Continuity Counter Errors", d.h. es fehlen Datenpakete. Klar, daß es dort eine Störung gibt.

Im Log steht nicht zufällig etwas von "retuning due to modification of channel". Das wäre dann die Ursache...

CU
Oliver

Moin!

Ich wollte noch mal den Treiber frisch holen und kompilieren, aber einige Sachen wollen nicht mehr:



Gibt es eine elegante Lösung, ausser die Datei manuell zu bearbeiten?



Ich habe einfach die Zeile in #include "altera.h" geändert. Welche Karte müsste man hier abwählen, damit das Kompilieren geht?



Dies führt dazu, dass die Treiber für meine alten Karten nicht mehr geladen werden können. Einen Patch habe ich hier gefunden, damit geht es.

@Mr_T: ich war gestern den ganzen Tag in der von dir erwähnte Datei mit einem Editor unterwegs. Dadurch habe ich meine Infos im vorherigen Post bekommen.

@UFO: wäre es denkbar, diesen Code in saa716x_ff_main.c aufzunehmen, natürlich nur, wenn es richtig ist:

Dadurch gibt es einen verwirrenden Eintrag weniger in syslog (direkt nach dem Laden des Treibers).

Gruß,
Freddy

Quoted from "UFO"

Quoted from "MegaV0lt"

Ich habe nun mal ein 2 Minuten Stück geschnitten, wo eine zweite Tonspur (ENG) zugeschaltet wird (nach ca. einer Minute). Am VDR entstehen Bild- und Tonstörungen beim Abspielen. Der Fehler ist wohl in der Aufnahme schon drin, weil mit VLC der selbe Effekt zu sehen und Hören ist. Der Mediaplayer hingegen stürzt ab.

Die Datei enthält "Continuity Counter Errors", d.h. es fehlen Datenpakete. Klar, daß es dort eine Störung gibt.

Im Log steht nicht zufällig etwas von "retuning due to modification of channel". Das wäre dann die Ursache...

CU
Oliver

Zwangsläufig! Da ja die Tonspur dazugeschaltet wird. Mit VDR1.6 ist die "Störung" aber minimal. Es fehlen ein paar Frames; aber Standbild, Verpixelung, stotternder Ton ist erst seit der TT-6400 und HD VDR 1.7... Die Störungen sind schon relativ stark (mehrere Sekunden!). Im Treiber kann bestimmt noch was verbessert werden - allein in Bezug auf den Ton beim Springen oder Spulen. In der Zeitlupe spielt komischerweise auch Ton...

Quoted from "MegaV0lt"

Quoted from "UFO"

Die Datei enthält "Continuity Counter Errors", d.h. es fehlen Datenpakete. Klar, daß es dort eine Störung gibt.

Im Log steht nicht zufällig etwas von "retuning due to modification of channel". Das wäre dann die Ursache...

CU
Oliver

Zwangsläufig! Da ja die Tonspur dazugeschaltet wird. Mit VDR1.6 ist die "Störung" aber minimal. Es fehlen ein paar Frames; aber Standbild, Verpixelung, stotternder Ton ist erst seit der TT-6400 und HD VDR 1.7... Die Störungen sind schon relativ stark (mehrere Sekunden!). Im Treiber kann bestimmt noch was verbessert werden - allein in Bezug auf den Ton beim Springen oder Spulen. In der Zeitlupe spielt komischerweise auch Ton...

Diesen Fall hatte ich auch schon, ca 1s nach Aufnahmebeginn ist das Bild für ca. 1s verpixelt und im VDR Log findet sich die retuning Meldung. IMHO hat VDR 1.6 dann das Broken-Link Flag im MPEG 2 Datenstrom gesetzt (Logmeldung: ""SetBrokenLink: no GOP header found in video packet") weshalb es dort nicht aufgefallen ist, aber mangels Streamanalyse im VDR 1.7 ist das nicht mehr möglich ist. Kann man das für MEPG2 im Treiber oder FW realisieren?

Für mein Problem habe ich einen bösen Würgaround gefunden. Könnte auch bei anderen helfen, wie mit verbose=3 im Syslog eine Timeout (osd command, command oder data) stehen haben, denn so wie der Code war, kann nach einem dieser Timeouts nichts mehr weitergehen:


Problem ist hier, dass wenn der Interrupt-handler static int __devinit saa716x_ff_pci_probe(struct pci_dev *pdev, const struct pci_device_id *pci_id) einmal (warum auch immer, hier wird das tatsächliche Problem liegen) nicht ausgeführt wird, wird weder sti7109->cmd_ready_wq aufgeweckt, noch sti7109->cmd_ready jemals wieder auf 1 gesetzt. Wenn man nach diesen Timeouts aus den Prozeduren nicht mit -EIO aussteigt, sondern die Kommandos einfach absetzt, läuft alles wunderbar weiter, die IRQ-s kommen wieder, und die entsprechenden WaitQueus werden schön wieder aufgeweckt.



Diese Änderungen habe ich jeweils in folgende Prozeduren eingebaut (jeweils NUR DIE ERSTE timeout-Prüfung). Ausserdem den timeout aus von 1 auf 0,1 reduziert.


Wenn's jemand probieren möchte, nur auf eigene Gefahr! Ich kann jedenfalls endlich die Karte genießen, ohne immer wieder zur Tastatur zu greifen, um den VDR neu zu starten. Es werden natürlich einige Befehle weiterhin nicht (richtig) ausgeführt, die Ursache des Problems ist mir immer noch unklar, dazu fehlen mir die Hardware-Level-Kenntnisse. Wie das OSD z.B. beim schnellen Vorlauf bei Wiedergabe aussieht und die Logfile dazu, sind im Anhang. Mit diesen Macken kann ich leben

Grüße,
Freddy.

Quoted from "MegaV0lt"

Quoted from "UFO"

Quoted from "MegaV0lt"

Ich habe nun mal ein 2 Minuten Stück geschnitten, wo eine zweite Tonspur (ENG) zugeschaltet wird (nach ca. einer Minute). Am VDR entstehen Bild- und Tonstörungen beim Abspielen. Der Fehler ist wohl in der Aufnahme schon drin, weil mit VLC der selbe Effekt zu sehen und Hören ist. Der Mediaplayer hingegen stürzt ab.

Die Datei enthält "Continuity Counter Errors", d.h. es fehlen Datenpakete. Klar, daß es dort eine Störung gibt.

Im Log steht nicht zufällig etwas von "retuning due to modification of channel". Das wäre dann die Ursache...

Zwangsläufig! Da ja die Tonspur dazugeschaltet wird.

Nein, das Zuschalten einer Tonspur verursacht keine Störung, sondern das Retuning!
Denn dadurch wird der Datenstrom bei den bereits vorhandenen PIDs kurzzeitig unterbrochen.

Dieses Verhalten liegt an VDR und nicht am Ausgabedevice. Ein Retuning ist unnötig, es würde genügen, die Tonspur zuzuschalten.

Quoted

Mit VDR1.6 ist die "Störung" aber minimal.

Liegt auch an VDR, denn 1.7 setzt z.B. an Schnittmarken nicht mehr das Broken Link Flag.
Auch mit der alten FF sieht man an Schnittmarken nun eine Verpixelung.

Daß die A/V-Synchronisation noch verbessert werden muß, habe ich weiter oben schon geschrieben:

Quoted

Es fehlen ein paar Frames; aber Standbild, Verpixelung, stotternder Ton ist erst seit der TT-6400 und HD VDR 1.7... Die Störungen sind schon relativ stark (mehrere Sekunden!). Im Treiber kann bestimmt noch was verbessert werden - allein in Bezug auf den Ton beim Springen oder Spulen. In der Zeitlupe spielt komischerweise auch Ton...

CU
Oliver

Quoted from "FireFly"

IMHO hat VDR 1.6 dann das Broken-Link Flag im MPEG 2 Datenstrom gesetzt (Logmeldung: ""SetBrokenLink: no GOP header found in video packet") weshalb es dort nicht aufgefallen ist, aber mangels Streamanalyse im VDR 1.7 ist das nicht mehr möglich ist. Kann man das für MEPG2 im Treiber oder FW realisieren?

Unsinn, man kann es - zumindest für MPEG2 - ganz einfach in VDR realisieren.

Den angehängten Patch habe ich hier im Einsatz (und schon vor langer Zeit an Klaus geschickt).

CU
Oliver

Quoted from "UFO"

Ein Retuning ist unnötig, es würde genügen, die Tonspur zuzuschalten.

Hat das schonmal jemand Klaus gesagt?