You are not logged in.

Dear visitor, welcome to VDR Portal. If this is your first visit here, please read the Help. It explains in detail how this page works. To use all features of this page, you should consider registering. Please use the registration form, to register here or read more information about the registration process. If you are already registered, please login here.

1,761

Monday, January 23rd 2012, 8:32pm

Die Einträge zu ffmpeg haben mich auch gewundert. Am default-Wert "engine.buffers.video_num_frames:22" musste ich noch nie was ändern. Eine Erhöhung macht auf meinem Equipment keinen erkennbaren Unterschied aus.

Gruß
iNOB

Mein VDR

Hartware: Gehäuse: Ahanix MCE 302, Mobo: Kontron 986LCD-M/mITX, CPU: Intel Core2 Duo Mobile T7400 2,16GHz, 2GB RAM, SAT: Digital Devices DuoFlex S2 miniPCIe, Graka: ASUS EN210 Silent 1GD3, 4x2TB 3,5" WD HD, 1x DVD-Brenner Pioneer, Atric IR-Einschalter+Empfänger, FB One-For-All URC-7960, SoundGraph iMON LCD ( MFP5I, 15c2:0038 )
Weichware: Wheezy (x86_64), Kernel 3.8.13, NVidia v340.17, VDR 2.1.6 gepatched

1,762

Monday, January 23rd 2012, 10:29pm

Die Einträge zu ffmpeg haben mich auch gewundert. Am default-Wert "engine.buffers.video_num_frames:22" musste ich noch nie was ändern. Eine Erhöhung macht auf meinem Equipment keinen erkennbaren Unterschied aus.

Gruß
iNOB

Vermutlich bewirkt das hochsetzen von video_num_frames nur etwas auf schwachen Systemen.
Der Buffer dient ja unter anderem dazu dass der decoder thread und der video ausgabe thread unabhängiger laufen können.
Server: Asus M3N-H/HDMI, AMD X2 5600+, 4GB RAM, 500GB+1,5TB Samsung HD, 2xTevii S470, 1xTT-S3200, Ubuntu/V12.04, vdr 1.7.27
Client1: ZOTAC ION-ITX B, 2GB RAM, Diskless/Netboot per PXE, Xubuntu/V12.04, vdr 1.7.27+softhddevice, XBMC V12.1, LG42LC2R LCD-TV
Client2: Wie 1 aber ZOTAC ION-ITX E , DFAtmo, 2xDF10CH 19 Kanal Atmolight, LG37LC2R LCD-TV


1,763

Monday, January 23rd 2012, 10:36pm

Bezüglich der ffmpeg Parameter bleibt noch anzumerken, das diese durchaus wieder relevant werden könnten wenn Videos z.b. über die Datei
Wiedergabefunktion des xineliboutput abgespielt werden und diese nicht in einem Format vorliegen für das es ein vdpau decoder profile gibt.
In diesem Fall würde aber die vdpau Ausgabe trotzdem genutzt. Nur der vdpau decoder halt nicht.
Server: Asus M3N-H/HDMI, AMD X2 5600+, 4GB RAM, 500GB+1,5TB Samsung HD, 2xTevii S470, 1xTT-S3200, Ubuntu/V12.04, vdr 1.7.27
Client1: ZOTAC ION-ITX B, 2GB RAM, Diskless/Netboot per PXE, Xubuntu/V12.04, vdr 1.7.27+softhddevice, XBMC V12.1, LG42LC2R LCD-TV
Client2: Wie 1 aber ZOTAC ION-ITX E , DFAtmo, 2xDF10CH 19 Kanal Atmolight, LG37LC2R LCD-TV


1,764

Monday, January 23rd 2012, 11:14pm

Vermutlich bewirkt das hochsetzen von video_num_frames nur etwas auf schwachen Systemen.
Der Buffer dient ja unter anderem dazu dass der decoder thread und der video ausgabe thread unabhängiger laufen können.

Kann ich bestätigen.
Auf meinem alten System mit Pentium III und Geforce 8400GS war video_num_frames 30 deutlich besser.

Mein VDR

Asrock M3A770DE, Sempron 140 @ DualCore, 3 x TT S2-1600, GT520
openSuse 13.1 64bit, Kernel 3.14.13 + BER/UNC-Patch für stv090x, nvidia 340.24, vdr 2.1.6 mit Patchen (checkts, naludump, statusleds, ...)

1,765

Tuesday, January 24th 2012, 5:51pm

Die Einstellungen für tvtime kommen aus dem Setup von xineliboutput. Wenn ich hier auf bei Deinterlacing auf "Aus" oder "Bob" stelle scheint das auch auf vdpau zuzutreffen, zumindest steht im Log dann Deinterlacer: None.

Ich habe es dann wieder auf tvtime gestellt, aber die xineplug_post_tvtime.so aus dem xine-Plugin-verzeichnis geschmissen. Im Log wieder Deinterlacer: None.

Jetzt stellt sich mir aber die Frage was hat tvtime hier mit dem Deinterlacing zu tun? Das Deinterlacing sollte doch komplett über vdpau gemacht werden. Würde hier eventuell eine vdpau-Option sinn machen die ohne den Umweg über tvtime läuft? Falls ja würde ich mir den Code da mal genauer ansehen und gucken das ich so eine Option eingebaut bekomme.

1,766

Wednesday, January 25th 2012, 12:01am

Es geht scheinbar immer über die tvtime api.

Source code

1
 --post=tvtime:method=use_vo_driver,enable=1,pulldown=0,framerate_mode=full,judder_correction=0,use_progressive_frame_flag=1,chroma_filter=1,cheap_mode=0


verwende ich als Befehlzeile von vdr-sxfe, geht aber auch in xine_config bzw. config_xineliboutput einzustellen oder war es in setup.conf?

Johns
Sag mir, wo die Developer sind. Wo sind sie geblieben? . . . . . . . . . . . . . . . . . . . . SoftHdDevice - A software and GPU emulated HD output device plugin.
Sag mir, wo die Developer sind. Was ist geschehn?

Client0: Crown CW02 MSI_C847MS-E33 Zotac_GT640_passiv Cine-S2 iMon-MCE / streamdev softhddevice
Client1: Lian_Li_PC-Q09FB ASRock_H67M-ITX/HT I3-2100 ASUS_ENGT520_passiv / streamdev softhddevice
Test: Lian_Li_PC-Q09R Asus C60M1-I / streamdev
Server0: Dockstar TT-S2-3600-USB / streamdev
Server2: Lian_Li_PC-Q07R Intel_DH61DL G620 WD20EARX 90W PicoPSU Cine-S2+DuoFlex-S2+DuoFlex-CT / streamdev / 22 Watt Verbrauch

1,767

Wednesday, January 25th 2012, 6:47pm

Ok, bin überzeugt das es notwendig ist und wie es ungefähr zusammenspielt.

Das Deinterlacer-Handling ansich findet in der video_out_vdpau der xine-lib statt. tvtime wird, wie johns geschrieben hat, unter anderem der Parameter method=use_vo_driver übergeben. Dadurch wird in der video_out_vdpau überhaupt erst das Deinterlacing aktiviert.

1,768

Wednesday, January 25th 2012, 10:34pm

@durchflieger: Der Fehler lässt sich bei mir auf einfache Art und Weise mit "xrandr -r" reproduzieren. Einfach ein paar mal die refreshrate umschlaten, z.B. zwischen 24 und 50. Nach 2-3 mal kommt dann nur noch folgendes:

Source code

1
2
vdpau_h264_alter : failed to create decoder !! The system does not have enough resources to complete the requested operation at this time.
vdpau_h264_alter : failed to create decoder !! The system does not have enough resources to complete the requested operation at this time.


Falls du Logs oder Tests brauchst sag einfach Bescheid.

1,769

Thursday, January 26th 2012, 9:44am

Ich habe noch ein bischen weiter geforscht. Der pre-emption callback der Auftritt ist normal sobald sich die Modeline ändert und vdpau initialisiert ist. Es wird dann automatisch ein reinit von vdpau durch die xine-lib durchgeführt.

@durchflieger: Solten bei einem reinit dann nicht auch die output surfaces zerstört und neu erstellt werden? Das müste dann auch die Probleme mit xrandr beheben.

1,770

Saturday, January 28th 2012, 9:07am

Source code

1
Könntest du das bitte mal mit aktivierten #define LOG im videou_out_vdpau.c testen und den xine log hier zeigen.


http://paste.ubuntu.com/819732/


wie gesagt, passiert nur mit dem xine-plugin.
und gerne bei "history hd" schon nach ca. einer halben stunde.
bei anderen sendern dauert es länger bis es zu dem "zittern" kommt.
kann aber auch zufall sein.

1,771

Saturday, January 28th 2012, 11:15am

Ich habe noch ein bischen weiter geforscht. Der pre-emption callback der Auftritt ist normal sobald sich die Modeline ändert und vdpau initialisiert ist. Es wird dann automatisch ein reinit von vdpau durch die xine-lib durchgeführt.

@durchflieger: Solten bei einem reinit dann nicht auch die output surfaces zerstört und neu erstellt werden? Das müste dann auch die Probleme mit xrandr beheben.

Das werden sie auch. Dein Fehler zeigt ja auch das er das decoder objekt nicht wieder allokiert bekommt. Ich denke das Problem hier hat nichts mit dem osd handling
zu tun und tritt vermutlich auch mit dem alten osd handling auf.
Erstmal nicht meine Baustelle.
Server: Asus M3N-H/HDMI, AMD X2 5600+, 4GB RAM, 500GB+1,5TB Samsung HD, 2xTevii S470, 1xTT-S3200, Ubuntu/V12.04, vdr 1.7.27
Client1: ZOTAC ION-ITX B, 2GB RAM, Diskless/Netboot per PXE, Xubuntu/V12.04, vdr 1.7.27+softhddevice, XBMC V12.1, LG42LC2R LCD-TV
Client2: Wie 1 aber ZOTAC ION-ITX E , DFAtmo, 2xDF10CH 19 Kanal Atmolight, LG37LC2R LCD-TV


1,772

Saturday, January 28th 2012, 11:59pm

Source code

1
Könntest du das bitte mal mit aktivierten #define LOG im videou_out_vdpau.c testen und den xine log hier zeigen.


http://paste.ubuntu.com/819732/


wie gesagt, passiert nur mit dem xine-plugin.
und gerne bei "history hd" schon nach ca. einer halben stunde.
bei anderen sendern dauert es länger bis es zu dem "zittern" kommt.
kann aber auch zufall sein.

Ich denke ich habe den Fehler gefunden! Ist tatsächlich noch ein fieser Bug der nur mit dem xine plugin auftritt da dieses rgba osd objekte verwendet.
Auf vdr-developers.org enthält der df-extensions branch den fix dazu. Bitte teste dass mal aus wieder mit aktivierten #define LOG und den Log dann wieder nach
pastebin.

Gruss
durchflieger
Server: Asus M3N-H/HDMI, AMD X2 5600+, 4GB RAM, 500GB+1,5TB Samsung HD, 2xTevii S470, 1xTT-S3200, Ubuntu/V12.04, vdr 1.7.27
Client1: ZOTAC ION-ITX B, 2GB RAM, Diskless/Netboot per PXE, Xubuntu/V12.04, vdr 1.7.27+softhddevice, XBMC V12.1, LG42LC2R LCD-TV
Client2: Wie 1 aber ZOTAC ION-ITX E , DFAtmo, 2xDF10CH 19 Kanal Atmolight, LG37LC2R LCD-TV


1,773

Sunday, January 29th 2012, 3:22pm

Quoted


Ich denke ich habe den Fehler gefunden!


sieht super aus bisher !
läuft aber auch erst ne halbe stunde.
natürlich hab ich #define LOG aktivieren vergessen.

ich liefer dir das aber noch nach.

1,774

Sunday, January 29th 2012, 7:23pm

df-extensions Branch mit überarbeiteter grab-Funktion fürs vdr xine plugin

Hallo,

auf vdr-developer.org habe ich den df-extensions Branch auf den Stand des aktuellen master hochgezogen.
Achtung Debian/Ubuntu Nutzer: Im master wurde das Packet libxine-dev in libxine2-dev umbenannt!

Ausserdem habe ich die Grab-Funktion für das vdr xine plugin nochmals überarbeitet.
Das vdr xine plugin muss nun mit dem Patch xine-plugin-0.9.4-grab.patch anstatt dem alten
xine-plugin-0.9.3-vdpau-extensions-v13.2.diff.gz gepatched werden!!!
Der alte Patch ist inkompatibel zu dem aktuellen df-extensions Stand.

Funktional hat sich nichts an der Grab-Funktion für das xine plugin geändert. Allerdings ist die Änderung
an der xine-lib jetzt rückwärtskompatibel und läuft auch mit einem ungepatchtem vdr xine plugin.
Damit ist der Weg frei den Patch ins xine-lib hg zu übergeben :)

Gruss
durchflieger
Server: Asus M3N-H/HDMI, AMD X2 5600+, 4GB RAM, 500GB+1,5TB Samsung HD, 2xTevii S470, 1xTT-S3200, Ubuntu/V12.04, vdr 1.7.27
Client1: ZOTAC ION-ITX B, 2GB RAM, Diskless/Netboot per PXE, Xubuntu/V12.04, vdr 1.7.27+softhddevice, XBMC V12.1, LG42LC2R LCD-TV
Client2: Wie 1 aber ZOTAC ION-ITX E , DFAtmo, 2xDF10CH 19 Kanal Atmolight, LG37LC2R LCD-TV


1,775

Sunday, January 29th 2012, 10:30pm

Ist http://hg.debian.org gerade offline? Wollte die xine-ui auch updaten. Gibts irgendwo einen Spiegelserver?
- VDR: Thermaltake DH 102 mit 7" TouchTFT * Mystique SaTiX-S2 Dual * Debian Wheezy/vdr-2.1.5/graphtft/MainMenuHooks-Patch * Intel Petium G3220 * DH87RL * Zotac GT630 * 1 TB System HDD * 4 GB Corsair Vegance * Harmony 900 (39-44W)
- Server: Zotac H55-ITX WiFi, Core i3 540, 4GB RAM, 4x4TB 3.5" WD RED + 1x500GB 2.5", Cine S2, vdr-2.1.6
- vdr-theme-darkred: https://github.com/TheChief79/vdr-theme-darkred

1,776

Sunday, January 29th 2012, 10:36pm

Ist http://hg.debian.org gerade offline? Wollte die xine-ui auch updaten. Gibts irgendwo einen Spiegelserver?

Hallo,
hier geht's auch gerade nicht. Spiegelserver kenne ich keinen...
Gruß Michael
Gen2VDR v4 auf Asus P5B-VM mit Core2Duo E4300, Gainward G210 1024MB passiv, SATA SSD+HDD, cineS2, TT Budget T-1500, MSI Mega Sky 580 DVB-T USB-Stick, Club3D Theatron Agrippa DTS, Atric Einschalter

caps!

Intermediate

Posts: 337

Location: München

  • Send private message

1,777

Monday, January 30th 2012, 2:50pm

Ausserdem habe ich die Grab-Funktion für das vdr xine plugin nochmals überarbeitet.
Das vdr xine plugin muss nun mit dem Patch xine-plugin-0.9.4-grab.patch anstatt dem alten
xine-plugin-0.9.3-vdpau-extensions-v13.2.diff.gz gepatched werden!!!
Der alte Patch ist inkompatibel zu dem aktuellen df-extensions Stand.

Das xine-Plugin kompiliert bei mir hier leider nicht mit dem xine-plugin-0.9.4-grab.patch:

Source code

1
2
3
4
5
6
7
8
xineLib.c: In Elementfunktion »uchar* PluginXine::cXineLib::execFuncGrabImage(const char*, int&, bool, int, int, int)«:
xineLib.c:4170:7: Fehler: »data_grab_image_v2_t« wurde in diesem Gültigkeitsbereich nicht definiert
xineLib.c:4170:28: Fehler: expected »;« before »data«
xineLib.c:4171:7: Fehler: »data« wurde in diesem Gültigkeitsbereich nicht definiert
xineLib.c:4171:26: Fehler: »func_grab_image_v2« wurde in diesem Gültigkeitsbereich nicht definiert
xineLib.c:4300:20: Warnung: ignoring return value of »int asprintf(char**, const char*, ...)«, declared with attribute warn_unused_result
xineLib.c:4308:20: Warnung: ignoring return value of »int asprintf(char**, const char*, ...)«, declared with attribute warn_unused_result
make: *** [xineLib.o] Fehler 1

Hab ich was übersehen?

Grüße, caps!

Signatur

Asus N4L-VM DH, Intel Core Duo 1,6 Ghz, 2 GB Ram, Gainward G210 SILENT (1GB GDDR2) passiv, 2x Budget (Cinergy C1200, KNC One)
VDR 2.0.1, 3.2.41-gentoo, nvidia-drivers 313.30, softhddevice (git)

1,778

Monday, January 30th 2012, 3:12pm

Anscheinend, hab vor ner viertel Stunde ohne Probleme kompiliert. xine-lib aktuell mit extensions patch?
- VDR: Thermaltake DH 102 mit 7" TouchTFT * Mystique SaTiX-S2 Dual * Debian Wheezy/vdr-2.1.5/graphtft/MainMenuHooks-Patch * Intel Petium G3220 * DH87RL * Zotac GT630 * 1 TB System HDD * 4 GB Corsair Vegance * Harmony 900 (39-44W)
- Server: Zotac H55-ITX WiFi, Core i3 540, 4GB RAM, 4x4TB 3.5" WD RED + 1x500GB 2.5", Cine S2, vdr-2.1.6
- vdr-theme-darkred: https://github.com/TheChief79/vdr-theme-darkred

1,779

Monday, January 30th 2012, 3:26pm

@caps! du musst den xine-lib df-extensions branch nehmen.(vorher)
sonst wird das nix.

http://projects.vdr-developer.org/git/xi…h=df-extensions

caps!

Intermediate

Posts: 337

Location: München

  • Send private message

1,780

Monday, January 30th 2012, 3:34pm

Oh mann... hatte mir die xine-lib neu aus dem Repo geholt und das "git checkout -b df-extensions origin/df-extensions" vergessen...

Danke Euch für den Hinweis! Grüße, caps!

Signatur

Asus N4L-VM DH, Intel Core Duo 1,6 Ghz, 2 GB Ram, Gainward G210 SILENT (1GB GDDR2) passiv, 2x Budget (Cinergy C1200, KNC One)
VDR 2.0.1, 3.2.41-gentoo, nvidia-drivers 313.30, softhddevice (git)