softhdcuvid/softhdvaapi/softhddrm with hevc and UHD

Murry

Ich habe folgendes auf meinem vdr2 getestet:

ffmpeg 3.4.4 mit dem von seahawk backportetem Patch compiliert, Deinen Patch in softhdcuvid eingespielt. Per streamdev auf WDR SD (Sat) und ONE SD (Sat) umgeschaltet - kein Problem. Ohne Deinen Patch hatte ich zuvor die gleichen Probleme.

Bis jetzt hatte ich keine Probleme, getestet mit Öffi DVB-T2 und Pro7 HD Sat.

Quote from jsffm

Bis jetzt hatte ich keine Probleme, getestet mit Öffi DVB-T2 und Pro7 HD Sat.

Und die SD Programme?

Sagte ich doch vorher, kein Problem.

Grad getestet und für gut befunden.

Fehlt eigentlich jetzt nur noch, dass man das OSD beim Fernsteuern (im Live-Plugin) sehen kann.

Jetzt hatte ich gerade doch auf meinem Prod-System (vdr3) wieder ein Problem mit PIP:

Oct 21 19:25:15 vdr3-2 vdr[28040]: [28040] [softhddev]CreateOsd: left 38, top 22, level 0, using OpenGL OSD support
Oct 21 19:25:15 vdr3-2 vdr[28040]: [28040] [softhddev]cOglOsd osdLeft 38 osdTop 22 screenWidth 1920 screenHeight 1080
Oct 21 19:25:24 vdr3-2 vdr[28040]: [3230] [softhddev]pip: invalid PES packet 8280
Oct 21 19:25:25 vdr3-2 vdr[28040]: video: normal aspect output 195x194+1591+54 Video 345x194
Oct 21 19:25:25 vdr3-2 vdr[28040]: CUVID Init ok 1920x1080
Oct 21 19:25:25 vdr3-2 vdr[28040]: video: normal aspect output 345x194+1516+54 Video 345x194
Oct 21 19:25:27 vdr3-2 vdr[28040]: [28040] [softhddev]CreateOsd: left 38, top 642, level 0, using OpenGL OSD support
Oct 21 19:25:27 vdr3-2 vdr[28040]: [28040] [softhddev]cOglOsd osdLeft 38 osdTop 642 screenWidth 1920 screenHeight 1080
Oct 21 19:25:44 vdr3-2 vdr[28040]: [3230] [softhddev] vom VDR kommt Clear:
Oct 21 19:25:44 vdr3-2 vdr[28040]: [3230] ERROR: 1 TS packet(s) not accepted in Transfer Mode
Oct 21 19:25:44 vdr3-2 vdr[28040]: audio/alsa: using pass-through device 'default'
Oct 21 19:25:44 vdr3-2 vdr[28040]: audio/alsa: start delay 336ms
Oct 21 19:25:44 vdr3-2 vdr[28040]: [3230] [softhddev] vom VDR kommt Clear:
Oct 21 19:25:44 vdr3-2 vdr[28040]: audio/alsa: using pass-through device 'default'
Oct 21 19:25:44 vdr3-2 vdr[28040]: audio/alsa: start delay 336ms
Oct 21 19:25:44 vdr3-2 vdr[28040]: [3230] [softhddev] vom VDR kommt Clear:
Oct 21 19:25:44 vdr3-2 vdr[28040]: audio/alsa: using pass-through device 'default'
Oct 21 19:25:44 vdr3-2 vdr[28040]: audio/alsa: start delay 336ms
Oct 21 19:25:44 vdr3-2 vdr[28040]: [3230] [softhddev] vom VDR kommt Clear:
Oct 21 19:25:45 vdr3-2 vdr[28040]: audio/alsa: using pass-through device 'default'
Oct 21 19:25:45 vdr3-2 vdr[28040]: audio/alsa: start delay 336ms
Oct 21 19:25:45 vdr3-2 vdr[28040]: [3230] [softhddev] vom VDR kommt Clear:
Oct 21 19:25:45 vdr3-2 vdr[28040]: audio/alsa: using pass-through device 'default'
Oct 21 19:25:45 vdr3-2 vdr[28040]: audio/alsa: start delay 336ms
Oct 21 19:25:45 vdr3-2 vdr[28040]: [3230] [softhddev] vom VDR kommt Clear:
Oct 21 19:25:45 vdr3-2 vdr[28040]: audio/alsa: using pass-through device 'default'

Beenden lies sich vdr nur noch mit kill -9

Quote from iNOB

Fehlt eigentlich jetzt nur noch, dass man das OSD beim Fernsteuern (im Live-Plugin) sehen kann.

Das vermisse ich auch noch ...

Ich habe auf nvidia 410.66 upgedated.

Bei mir läuft es nur in der Kombi: JoJos ffmpeg Patch und mit den Surfaces.

Bei den anderen Varianten wird das osd mit skindesigner nicht mehr richtig dargestellt.

Ich nutze ffmpeg-3.4.4.

Scheint ja ne knifflige Stelle zu sein.

Keine Probleme auf GT1030 mit nvidia 396.54, CUDA 9.1, ffmpeg 3.4.4 + patch , last commit softhdcuvid und skindesigner (git). Spulen, Schneiden, paralleles Aufnehmen, Powerzapping SD <> HD/UHD funzt. Nicht getestet, PIP.

Konnte gestern lediglich einmal einen Crash des vdr's beobachten, wobei ich den nicht auf softhdcuvid zurückführen konnte. Lag wohl eher daran, dass ich das epg während einer Aufnahme neu eingelesen habe (vdr-epg2vdr-plugin).

Noch eine Anmerkung zum PIP-Problem:

BT wird schwierig, da kein Absturz erfolgt. Das Erscheinungsbild ist aber das Gleiche wie am Anfang beim detach und Beenden. Vielleicht hilft das ja.

Bei mir ruckeln die SD-Programme hin wieder. Das wird wesentlich besser wenn ich drop_second_field=true setze.

Gruß

Murry

kann ich so nicht bestätigen, sieht gut aus soweit.

Wo bemerkst du das ruckeln?

Quote from CKone

kann ich so nicht bestätigen, sieht gut aus soweit.

Wo bemerkst du das ruckeln?

Bei Schwenks mit vielen geraden Linien im Bild (z.B. Fenster).

Das hört sich nach Problem beim deinterlacing an.

Ich schaue selten mpeg2, wenn ich sowas aufzeichne, wird es meist nach h264 oder hevc gewandelt.

Hast recht Murry, RTLplus ruckelt hier auch.

und das skindesigner Skin zeigt bei SD in der Menubar die Auflösung nicht mehr an, 720p und 1080i wird erkannt. - möglicherweise hängt das aber auch mit dem 396er Treiber zusammen das da was angepasst werden muss.

Quote from jojo61

Probiert halt mal die Surfaces auf etwas zwischen 7 und 24 zu setzen. 24 ist der deafult und ist wohl zu hoch.

Mit surfaces 9 läuft es bei mir recht gut.

Quote from FFmpeg Programmierer

Sofern das keine Probleme bei höheren Auflösungen macht ist das Setzen des Parameters aber eine angebrachte Lösung. Das zugrunde liegende Problem kann hier vermutlich nur Nvidia selbst lösen.

Evtl. ein Punkt für eine einstellbare Option.