Posts by stevie101

    jo, mag sein, wollte nur eine günstige Alternativmöglichkeit aufzeigen.

    Das mit VAAPI halt ich für ein Gerücht:


    vainfo: VA-API version: 1.15 (libva 2.15.0)

    vainfo: Driver version: Intel iHD driver for Intel(R) Gen Graphics - 22.4.4 ()

    vainfo: Supported profile and entrypoints

    VAProfileNone : VAEntrypointVideoProc

    VAProfileNone : VAEntrypointStats

    VAProfileMPEG2Simple : VAEntrypointVLD

    VAProfileMPEG2Main : VAEntrypointVLD

    VAProfileH264Main : VAEntrypointVLD

    VAProfileH264Main : VAEntrypointEncSlice

    VAProfileH264Main : VAEntrypointFEI

    VAProfileH264Main : VAEntrypointEncSliceLP

    VAProfileH264High : VAEntrypointVLD

    VAProfileH264High : VAEntrypointEncSlice

    VAProfileH264High : VAEntrypointFEI

    VAProfileH264High : VAEntrypointEncSliceLP

    VAProfileVC1Simple : VAEntrypointVLD

    VAProfileVC1Main : VAEntrypointVLD

    VAProfileVC1Advanced : VAEntrypointVLD

    VAProfileJPEGBaseline : VAEntrypointVLD

    VAProfileJPEGBaseline : VAEntrypointEncPicture

    VAProfileH264ConstrainedBaseline: VAEntrypointVLD

    VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice

    VAProfileH264ConstrainedBaseline: VAEntrypointFEI

    VAProfileH264ConstrainedBaseline: VAEntrypointEncSliceLP

    VAProfileVP8Version0_3 : VAEntrypointVLD

    VAProfileVP8Version0_3 : VAEntrypointEncSlice

    VAProfileHEVCMain : VAEntrypointVLD

    VAProfileHEVCMain : VAEntrypointEncSlice

    VAProfileHEVCMain : VAEntrypointFEI

    VAProfileHEVCMain10 : VAEntrypointVLD

    VAProfileHEVCMain10 : VAEntrypointEncSlice

    VAProfileVP9Profile0 : VAEntrypointVLD

    VAProfileVP9Profile2 : VAEntrypointVLD


    Als reine streaming Lösung, kann ich nach wie vor MPV streamdev client empfehlen. Einfaches lua script innerhalb des mpv conf Verzeichnisses und man hat die schöne alte vdr 1.04 Optik im MPV. Unter windows sollte es auch gehen, hab ich aber mangels windows noch nie probiert.

    Probiere es auch gerade aus - Du hast mit Sicherheit die recovery mit den Stick kopiert - es dürfen nur die 2 files (scr und fw) auf dem Stick sein.
    Man kommt per ssh auf die box - das satip plugin findet die box entsprechend auch.
    Umschalten kommt mir schneller vor, einige transponder fehlen bei mir, die per DVB Karte da waren.
    Alles in allem sieht das sehr gut aus.


    Portisch
    Danke fürs Teilen Deiner Untersuchungen bzgl. der Kommunikation mit dem Treiber.


    @perexg


    Thank you very much - you have given the box its purpose back.


    Gruss

    Es gibt ein openelec repo von codesnake, ich meine der s805 wird auch supported. Auf einer s802 box läuft es schon nicht schlecht, super deinterlacer im Vergleich zu imx6.

    Das hat mich auch wahnsinnig gemacht.
    Leider kann ich Dir nicht genau sagen was die Ursache ist, allerdings lag es nicht am xvdr-plugin selbst.
    Nutze openelec auf Matrix TBS und bin auf ein älteres image von 16/SEP zurückgegangen (obwohl das betroffene als auch das ältere image Gotham 13.2 enthalten).

    Bricken ist eigentlich kein Thema.
    Ihr könnt mir dem tool "imx_usb" ein selbstkompiliertes Uboot per OTG auf dem Teil ausführen wenn der Schalter auf burn modus steht.
    Ich hab die 1.3 Version, mit einem Kabel und einem Pegelwandler+RS232 FTDI kann man dann schön den Uboot unterbrechen und manuell zB. von SSD aus booten.
    Ich hatte da vor Monaten sehr viel ausprobiert, weil ich das Ding als VDR Server verwenden wollte.
    Mittlerweile hab ich openelec drauf und das Teil fungiert als client.
    Ihr könnt euch zB. den u-boot und DTB aus dem Openelec image von vpeter holen, der bootet 3.14.19 - wenn ich es richtig interpretiere ist der Kernel carry over vom Cuboxi.
    Der Originale U-boot zumindest auf der 1.3 war ziemlich mies, keine network connection und hat keine sdcard erkannt.


    Ich hab mir letztens aus China ein Amlogic S802 board mitgebracht - das Teil ist wirklich Müll, per Android geflashed und nun meldet U-boot permanent DDR init failed und looped.
    Lässt sich auch nicht per OTG reparieren - aus meiner Sicht kann das beim Matrix nicht passieren.

    rell


    Wollte gerade mal Deinen WIP branch testen doch da hakt es beim Kompilieren:




    gcc version 4.9.1 (Debian 4.9.1-12)

    Quote

    Obwohl im fexscript pll4 = 300 steht kommt in dmesg

    Source code
    1
    Mali: mali clock set completed, clock is 288000000 Hz


    Interessant, hab mal hier geschaut:


    [ 18.564041] mali: use config clk_div 3
    [ 18.567885] mali: clk_div 3
    [ 18.568897] Mali: mali clock set completed, clock is 320000000 Hz
    [ 18.577802] mali: use config clk_div 3
    [ 18.580515] mali: clk_div 3
    [ 18.591379] Mali: mali clock set completed, clock is 320000000 Hz
    [ 18.742723] Mali DRM initialize, driver name: mali_drm, version 2.1
    [ 18.754991] [drm] Initialized mali_drm 2.1.1 20101111 on minor 0
    [ 18.764495] Mali DRM initialize, driver name: mali_drm, version 2.1
    [ 18.770179] [drm] Initialized mali_drm 2.1.1 20101111 on minor 1


    script.bin hatte ich von aRuntu - installiert auf der SSD ist CTdebian jessie.

    Ich weiß echt nicht was ihr gegen Debian habt - fahre seit Jahren gut damit.
    Anyway, ich hab gestern ein bischen testen können - der entscheidende Punkt aus meiner Sicht ist nicht die Distribution sondern, ffmpeg/libav.
    Mit ffmpeg 1.2 .. 2.3 funzt HD gut, aber SD bleibt dunkel - bei libav hatte ich mit 0.8.15 Glück (9.16 blieb HD dunkel, mit der bei aRuntu ich glaub 0.8.13 ging HD in Zeitlupe).
    Dieses ganze ffmpeg / libav Gedöns ist wirklich nervig, aber wohl entscheidend.


    Auflösung: 1980x1080 @50Hz
    softhddevice git : max_refs = 9
    vdr 2.1.6
    ve_mem : 140 MB reserved
    --> Kernel 3.4.102-ct_r2+


    Damit funktioniert aktuell ServusTV mit OSD - beim Umschalten zu 720p kann es zum Absturz kommen.
    Edit: passierte ein/zwei Mal vernachlässigbar


    Bisher ganz brauchbar, gut deinterlacing auf SD wäre schön - übrigens mit cubietruck.

    Hi Uwe,


    Ja, das sticky bit.
    Xbmc ist halt deutlich träger ohne force turbo.
    bisher hab ich auch keine schlechten Erfahrungen gemacht - ich glaube den 256er hab ich seit Mitte 2012 und den Chinesen kurz danach. Beide wurden ordentlich gequält und funktionieren noch immer. Wenn man sich die Temperaturen anschaut, denke ich, sieht es auch nicht so dramatisch aus.

    Leider gleiches Resultat:


    Das Risiko ist mir bewusst, allerdings wäre der Schaden tragbar.
    Beide laufen seit ca. Januar mit 1100Mhz 24/7:


    processor : 0
    model name : ARMv6-compatible processor rev 7 (v6l)
    Features : swp half thumb fastmult vfp edsp java tls
    CPU implementer : 0x41
    CPU architecture: 7
    CPU variant : 0x0
    CPU part : 0xb76
    CPU revision : 7


    Hardware : BCM2708
    Revision : 100000e


    root@raspberrypi:~# bcmstat.sh
    Config: v0.1.6, args "", priority lowest (+19)
    Governor: powersave
    Memory: 512MB (split 384MB ARM, 128MB GPU) plus 100MB Swap
    HW Block: | ARM | Core | H264 | SDRAM |
    Min Freq: | 1100Mhz | 250Mhz | 0Mhz | 600Mhz |
    Max Freq: | 1100Mhz | 250Mhz | 250Mhz | 600Mhz |
    Voltages: | +8, 1.40V | +3, 1.28V |
    Other: temp_limit=85, force_turbo=1
    Firmware: Apr 24 2014 18:50:58, version 6b392a1ba3592998a8436f54759b8c7f1403f5ec (clean) (release)
    Codecs: H264 WVC1 MPG2 MJPG
    Booted: Sat Jun 21 08:22:25 2014


    Time ARM Core H264 Core Temp (Max) IRQ/s RX B/s TX B/s
    ======== ======= ======= ======= =============== ====== ========== ==========
    20:08:42 1099Mhz 550Mhz 550Mhz 59.45C (59.45C) 6,108 1,884,711 6,995
    20:08:44 1100Mhz 550Mhz 550Mhz 59.45C (59.45C) 5,258 1,792,714 6,501
    20:08:46 1100Mhz 550Mhz 550Mhz 58.91C (59.45C) 5,318 1,895,577 6,761
    20:08:48 1100Mhz 550Mhz 550Mhz 58.38C (59.45C) 5,366 2,030,288 6,293


    Allerdings hab ich einen Kühlkörper verbaut.


    Gruss,

    Meine beiden laufen recht stabil mit folgenden Einstellungen:


    #Overclocking
    force_turbo=1
    arm_freq=1100
    gpu_freq=550
    #isp_freq=490
    #core_freq=500
    sdram_freq=600
    over_voltage=8
    over_voltage_sdram=3


    gpu_mem_512=128


    Das geht aber nur mit UK Version und Samsung Speicher - ich habe auch ein China Teil, das Ding ist wesentlich instabiler und hatte mich letztes Jahr in den Wahnsinn getrieben.
    Den China RPI verwende ich jetzt mit einem DAC zum Musik hören (und immer noch eine Betty um MPD zu steuern).


    Wichtig ist nach meiner Erfahrung ein gute Spannungsversorgung - ruhig 2A Netzteile verwenden.
    Und alle meine 512MB Versionen laufen besser, wenn sie über einen USB Anschluss bestromt werden.
    Im Zweifelsfall kann ich Dir nur raten einen neuen zu kaufen - bei dem Preis lohnt sich der Zeitaufwand für eine Montagsversion nicht.

    ich hatte schon immer audio plops bei LiveTV auf HDMI, auch wenn der rpi nicht übertaktet ist.
    Verbesserung bringt der next-branch, könnt ja mal ausprobieren:


    wget https://raw.github.com/Hexxeh/rpi-update/master/rpi-update -O /usr/bin/rpi-update && sudo chmod +x /usr/bin/rpi-update
    BRANCH=next rpi-update


    dwc_otg.fiq_enable=1 dwc_otg.fiq_fsm_enable=1 dwc_otg.fiq_fsm_mask=0x7


    coherent_pool=6M musste bei mir aus cmdline.txt entfernt werden.


    Durch die Übertaktung läuft das menu (skinnopacity mit scraper2vdr) auch recht flüssig.


    Jetzt würde ich mir noch einen fix für das Deinterlacing Problem auf den ZDF HD Kanälen wünschen :]

    ok, sorry hier etwas mehr Info:



    Das vollständige Log ist hier:
    http://pastebin.com/1rLMZty6


    channel 5 ist Sat1 (SD), channel 1 DasErsteHD.


    Ich nahm an das hier ist der Grund für den black screen bei SD:
    localhost vdr: codec: bad video frame


    Bringt ein Log mit dem einzigen Unterschied ffmpeg 1.08 etwas ?


    Danke für Dein feedback.