softhddevice - Software VDPAU/VA-API/CPU Decoder und Ausgabe Plugin

Zitat von johns

So neuer Audio/Video Sync Code ist nun im GIT.

Damit sind die von mir weiter oben beschriebenen "[softhddev] invalid PES video packet_ " Fehler bei den "speziellen" Senden nun auch weg.

...Bleibt nur noch das Problem nit dem Audiomanagement.

Zitat von johns

So neuer Audio/Video Sync Code ist nun im GIT.
Im Großen und Ganzen hat sich nicht viel geändert.
Nur werden bei Interlaced Sourcen nicht gleich zwei Halbbilder mehr ausgelassen.
Ansonsten sollte nun PES (alte VDR Aufnahmen) Trickspeed funktionieren.

Relativiere doch nicht immer deine Arbeit Das waren mal wieder über 900 veränderte Codezeilen.

Zitat von C-3PO

Damit sind die von mir weiter oben beschriebenen "[softhddev] invalid PES video packet_ " Fehler bei den "speziellen" Senden nun auch weg.

Naja ich bekomme die Meldung zweimal, kurz nach dem Umschalten. Sonst bleibt aber alles ziemlich still.

johns: Das alte "decoder renderer too slow" Problem ist leider immernoch da. Ich hatte gehofft der neue NVIDIA Treiber hätte es beseitigt...

Apr  1 12:52:35 vdr vdr: video/vdpau: decoder render too slow 73ms
Apr  1 12:52:35 vdr vdr: video: decoder buffer empty, duping frame (162/6) 0 v-buf
Apr  1 12:52:35 vdr vdr: video/vdpau: missed frame (1/15422)

Es scheint aber stark eingeschränkt zu sein. Vorher wurden ja mehrere Frames verworfen. Jetzt nur noch eines.

Anbei mal (ggf. für späteres Feintuning) ein Log hinsichtlich Empfangsaussetzer meiner DVB-C Karte:

http://pastebin.com/myPdjCrc

Reaktion des Plugins:
Bei zu starken/langen Störungen ist Bild/Ton eingeforen (Pixelsalat). Ein umschalten auf andere Kanäle (DVB-S, DVB-C) wird per OSD angezeigt, aber es kommt kein Bild/Ton.
Ein SUPEND mit anschliessenden RESUME des Plugins bringt Abhilfe.

Ggf. kann man ja eine Art Timeout einführen, sofern der schlechte Empfang erkennbar ist, welches eine OSD-Meldung ausgibt mit anschliessendem Reset (SUSP/RESU).

Marcus

Zitat von jack-itb

Es sind wohl doch die Buffer.
Wenn ich die Buffer am Anfang von AlsaSetup neu initialisiere klappts mit 5.0:

Hi, just to let you know, I have exactly the same problem.
Reinit the buffer is also a working bypass.

Greetings

Hallo johns,

ich erweitere gerade meinen Zoom-Patch um das Abschneiden der Ränder je Auflösung festlegen zu können; es hat sich gezeigt, dass das nötig ist.

Allerdings hänge ich an einem kleinen Problem:

Ich habe die Funktion um "resolution" erweitert:

static void VideoUpdateOutput(AVRational input_aspect_ratio, int input_width,
    int input_height, int *output_x, int *output_y, int *output_width,
    int *output_height, int *crop_x, int *crop_y, int *crop_width,
    int *crop_height, VideoResolutions *resolution)                                 
{
    AVRational display_aspect_ratio;


    if (!input_aspect_ratio.num || !input_aspect_ratio.den) {
	input_aspect_ratio.num = 1;
	input_aspect_ratio.den = 1;
	Debug(3, "video: aspect defaults to %d:%d\n", input_aspect_ratio.num,
	    input_aspect_ratio.den);
    }


    av_reduce(&display_aspect_ratio.num, &display_aspect_ratio.den,
	input_width * input_aspect_ratio.num,
	input_height * input_aspect_ratio.den, 1024 * 1024);


    // InputWidth/Height can be zero = uninitialized
    if (!display_aspect_ratio.num || !display_aspect_ratio.den) {
	display_aspect_ratio.num = 1;
	display_aspect_ratio.den = 1;
    }


    Debug(3, "video: aspect %d:%d\n", display_aspect_ratio.num,
	display_aspect_ratio.den);


    *crop_x = VideoCutHeight[resolution];
    *crop_y = VideoCutWidth[resolution];
    *crop_width = input_width - VideoCutWidth[resolution] * 2;
    *crop_height = input_height - VideoCutHeight[resolution] * 2;

VideoUpdateOutput(decoder->InputAspect, decoder->InputWidth,
	decoder->InputHeight, &decoder->OutputX, &decoder->OutputY,
	&decoder->OutputWidth, &decoder->OutputHeight, &decoder->CropX,
	&decoder->CropY, &decoder->CropWidth, &decoder->CropHeight,
  &decoder->Resolution);

Allerdings wirft mir der Compiler einen Fehler aus:

video.c: In Funktion »VideoUpdateOutput«:
video.c:471:29: Fehler: Feldindex ist keine Ganzzahl
video.c:472:28: Fehler: Feldindex ist keine Ganzzahl
video.c:473:46: Fehler: Feldindex ist keine Ganzzahl
video.c:474:49: Fehler: Feldindex ist keine Ganzzahl

Wie stelle ich das den richtig an? Da ich mit C++ gerade erst anfange, bin ich hier mit meinem Latein am Ende.
Der Rest des Patches ist bereits fertig und steht quasi kurz vor dem Test, nur ohne dies wird es ja wohl nicht richtig funktionieren.

CafeDelMar

Zitat von johns

Wäre das Richtige, nach vorne weil es ein Eingangswert ist. Also ohne "*".

Die Idee mit Abhängigkeit zur Auflösung hatte ich auch schon, aber langsam wird es richtig kompiliziert für Anfänger.

Danke, johns, jetzt kompiliert es. Zum Testen komme ich erst morgen, wenn es funktioniert, poste ich den Patch hier.

Ich bin hier schon wieder in die Falle mit der Dereferenzierung getappt, das macht C/C++ nicht gerade einfach.
Das mit den Input- und Output-Variablen ist auch logisch, soweit hatte ich gar nicht gedacht.

CafeDelMar

Hallo johns,

anbei ist der fertige Patch für auflösungsabhängigen Overscan gegen die (mittlerweile) vorletzte GIT-Version. Hiermit kann nun bei 1080i ein 1:1 Pixel-Mapping realisiert werden und gleichzeitig bei anderen Auflösungen ein beliebiger Overscan erfolgen. Werte zwischen 3% und 5% auf die jeweilige Auflösung bezogen sollten sinnvoll sein; die Einstellung erfolgt jedoch nach wie vor in Pixeln.

Die Parameter habe ich nun CutHeight und CutWidth genannt, Du kannst es bei Bedarf ja umbenennen, einen Bruch mit vorherigen Versionen gibt es ja so oder so.

Das Ganze funktioniert soweit auch wie gewünscht, allerdings ist mir aufgefallen, dass das Videobild bei einem AutoCrop nun um "CutWidth" aus der Mitte verschoben ist. Ich denke, der Cut-Wert muss nur bei der Berechnung der Bildmitte mit berücksichtigt werden, hier traue ich mich aber ohne tieferes Wissen von der Funktion Deines Codes nicht ran.

CafeDelMar

Hallo Johns,
Mein Frage ist zwar Off Topic, da das hier kein C++ Thread für Anfänger wie ich es bin ist.
Wenn CafeDelMar seine Funktionsdefinition nicht geändert hätte also mit

VideoResolutions *resolution

Das hier funktioniert nicht:

*crop_x = VideoCutHeight[resolution];

Da er hier den Wert des Pointers braucht.
Wäre das hier richtig ?

*crop_x = VideoCutHeight[*resolution];

Da er den Wert nicht verändern will/muss ist dein Vorschlag natürlich besser - Ich will es nur Verstehen

Und noch gleich was:

Mit der letzten GIT-Version habe ich nun Probleme bei Aufnahmen mit AC3 auf ProSieben (z.B. Terra Nova, Touch), andere Sender noch nicht getestet.
Sobald es auf die Werbung zugeht, kommt bereits der Ton der Werbung, es läuft aber noch das Bild des Films weiter, wo dann logischerweise der Ton des Films fehlt.
Wenn es von der Werbung wieder auf den Film zugeht ist es entsprechend andersherum, es läuft noch Werbung aber es kommt schon der Ton vom Film.
Das Ganze ist reproduzierbar mit mehreren Aufnahmen und lief vor dem AV-Sync-Rewrite noch anstandslos. Getestet mit und ohne AC3_DRIFT_CORRECTION.

Hier das schmale Log, was kurz nach einem Übergang ausgeworfen wird:

Apr  3 19:18:13 vdr vdr: audio/alsa: using ac3 device 'hdmi:AES0=0x6,CARD=1'
Apr  3 19:18:13 vdr vdr: audio/alsa: delay 264ms
Apr  3 19:18:18 vdr vdr: audio/alsa: wait underrun error? 'Datenübergabe unterbrochen (broken pipe)'
Apr  3 19:18:24 vdr vdr: video: decoder buffer empty, duping frame (745/6214) 0 v-buf
Apr  3 19:18:24 vdr vdr: video: 13:22:39.758-6719  346 520/\ms 189 v-buf

CafeDelMar

Zitat von CafeDelMar

Und noch gleich was:

Mit der letzten GIT-Version habe ich nun Probleme bei Aufnahmen mit AC3 auf ProSieben (z.B. Terra Nova, Touch), andere Sender noch nicht getestet.
Sobald es auf die Werbung zugeht, kommt bereits der Ton der Werbung, es läuft aber noch das Bild des Films weiter, wo dann logischerweise der Ton des Films fehlt.
Wenn es von der Werbung wieder auf den Film zugeht ist es entsprechend andersherum, es läuft noch Werbung aber es kommt schon der Ton vom Film.
Das Ganze ist reproduzierbar mit mehreren Aufnahmen und lief vor dem AV-Sync-Rewrite noch anstandslos. Getestet mit und ohne AC3_DRIFT_CORRECTION.

Hier das schmale Log, was kurz nach einem Übergang ausgeworfen wird:

Code

Apr  3 19:18:13 vdr vdr: audio/alsa: using ac3 device 'hdmi:AES0=0x6,CARD=1'
Apr  3 19:18:13 vdr vdr: audio/alsa: delay 264ms
Apr  3 19:18:18 vdr vdr: audio/alsa: wait underrun error? 'Datenübergabe unterbrochen (broken pipe)'
Apr  3 19:18:24 vdr vdr: video: decoder buffer empty, duping frame (745/6214) 0 v-buf
Apr  3 19:18:24 vdr vdr: video: 13:22:39.758-6719  346 520/\ms 189 v-buf

CafeDelMar

Alles anzeigen

Kann ich bestätigen. Ist auch bei mir so mit dem nebeneffekt das nach Schnittmarkensprung der Ton um ca. 2s verschoben ist. Ein Stop und Restart der Wiedergabe bringt wieder alles ins lot.

Zitat von johns

Ich hatte sowas Ähnliches auch schon gemerkt, aber immer wenn ich eine Aufnahme mit Debug angeschaut habe, konnte ich es nicht reproduzieren.
Aber es könnte mit der Werbung und einer anderer Tonspur oder anderer Zeitstempel zusammenhängen
Werde es mal überprüfen,
Johns

Also ganz genau gesagt, passiert es immer beim Wechsel von AC3 auf Stereo und umgekehrt. Beim ersten wird der AC3-Ton zu früh abgeschnitten und der Stereo-Ton zu früh eingemischt, beim zweiten ist es entsprechend andersherum. Dieser Versatz von wenigen Sekunden bleibt dann auch bei der weiteren Wiedergabe bestehen. Nur ein Stopp (keine Pause) und Neustart der Aufnahme innerhalb der gleichen Tonnorm behebt das Problem bis zum nächsten Wechsel. Es betrifft übrigens auch andere Aufnahmen mit AC3 (HD, SD, ÖR, Privat).

CafeDelMar

PS: Auch wenn das AC3-Problem mir/insgesamt viel viel wichtiger ist, konntest Du schon einen Blick auf meinen neuen Patch werfen? Wenn ich hier wüsste, wie ich das AutoCrop wieder zentrieren kann, baue ich das auch gerne direkt selbst ein.

Zitat von johns

Bin noch am überlegen ob CutLeftRight und CutTopBottom besser ist als CutWidth und CutHeight.

CutLeftRight und CutTopBottom wären etwas präziser, da damit unterstrichen wird, dass an jeweils beiden Seiten etwas abgeschnitten wird.
ZoomWidth und ZoomHeight wäre wohl das gängigste, aber da geht man dann wohl eher von einem Zoom-Faktor in Prozent und nicht in abzuschneidenden Pixeln aus.

Sag einfach, wie es Dir am besten gefällt und ich ändere das ggf, ist ja keine große Sache.

Zitat von johns

Müsste es wieder in der Mitte platzieren.

Oh, klar, ist ja logisch, hatte ich beim ersten Patch aber auch schon übersehen. Ich habe es bereits geändert und werde es schnellstmöglich testen.

Hallo Johns,

anbei ist jetzt der finale Patch gegen die aktuelle GIT-Version.

Die BBC empfiehlt einen minimalen Overscan von etwa 3,5%, womit sich folgende Werte ergeben:

softhddevice.576i.CutLeftRight = 13
softhddevice.576i.CutTopBottom = 10
softhddevice.720p.CutLeftRight = 19
softhddevice.720p.CutTopBottom = 13

Dies scheint bisher auch ganz gut zu passen.

CafeDelMar

Und folgendes ist mir noch mit der GIT-Version vom 03.04. aufgefallen:

Bei alten PES-Aufnahmen, nur ein paar durchprobiert, kommt es zu häufigen Bildrucklern.
Folgendes steht dann in etwa im Log:

Apr  5 20:09:15 vdr vdr: video/vdpau: missed frame (118/82866)
Apr  5 20:09:30 vdr vdr: [softhddev] empty video packet 986 bytes
Apr  5 20:09:31 vdr vdr: [softhddev] empty video packet 263 bytes
Apr  5 20:09:39 vdr vdr: video/vdpau: decoder render too slow 90ms
Apr  5 20:09:41 vdr vdr: video/vdpau: missed frame (121/84082)
Apr  5 20:09:41 vdr vdr: video:  1:11:53.898   -2  825 240/\ms 189 v-buf
Apr  5 20:09:43 vdr vdr: [softhddev] empty video packet 2048 bytes
Apr  5 20:09:43 vdr vdr: [softhddev] empty video packet 1277 bytes
Apr  5 20:09:43 vdr vdr: [softhddev] empty video packet 794 bytes
Apr  5 20:09:44 vdr vdr: [softhddev] empty video packet 299 bytes
Apr  5 20:09:51 vdr vdr: [softhddev] empty video packet 724 bytes
Apr  5 20:09:52 vdr vdr: [softhddev] empty video packet 12 bytes

Das kann natürlich an der Aufnahme liegen, aber ich bin mir sicher, dass diese zuvor mit der SD-FF-Karte fehlerfrei abgespielt wurden.

Das AutoCrop funktioniert nicht immer gut.
Ich hatte es schon öfter, dass oben und unten (teilweise auch jeweils unterschiedlich groß) noch ein schwarzer Restbalken stehen blieb. Bei sehr dunklen Szenen konnte ich auch schon ein heftiges Hin- und Herspringen beobachten.
Ich verwende die von Dir empfohlenen Einstellungen.
BTW: Irgendwann für später fände ich hier die Möglichkeit eines weichen Aufziehens wie bei Xineliboutput sehr wünschenswert.

CafeDelMar

PS: Ich teste jetzt erstmal die aktuelle GIT mit den Problem-AC3-Videos.