Beiträge von beta

    Mit "scalermode an" ist die Performance bei mir deutlich schlechter. Meine Mikro-Ruckler werden allerdings deutlich weniger bei 1920x1080p60 statt p50.
    Mit Rellas De-Interlace branch ist das schon richtig brauchbar!


    Edit: Mit dem de-interlace branch fängt das Bild allerdings nach einiger Zeit stark an zu ruckeln. Dann hilft nur ein Neustart. Ob das das Kernel-Problem ist?


    LG,
    beta

    Hallo von fritz,


    hast Du eigentlich verlorene und übersprungene Frames im Softhddevice?
    Kommt bei mir immer, egal ob ffmeg 1.08, 2 oder libav, unabhängig, ob ich mit streamdev oder direkt schaue.


    Je mehr Speicher ich für die GPU im Kernel reserviere (ve_size), desto geringer ist die CPU-Last. Im De-Interlace branch von rella habe ich bei SD nur die halbe Last (38% Xorg statt 79%). Mehr als 190 * 1MB kann ich nicht reservieren, dann lädt das Modul nicht. Als Kernel nutze ich dan-and 104 mir allen Pasches (WLAN, BT AP6210).


    Ich habe keine Ahnung, wie ich den dropped frames Herr werden kann, die sind nämlich als Mikro-Ruckler deutlich zu sehen.


    LG,
    beta

    Hallo,


    bei mir gibt es noch folgendes Problem. VDR-Start:
    [VDPAU SUNXI] VE version 0x1623 opened.
    [VDPAU SUNXI] Deinterlacer enabled.
    codec: buggy libav, use ffmpeg
    [VDPAU SUNXI] Requested unimplemented picture_structure



    syslog ist voll mit:
    Oct 1 19:31:32 linaro-ubuntu-desktop vdr: video: speed up video, droping frameOct 1 19:31:32 linaro-ubuntu-desktop vdr: video/vdpau: missed frame (33/44)
    Oct 1 19:31:33 linaro-ubuntu-desktop vdr: video/vdpau: missed frame (37/52)Oct 1 19:31:33 linaro-ubuntu-desktop vdr: video: speed up video, droping frame
    Oct 1 19:31:33 linaro-ubuntu-desktop vdr: video/vdpau: missed frame (38/56)Oct 1 19:31:33 linaro-ubuntu-desktop vdr: video/vdpau: missed frame (44/66)


    Softhddevice ist gepatcht. Ob das nur an libav liegt?


    Gruß,
    beta

    Version 2 läuft besser bei mir. Mit T3 im live TV laufen Bild und Ton auseinander, bis Bild ganz verschwindet..


    LG,
    Beta


    -Analog Audio: -A alsa (funktioniert bei mir)
    - Umschalten sollte eigentlich gehen
    - Im Server-VDR-Xineliboutbut-Setup im Menü Video muß deinterl. abgeschaltet sein ... noch

    -A alsa funktioniert. Das war mein Fehler. Ich hatte alsa falsch konfiguriert. Beim Umschalten (egal ob vdr-Konsole oder andere) kommt beim vdr-fbfe-Aufruf:



    assertion failure:ilclient.c:996:ilclient_disable_port_buffers():error == OMX_ErrorNone
    Abgebrochen


    Edit: Obere Fehlermeldung kommt unter X, ohne X kann ich einmal umschalten, bis der RPI hängt (Reboot nur durch Netzstecker ziehen)-


    LG,
    beta

    Hallo Ardi,


    zunächst einmal herzlichen Dank für Deine Mühe. Meine Testergebnisse:


    - Läuft hervorragend mit xineliboutput
    - Darstellung ist 4:3 auf 16:9 Monitor
    - Beim Umschalten (svdrpsend CHAN xxx) stoppt Wiedergabe
    - Kein Analog-Audio. HDMI habe ich nicht testen können
    - Kein OSD (aber das sagtest Du ja schon)
    - Kein Deinterlacing


    Wenn ich Dir beim Programmieren helfen kann, mache ich das gerne. Bis hierher klasse Arbeit! Danke.


    Gruß,
    beta

    Hallo Johns,


    libdce wäre sicherlich nicht schlecht und würde Omap3 und Omap4 abedecken. Aus Geschwindigkeitsgründen ist es sicherlich angeraten, armhf zu nehmen, also z.B. Ubuntu 12.04. Da läuft aber out of the box kein omapfb mehr. Nimmt man libdce, schließt man aber wieder z.B. Broadcom aus. Ich würde gerne mithelfen. Hast Du einen Vorschlag, wo wir anfangen können, z.B. bellagio? Oder einen Wrapper für libdce<->vdpau?


    Gruß,
    beta

    Hallo,


    Ich nutze xine-lib 1.2 mit vdpau und vdr 1.7.12. Beim Anschauen einer DVD habe ich folgendres Problem: xine selbst arbeitet im fullscreen modus (1920x1080@50Hz) und das Video der DVD wird auch korrekt angezeigt. Die Steuerung der Menüs jedoch klebt am linken Rand (720x576) und wird nicht "mitgezoomed". Ist das Problem bekannt? Wenn xine auch nur mit 720x576 arbeitet, sieht alles normal aus....


    Gruß,
    beta

    schorsch, Maniac: Nur eine Idee: Könnte man den DTS Stream nicht ähnlich wie bei einer Full featured in einen PCM Stream packen, so in der Art:


    void cAudioEncapsulatorDTS::StartIECFrame(const uchar *buf, int length, uchar PTSflags, const uchar *PTSdata)
    {
    if (firstBurst) {
    SendIECpause(1);
    if (++firstBurst > 10) firstBurst = 0;
    }
    else {
    uchar ac5_type = ((buf[4] & 0x01) << 6) | ((buf[5] >>2) & 0x3F);
    uchar ac5_spdif_type;
    switch(ac5_type) {
    case 0x0F:
    ac5_spdif_type = 0x0B; /* DTS */
    break;
    case 0x1F:
    ac5_spdif_type = 0x0C; /* DTS */
    break;
    case 0x3F:
    ac5_spdif_type = 0x0D; /* DTS */
    break;
    default:
    ac5_spdif_type = 0x00; /* DTS */
    esyslog("DTS: SPDIF type not detected: ac5 type = %X!\n", ac5_type);
    break;
    }


    if (length > DTS_SIZE-IEC_HDR_SIZE) {
    DEBUG("DTS: length too long %d\n",length);
    return;
    }

    StartFrame(DTS_SIZE,PTSflags,PTSdata);
    fillup = DTS_SIZE-IEC_HDR_SIZE-length;


    // prepare IEC 60958 data frame
    uchar burst[IEC_HDR_SIZE];
    burst[0] = 0xF8;
    burst[1] = 0x72;
    burst[2] = 0x4E;
    burst[3] = 0x1F;
    burst[4] = 0x00;
    burst[5] = ac5_spdif_type; /* DTS data */
    burst[6] = ((length * 8) >> 8 ) & 0xFF; /* ac5_length * 8 */
    burst[7] = (length * 8) & 0xFF;
    PutData(burst,sizeof(burst));
    }
    }


    und den Rest dem Receiver überlassen?


    Gruß,
    beta