Beiträge von tbshl-vdr

Man kann hier http://packages.ubuntu.com/ nach Paketnamen und auch Inhalten suchen.

Zitat

Original von neptunvasja
Bei FFMEPG ist doch schon VAAPI längst eingebaut

Ich benutze hierbei auch ffmpeg (libav...) zum dekodieren. In xinelib ist aber eben das ganze drumrum, also hauptsächlich die AV-Synchronisation, demuxer usw., schon drin, da brauch ich mich erstmal nicht drum zu kümmern. VAAPI an xinelib anzupflanzen ist "relativ" einfach, jedenfalls um erstmal überhaupt ne Ausgabe zu bekommen...
Wie's mit softdevice aussieht weiss ich nicht, da hab ich noch gar nicht reingeguckt (im Gegensatz zu xinelib, daher hatte ich da auch schon sowas wie einen Plan, wie das zu machen ist ).
Aber das mit xinelib ist ja erstmal auch ein Versuch, um zu sehen was machbar ist usw., evtl. entwickelt sich das auch noch ganz anders...

Zitat

Original von fnu
D.h. man ruft nachher "xine -vo vaapi ..." auf?

So zumindest der Plan...
Funktioniert (hier mit vdr-sxfe --video=vaapi) zumindest sehr rudimentär - Bild wird ausgegeben - schon, mit nvidia-Backend. Inwieweit wichtige Dinge dann funktionieren bzw. wie die implementiert werden müssen - deinterl., OSD... - ist aber (mir) noch vollkommen unklar.

Bin ja grad dabei, vaapi in xinelib einzubauen...

Zitat

Original von fnu
M.E. muß man eine "Zwischenschicht" von VDPAU zu VAAPI nutzen, bin aber nicht dahinter gekommen wie das funktionieren könnte ...

Umgekehrt, die Zwischenschicht ist vaapi, und dafür gibts ja dann die Backends (vdpau u.a.) .

Gruss,
Thomas

Hallo,

Zitat

Original von C-3PO
dafür aber ruckeln nun Bild und Ton bei den "very-low Quality" Kanälen ganz erheblich. (mpeg2 Sender)

Wie hier schon erwähnt ist das sehr unwahrscheinlich (eigentlich unmöglich) dass das allein mit dem Patch zusammenhängt. Ich denke das war auch vorher so, und ähnliches hab ich auch schon festgestellt.
Ich hab hier in xineliboutput (demux_xvdr.c) vor einiger Zeit wegen ähnlichem was eingebaut und folgenden Kommentar dazu gemacht

static char last_wrap = 0;	// some streams have permanently a big diff A/V-PTS, or A-PTS > 0x40400000
									// (e.g. TV-Channels "TAQUILLA", "PORTADA"...)

Das betrifft zwar jetzt nicht Deinen Fall, aber falls mal jemand auf diesen Kanälen testen mag - auf dem ersten sollte ein Standbild (mit Ton!) sein, auf dem so ein durchlaufender Streifen ist. Sorry, bessere Beschreibung fällt mir grad nicht ein, aber Ton und ein bewegtes Bild muss vorhanden sein, im syslog sollte das glaube ich auch zu sehen sein wenn nicht.
Bei manchen "billig-Sendern" lag das aber noch an etwas anderem, ging glaube ich aber in die selbe Richtung (unterschieldliche video/audio-pts). Sag mal welche Sender das sind.

Der Thread hier ist ja nicht der richtige dafür, aber welcher? Wie ich das festgetsellt habe, sind die Probleme bei diesen Kanälen schon recht speziell, also Fehler, die zwar ungefähr gleiche Auswirkungen wie andere Bild/Ton-Probleme haben, aber halt die Ursachen grundsätzlich doch etwas unterschiedlich...

Gruss
Thomas

Zitat

Original von hotzenplotz5

umschalten

Und wenn das auch nicht hilft? Fenster zumachen ist keine Option.
(Ja OK, bei momentanen Temperaturen schon, aber das ignorieren wir einfach)

Hier zum Glück bisher auch nicht wirklich nötig, aber wer weiss...

Zitat

Original von wbreu
der Grundgedanke ist halt erstmal die libva hinsichtlich VDR inkl. OSD zum Laufen zu bekommen, das möglichst mit Blick auf einfache Konfiguration und absolute Stabilität verbunden mit "kein unnötiger Ballast = Fehleranfälligkeit".

Ja schon, aber um libva zu nutzen sind ja noch die Decoder notwendig, und das ist ja nicht ganz ohne, besonders bei h264. Die sind ja vorhanden - xine-lib oder z.B. ffmpeg. Auf irgendetwas sollte das schon aufbauen, entweder als lib, oder übernommener Code, oder auch erweiterte xine-lib, oder...
Und auch nicht zu vergessen Audio und AV-Synchronisation.

Zitat

Original von wbreu
Wenn ich mir die xine-lib-1.2-Entwicklung so ansehe, wird da jeden Tag an jeder Ecke gedreht und geschraubt, dass ist bei weitem nicht ideal und führt immer wieder zu Instabilitäten/Fehlern.

Die Gefahr besteht bei einerm neuen Plugin natürlich auch. Wobei ein Neuanfang natürlich den riesigen Vorteil von jetzt vorhandenen Erkenntnissen, bisher gemachten Fehlern, neuen Möglichkeiten (vaapi) usw. hat.

Zitat

Original von wbreu
Ich hoffe, man kann dich doch noch überzeugen!

Na festgelegt hab ich mich doch auch noch gar nicht. Auch erst mal sehen, was noch so für Meinungen/Vorschläge kommen. Mitmachen würde ich denke ich aber auf jeden Fall, hab ja jetzt auch schon etliches an Zeit daran verbraucht...

Wie schon erwähnt, vor nächster Woche wird hier nicht mehr allzuviel von mir kommen, wenig Zeit (so ne Art Urlaub, muss auch ab und zu sein ).

Gruss,
Thomas

Zitat

Original von wbreu
- tbshl-vdr, schreib doch mal bitte ein paar Worte was du schon gesichtet hast / angefangen hast? => eventuell kann ja aelo dann mit einsteigen....

(Wollte aelo nicht erstmal studieren )
Naja, so viel ist das auch noch nicht, und vor nächster Woche wird mangels Zeit auch nicht mehr viel passieren. Hab mich erstmal an xbmc orientiert, welches ffmpeg benutzt.
Was mir da auffiel: das hat die ffmpeg-Quellen mit drin (und einigen anderen libs). Das mag ja Vorteile haben - kein Ärger wg. untwerschiedlicher Versionen beim Benutzer z.B., aber irgendwie ist das doch nicht ganz der Sinn dessen...

Ein eigenständiges Plugin: Wirklich dafür bin ich nicht. Wird darin dann wirklich gar nix anderes genutzt, oder z.B. ffmpeg? Wenn erstmal nur für DVB mag der Aufwand geringer sein - Decoder für mpeg/h264, aber wenn dann noch Medien dazukommen sollen... Und Audio nicht zu vergessen.

Vorteil: man kann die Fehler der anderen Implementationen weglassen. Und viele neue einbauen

Gruss,
Thomas

Aah, danke Tomas!

grappi
Welche Version ist das xine-Plugin?

@all
Funktioniert das mit den Schnittmarken bei jemanden mit xine-Plugin, und wenn welche Version?

Im vdr selbst find ich davon nix, nur in streamdev, kann das wer bestätigen?
Kannst Du mal gucken - wenn source vorhanden - wo das bei Dir auftaucht?

Zitat

Original von grappi
vdr: [12653] cVideoRepacker: operating in H.264 mode

cVideoRepacker gibts doch schon ziemlich lange gar nicht mehr, welche vdr-Version ist denn das?

Zitat

Original von wbreu
inwieweit kann man dich denn mit Hardware unterstützen => Intel oder Ati/AMD?

Momentan kann ich ja erstmal mit dem VDPAU-Backend testen, oder besser, muss ich erstmal soweit kommen dass ich überhaupt ne Ausgabe testen kann
Evtl. hab ich doch ne ATI hier die h264 decodiert, bin aber nicht sicher, vielleicht weiss da wer mehr. Ist nicht eingebaut, daher keine Ausgaben, nur vom Karton, da steht RX1550 und TD128EH, HDTV-Ready, DirectX 9.0, OpenGL 2.0. Ahja, in der Anleitung steht "MPEG 1/2/4 decode and encode accerlation", könnte gehen.

Zitat

Original von wbreu
@all, wie sieht es denn jetzt mit konkreten "Ja, ich wäre dabei beim Programmieren aus" ?

Bin grade dabei, das mal in xine-lib einzubauen.

...
load_plugins: plugin /usr/lib/xine/plugins/2.0/post/xineplug_post_autocrop.so found
load_plugins: plugin /usr/lib/xine/plugins/2.0/xineplug_dmx_fli.so found
load_plugins: plugin /usr/lib/xine/plugins/2.0/xineplug_decode_yuv.so found
libva: libva version 0.31.0
Xlib:  extension "XFree86-DRI" missing on display ":0.0".
libva: va_getDriverName() returns 0
libva: Trying to open /usr/lib/dri/nvidia_drv_video.so
libva: va_openDriver() returns 0
VAAPI initialized, Vers. 0.31
VAAPI - attrib 5 (get/---) min 0 max 0 value 0x0
VAAPI - attrib 0 (get/set) min -100 max 100 value 0x0
VAAPI - attrib 1 (get/set) min -100 max 100 value 0x0
VAAPI - attrib 2 (get/set) min -100 max 100 value 0x0
VAAPI - attrib 3 (get/set) min -100 max 100 value 0x0
VAAPI - attrib 4 (get/set) min 0 max 16777215 value 0x0
audio_alsa_out : Unterstützte Modi sind 8Bit 16Bit 24Bit 32Bit Mono Stereo (4-Kanal nicht aktiviert in xine Konfiguration) (4.1-Kanal nicht aktiviert in xine Konfiguration) (5-Kanal nicht aktiviert in xine Konfiguration) 5.1-Kanal (a/52 und DTS pass-through nicht aktiviert in xine Konfiguration)
Available video drivers: vdpau vaapi xv raw opengl xshm caca aa xxmc none sdl fb xvmc
...

Mehr als die lib zu initialisieren ist aber noch nicht, das kann auch noch etwas dauern...

Gruss,
Thomas

Zitat

Original von wbreu
an Medienwiedergabe wollen wir jetzt mal noch nicht denken.

Das kann der Mplayer bereits mit der libva und das sehr gut.

Was mir dabei aber nicht gefällt ist, dass dann nicht mehr über das OSD des VDR gesteuert werden kann.

Zitat

Original von wbreu
Sicher wäre die xine-lib eine Alternative, aber die Frage ist halt brauchen wir das alles dann im/am VDR?

Eigentlich ja, das meiste schon...
Wenn man mal Medienwiedergabe aussen vor lässt entfallen die ganzen decoder für die diversen Formate, aber das soll ja dann auch mal gehen...

Zitat

Original von wbreu
Du weißt ja sicher selbst, wieviel altes Zeugs da drinnen steckt und die Sache unnötig verkompliziert.

Nicht nur altes - man weiss gar nicht genau, welche Parameter in der config mit welchem Patch überhaupt Wirkung haben.

Zitat

Original von wbreu
Ein schmales unkompliziertes Plugin wäre für den Anfang eine super Sache mit enormem Zukunftspotential.

Ja, aber ganz so einfach wirds nicht werden.
So ganz nur als Plugin sicher eher nicht, der Unterbau sollte schon wie xine-lib vorhanden sein (oder verbesserte xine-lib, vielleicht auch neu auf Grundlage von xine-lib).
Es wäre dann aber auch die - keine Ahnung wie vielte - neue Erfindung eines (nicht ganz rund laufendes) Rades...

Gruss,
Thomas

Zitat

Original von Darkstar
Hilft leider nichts... Was müsste ich denn einstellen, damit bei JEDEM Kanalwechsel das ungezoomte Verhältnis eingestellt wird?

Also wie schon geschrieben weiss ich nicht mehr, ob das alle Änderungen im source waren die dafür nötig sind. Ist ja auch schon etwas älter - meine benutzte xineliboutput-Version auch - welche benutzt Du?
Die relevanten Plugin-Einstellungen sind
'Schneide letterbox...' -> 'ja'
und
'Letterbox automatisch erkennen' -> 'nein'.

Zitat

Original von tecfreak
Wenn schon ein neues/weiteres Ausgabe-Plugin entstehen soll, wäre es dann nicht viel sinnvoller beide Techniken damit abzudecken, also sowohl VAAPI als auch VDPAU?

'Beide Techniken' ist ja eigentlich nicht ganz richtig, VAAPI steht ja für 'Video Acceleration API', also irgendwie dasselbe wie 'Video Decode and Presentation API for Unix', beides APIs, die HW-Beschleunigung nutzen. VDPAU gibts eben nur für Nvidia (und S3), während es für VAAPI auch ein VDPAU-Backend gibt.
Also sollte wohl ein Plugin für VAAPI beides abdecken.
Meine erste Idee war ja, xine-lib um VAAPI zu erweitern, denn alles in einem Plugin (oder auch mit zusätzlicher lib, aber eben neu) ist doch etlicher Aufwand - rein zur vdr-stream-Wiedergabe evtl. nicht so hoch, aber es sollen ja auch Medien (Dateien, DVD...) wiedergegeben werden.

Zitat

Original von wbreu
Aber das Plugin sollte die Geschichte eben auch vereinfachen, wenn ich mir ansehe, was man sich für einen Aufwand auf der Konsole antun muß, um xineliboutput/vdr-xine-plugin die passende Soundausgabe beizubringen, könnte man mit einem Plugin übers OSD die paar Paramter setzen.

Ja, die ganze Konfiguration sollte auf jeden Fall mal besser gelöst werden.

Gruss,
Thomas

PS:
Oje, etwas lang zum schreiben gebraucht, schon viele neue Beiträge da, die u.a. auch auf VDPAU ist in VAAPI drin hinweisen...

Die Meldung lautet sicher "no free receiver slot", dazu findet sich hier auch was:
No free receiver slot - Problem ab 20 Clients mit streamdev-server

100613 für die xine-lib-Version vor dem 13., 100614 für die Version vom 13. (918cd2288e97).

Mit beiden geht Rewind mit Aufnahmen ohne Bildfehler (sollte, hier tuts ).

Bildfehler gibts noch, wenn mit Zeitangabe (rot) gesprungen wird.

Zitat

Original von Taipan
Aber ich glaube das nennt sich 'aktueller Entwicklungsstand', oder?...

Ja
Mit den Aufnahmen, da bin ich grad dran, u.a. dass Rewind dann auch ohne Bildfehler geht.
Dass es nach Sprüngen ruckelt ist aber seltsam (wobei sich manches ja bei einigen anders verhält, was ich hier nicht nachvollziehen kann). War das ohne Patch nicht bzw. kannst Du das ohne testen?

@C-3PO
Bei HD+, also dem verschlüsseltem Zeugs? Kann ich leider nicht testen.

Hier dann der angepasste.
Schneller Vor-/Rücklauf in Aufnahmen scheint sich verschlechtert zu haben, es läuft erst, nach einigen Sekunden muss ich vdr-sxfe aber killen. Noch keine Ahnung warum...
Springen geht aber.