Posts by mac_7

    ist ja schon eine weile her aber
    bei mir war es eben das falsche epg.data file
    ich habe es in /home/video/epg.data dachte ich
    nur dummerweise nutzte der vdr das file in
    /var/cache/vdr/epg.data

    der packet maintainer der mandriva vdr version Anssi Hannula hat das problem für mich sehr schnell gelöst
    der fehler liegt in einer alter patch version der aktuellen ct'vdr version
    debian/patches/opt-27_subtitles-ttxtsubs.dpatch


    The patch is an old version, which contains a bug in line 709
    (PES_EXTENSION insertion).


    It should be replaced with an updated fixed patch from here:
    http://www.saunalahti.fi/~rahr…nd-ttxtsubs-0.0.5.diff.gz


    @@ -1717,12 +1736,22 @@
    case 7:
    if (!done && (mpeg == 2 || mpeg1_required > 7)) {
    flag2 = Buf[c++];
    + if (dataIdentifier) {
    + if (flag2 & PES_EXTENSION) {
    + esyslog("Error: cannot add extension to pes packet. Disabling.");
    + dataIdentifier = 0;
    + }
    + else
    + flag2 |= PES_EXTENSION;
    + }
    found++;
    }
    break;

    meine streamdev/softdevice basierten clients spielen neuere aufnahmen nur ohne bild
    das ganze kann ja nur am file-format oder softdevice liegen
    altere aufnahmen oder das live bild sind aber kein problem
    einen fehler kann ich dem log auch nicht entnehmen
    bei den vdr's handelt es sich durchweg um 1.4.7
    server wäre ct'debian hier geht alles
    clients wären vdr-1.4.7-8mdv2008.1 Mandriva hier GING alles
    NUR BEI NEUEREN AUFNAHMEN GIBT ES KEIN BILD !
    vermutlich seit ich hier von 1.4.5 auf 1.4.7 upgraded habe
    hat jemand eine idee

    was verändert ?
    MinEventTimeout
    MinUserInactivity

    zappen lokal oder streamdev usw
    bzw kann man sie extern z.b. über SVDRP auslesen/setzen ?


    ok bin schon schlauer
    kann man MinUserInactivity zurücksetzen ohne die fernbedinung?
    ich will z.b. nicht das der vdr ausgeht wenn z.b. nur streamdev genutzt wird
    streamdev events setzen ihn aber bei mir nicht zurück!
    gibt es denn dafür keinen patch ?
    das muss doch auch anderen so gehen ?

    Quote

    Original von Morone
    Ich habe ne ATI X1600 Pro und das Bild ist ner FF ebenbuertig.
    Allerdings hier nur unter Windows.


    ..unter Linux bin ich froh , dass wenigstens 2D (allerdings ohne dri)
    funzt ;)
    Aber ohne dri kein xv :(


    es gibt auch xv ohne dri :)

    root@vdr2:~# dpkg -l ffmpeg
    Gewünscht=Unbekannt/Installieren/R=Entfernen/P=Säubern/Halten
    | Status=Nicht/Installiert/Config/U=Entpackt/Fehlgeschl. Konf./Halb install.
    |/ Fehler?=(kein)/Halten/R=Neuinst notw/X=beide (Status, Fehler: GROSS=schlecht)
    ||/ Name Version Beschreibung
    +++-================================-================================-================================================================================
    ii ffmpeg 20060430-0.0 audio/video encoder, streaming server & audio/video file converter
    root@vdr2:~# ffmpeg
    FFmpeg version CVS, Copyright (c) 2000-2004 Fabrice Bellard
    configuration: --prefix=/usr --libdir=${prefix}/lib --incdir=${prefix}/include/ffmpeg --enable-shared --enable-mp3lame --enable-gpl --enable-faad --mandir=${prefix}/share/man --enable-vorbis --enable-pthreads --enable-faac --enable-xvid --enable-dts --enable-amr_nb --enable-amr_wb --enable-pp --enable-libogg --enable-a52 --enable-theora --enable-libgsm --enable-x264 --enable-a52bin
    libavutil version: 49.0.0
    libavcodec version: 51.9.0
    libavformat version: 50.4.0
    built on Apr 30 2006 12:53:40, gcc: 4.0.4 20060422 (prerelease) (Debian 4.0.3-2)
    root@vdr2:~#

    Beispiele:
    2 Pass:
    ffmpeg -f mpeg -y -i 001.vdr -vcodec h264 -pass 1 -me full -refs 3 -subq 5 -b 700 -rc_max_rate 768 -rc_buffer_size 244 -s 320x240 -r 25 -ac 1 -max_b_frames 0 -level 13 -f h264 /dev/null && ffmpeg -f mpeg -y -i 001.vdr -vcodec h264 -pass 2 -me full -refs 3 -subq 5 -b 700 -rc_max_rate 768 -rc_buffer_size 244 -s 320x240 -r 25 -ac 1 -max_b_frames 0 -level 13 -acodec aac -ar 48000 -ab 160 -ac 2 Oliver.mp4


    Good Single:
    ffmpeg -f mpeg -i 001.vdr -v 1 -vcodec h264 -crf 19 -refs 5 -loop 1 -deblockalpha 0 -deblockbeta 0 -parti4x4 1 -partp8x8 1 -partb8x8 1 -me umh -subq 6 -brdo 1 -me_range 21 -chroma 1 -threads 2 -slice 2 -bf 1 -bframebias 1 -b_strategy 1 -g 250 -keyint_min 25 -sc_threshold 40 -rc_eq 'blurCplx^(1-qComp)' -qcomp 0.60 -qmin 7 -qmax 35 -max_qdiff 4 -i_quant_factor 0.71428572 -b_quant_factor 0.76923078 -rc_max_rate 0 -rc_buffer_size 0 -aspect 4:3 -s 320x240 -r 25 -acodec aac -ab 96 -ar 48000 -ac 2 OUTPUTFILE1.mp4


    # The most important ones for iPod compatibility are
    # "-max_b_frames 0 -level 13 -rc_max_rate 768".
    # The most important one for high quality is "-loop 1" which
    # (contrary to the ffmpeg man page) activates the in-loop deblocker.
    # Most of the rest I cribbed from
    # http://lists.mplayerhq.hu/pipe…el/2006-March/008997.html

    mein IPod video hat Firmware 1.2 und ist Modell MA146FD
    laut gtkpod ist er damit fifth generation; wo genau die unterschiede der halbjährigen updates auf die sixth generation (xA446) liegen weiß ich nicht
    meiner mag aber anscheinend nur MP4/AVC(H.264) bis 768kb/s
    (H.264 video, up to 768 Kbps, 320 by 240 pixels, 30 frames per sec., Baseline Profile up to Level 1.3 ohne b-frames blablabla)
    vorbei die guten alten MPEG-2 Zeiten wo man noch wußte was drin ist
    MPEG-4 "standard profile" spielt er auch mit 640x480 und höherer bitrate
    mich würde mal interessieren wie sich die verschiedenen MP4-codecs auf den accu auswirken?

    ok das ganze ist auch nicht ganz einfach zu debuggen
    du scheinst ja aber auf dem richtigen weg zu sein
    ich habe den thread mal überflogen aber adhoc keine antwort
    dri brauchst du nicht
    softdevice geht aber nicht richtig?
    weitere mögliche probleme sind bei mir immer mal wieder
    die libs von denen softdevice abhängt
    /libavformats*/
    /libffmpeg*/
    schon mal den vdr von der console gestartet und die meldungen gecheckt?
    das beispiel musst du natürlich anpassen:
    vdr -u vdr -v /misc/vdr2/video -c /etc/vdr -L /usr/lib/vdr -E /misc/vdr2/video/epg.data -P "softdevice -vo xv:" -s 'killall vdr' -Pstreamdev-client -Psky -Ptext2skin -Pamarok -Pfilebrowser -Pnordlichtsepg -Pyaepg -Pskinsoppalusikka\ --logodir='/usr/share/vdr/chanlogos'


    sonst würde ich chat oder skype empfehlen und du schreibst dann eine zusammenfassung


    btw mein softdevice stellt meinen recht guten fernseher in den schatten
    das bild ist TOP !

    kleiner auszug aus meinem betagten 8.28


    MOBILITY RADEON X1300 (M52 714B), MOBILITY RADEON X1300 (M52 714C),
    RADEON X1600 Series (RV515 7140), RADEON X1300 Series (RV515 7142),
    MOBILITY FireGL (M54 GL 7144), MOBILITY RADEON X1400 (M54 7145),
    RADEON X1300 Series (RV515 7146), MOBILITY RADEON X1300 (M52 7149),
    MOBILITY RADEON X1300 (M52 714A), RADEON X1300 Series (RV515 714D),
    RADEON X1300 Series (RV515 714E), FireGL V3300 (RV515 7152),
    RADEON X1300 Series (RV515 715E), RADEON X1300 (RV516 7180),
    RADEON X1600 Series (RV516 7181), RADEON X1300 (RV516 7183),
    MOBILITY RADEON X1450 (M64P 7186), RADEON X1300 (RV516 7187),


    sollte also schon mal gehen !
    was sagt denn der kernel wenn du fglrx lädst

    welche distribution, kde, fglrx, ati-karte


    warum? z.b.


    neuere kde >= 7.1 brauchen neuere video-treiber
    zu neues fglrx z.b. 8.31.5 läuft nicht mehr mit ati-chips < 9600


    ich nutzte hier mein laptop dann und wann zum fernsehen
    Pentium M1.5G&11g
    das ganze ist mit fglrx & softdevice sehr gut
    aber auch mit dem radeon treiber sehe ich keine grossen unterschiede mehr
    (last&qualität)

    mach ruhig
    ich hab aus faulheit nicht weiter gesucht
    auch weil ich keine so grossen unterschiede feststellen konnte
    es ging mir auch in erster linie um vdr2ipod
    finde aber ffmpeg auch für andere converts sehr gut und schnell !

    der server läuft einwandfrei
    syslog:
    Jun 2 21:43:27 vdr2 vdr: [8201] Streamdev: Accepted new client (VTP) 192.168.34.9:41308
    Jun 2 21:43:31 vdr2 vdr: [8201] ERROR: streamdev: write to client (VTP) 192.168.34.9:41308 failed: Die Verbindung wurde vom Kommunikationspartner zurückgesetzt
    Jun 2 21:43:31 vdr2 vdr: [8201] streamdev: closing streamdev connection to 192.168.34.9:41308
    Jun 2 21:43:31 vdr2 vdr: [8201] Streamdev: Accepted new client (VTP) 192.168.34.9:41309
    Jun 2 21:43:31 vdr2 vdr: [8201] client (VTP) 192.168.34.9:41309 has closed connection
    Jun 2 21:43:31 vdr2 vdr: [8201] streamdev: closing streamdev connection to 192.168.34.9:41309
    usw.......

    noad ist zwar fein und wird auch von mir gern genutzt
    trotzdem ist es nicht obsolete da auch der manuellen schnittfunktion dieses "fast-cut" gut zu gesicht stehen würde.
    da ja nun mal einige sender nicht noad-algo-konform ausstrahlen ;)
    ich würde mich also freuen wenn Klaus Schmidinger ihn fest einbaut!