Beiträge von faup

    Probier mal die Zielgröße hinten in Mbyte anzugeben


    #transcode_avi_2_h264.pl [Infile] [Targetsize/Mbyte]


    45 Minuten bei Zielsize 220 Mbyte ergeben rund 500 Kbit, als Anhaltspunkt


    Code
    easyVDR:/# ./transcode_mpg_2_h264.pl welcometrans.mpg 220


    Grüße vom Alex


    BTW : ich experimentiere gerade mit transcode 1.1.0 , die x264 Unterstützung an Board haben,
    mit angepassten Parametern und individueller Matrizze. da gibts demnächst mehr.

    ich hab mal aus "man transcode" die sektion use profile extrahiert


    Code
    ....
    --export_prof  S
    ....
    The ffmpeg export module `-y ffmpeg' does support profiles as well. The module tries to be smart 
    and sets internal ffmpeg parameters which are otherwise quite tricky to find out. Usage is similar to the above.
    
    
    transcode -i vob/ --export_prof dvd -y ffmpeg -o test -m test.ac3
    ....


    Das könnte es einfacher machen.


    PS :
    lame --> mp3
    toolame --> mp2 ( mpeg2 Tonformat )


    Grüße vom Alex

    Zitat

    Original von durchflieger
    Parametrierung für CoreAVC in der Registry, wie sie im Googgle Wiki für V1.7 beschrieben ist, auch bei V1.8 noch Gültigkeit? Ich würde gerne den deinterlacer abschalten.


    Hallo durchflieger,


    ich habe die Cheats mal mit der Version 1.8 ausprobiert, aber keine wirkliche Veränderung festgestellt, heißt, den Deinterlacer hab ich nicht abgeschaltet bekommen.


    Problemlos sollte aber auch die Version 1.7 in oben beschriebener Anleitung laufen, damit könnten die Cheats dann funktionieren.


    Grüße vom Alex

    Tach Team,


    Nach ewigen Versuchen habe ich hier nun eine funtionierende Variante des Windows Codecs CoreAVC laufen, der eine alternative zur ffmpeg decodierung von h264 darstellt.
    Gleich vorneweg, ruckelfrei ist das Ganze auch nicht, aber deutlich besser als der derzeitige ffmpg Stand.


    Der Reihe nach, folgendes System soll das Ziel sein :


    - amd 64Bit
    - vdr (hier 1.5.14 ) mit S2 h264 Fähigkeit
    - Ausgabe über vdr-xine in Xine
    - Videodekodierung via xine-lib 1.2 , dshowserver und CoreAVC 1.8


    Vorteile :
    - skalliert über mehrere CPUs ( macht ffmpeg derzeit nicht )
    - bessere Bildqualität, ruckelfreier als ffmpeg :)


    Nachteile :
    - externer Direct Show Server, Windows Closed Source Filter
    - Kostenpflichtiger Codec


    Ich betrachte das ganze als zwar funtionierend, aber nicht der Weißheit letzter Schluß.


    Die schritte im Einzelnen ( hier nur die Coreavc und dshowserver relevanten Dinge )


    1. CoreAVC besorgen, z.b: hier :
    http://www.coreavc.com/


    2. installation mittels wine


    3. Nach Installation kommt die Datei "YOUR_HOME/.wine/drive_c/Programme/CoreCodec/CoreAVC Professional Edition/CoreAVCDecoder.ax" nach "/usr/lib/win32/CoreAVCDecoder.ax"


    4. dshowserver als vorkompiliertes binary von hier herunterladen :
    http://coreavc-for-linux.googl…r-ia32-r63-gentoo.tar.bz2


    5. enthaltene binarys " dshowserver" + "registercodec" entpacken nach /usr/bin


    6. registrieren des Codecs mit :

    Code
    mkdir YOUR_HOME/.mplayer/
    export REGISTRY=$HOME/.mplayer/registry32
    registercodec -r $REGISTRY -k "HKLM\\Software\\CoreCodec\\CoreAVC Pro\\Serial" -v "55555-55555-CORE-55555-55555"


    Statt der vielen 5en kommt der 15$ teure Key rein.


    7. testen auf funtionierenden dshowserver mit :

    Code
    dshowserver -c CoreAVCDecoder.ax -s 1280x720 -g 09571a4b-f1fe-4c60-9760de6d310c7c31 -b 12 -f 0x34363248 -o 0x30323449


    sollte bringen :

    Code
    No id specified, assuming test mode
    Opening device
    Called unk_IsDebuggerPresent
    len: 992
    ProductVersion: 1.8.0
    Decoder supports the following YUV formats: YUY2 UYVY YV12 I420
    Decoder is capable of YUV output (flags 0x2b)
    Setting fmt
    Starting
    Initialization is complete


    8. dshowserver decoder plugin for xine-lib von Petri Hintukainen herunterladen und übersetzen, setzt natürlich eine funktionierende xine-lib1.2 vorraus
    http://phivdr.dyndns.org/vdr/x…ne_2008-08-04-phi.tar.bz2
    alternativ : http://rapidshare.de/files/405…08-08-04-phi.tar.bz2.html


    Die Übersetzung kann außerhalb des xine-lib tree's erfolgen

    Code
    make


    9. kopieren und ausführbar machen der eben erstellten xineplug_decode_dshowserver.so

    Code
    xineplug_decode_dshowserver.so --> /usr/local/lib/xine/plugins/2.0/xineplug_decode_dshowserver.so


    10. Aufruf von xine ( via vdr-xine als Ausgabe vom vdr )

    Code
    nice --10  /usr/bin/xine -V xv --post vdr_video --post vdr_audio --post upmix_mono --post vdr --verbose=2  vdr:/tmp/vdr-xine/stream#demux:mpeg_pes


    gibt folgende Terminal Ausgabe :



    Quellen :
    http://code.google.com/p/coreavc-for-linux/
    http://phivdr.dyndns.org/vdr/xine-lib/dshowserver/


    Wie siehts aus ?


    [Blockierte Grafik: http://img100.imageshack.us/img100/6394/cpuloadpremierehdcx6.th.jpg]


    [Blockierte Grafik: http://img201.imageshack.us/img201/7708/viewdiscoveryhdix8.th.jpg]


    [Blockierte Grafik: http://img201.imageshack.us/img201/6915/viewdiscoveryhd2ny6.th.jpg]


    ich sach ma, Compiler ON


    Grüße vom Alex

    @ilmusi


    Vdrtransxvid hat in der config Datei eine Matrix , in der die Zielgrößen je nach Menge der Tonspuren und Länge des Files angegeben werden können.
    Voreineingestellt ist da glaube ich 900 Kbit/s, was bei 1 Tonspur und 90 Minuten so 700 Mbyte Zielgröße macht.


    Kleiner bei gleicher Bildquali gehts z.B. hiermit :


    transcode mpg 2 h264


    Grüße vom Alex

    Tach Team,


    hier mal der aktuelle Stand, ich kodiere hiermit vor allem die Sendeformate 480x368, wie sie auf Premiere SciFi, 13thStreet etc. gesendet werden.


    Da ist mir die Platzersparnis gegenüber xvid wichtiger, im Vergleich ergibt sich eine deutlich bessere Bildqqualität bei eh schon schlechtem Ausgangsmaterial :


    xvid -> 45 min -> Size 375 MByte ~ 1000 Kbit
    h264 -> 45 min -> Size 220 Mbyte ~ 550 Kbit


    Automatisch werden erledigt :
    - Bildscalierung
    - deinterlace
    - Beschnitt ( schwarze Balken )


    Der x264 Prozess skalliert auf 4 Cores und ist sehr, sehr CPU intensiv ( hier Phenom mit 4 x 2,2 Ghz , transcoding Zeit 2 x orig Länge bei 4 x 95% CPU load )


    Das Script benötigt folgende bins :


    - transcode
    - x264 ( the pure encoder )
    - faac
    - mp4creator from mpg4


    Aufruf :


    Code
    transcode_mpg_2_h264.pl File1 TargetSize File2 TargetSize File3 TargetSize



    Infiles : mpg nach Umwandlung der VDR Files z.B. mittels Projectx
    created Outfiles : selber Filename / selbes Verzeichnis -> Endung mp4 statt mpg


    Grüße vom Alex

    Tach Team,


    betrifft die Scriptvariante HDvdrpes_to_mkv_V7,
    da hatte ich doch glatt vergessen, das Löschen des test.vdr Files nach Gebrauch wieder auszukommentieren,


    daher schnell mal eine version 7a


    CBArts
    Ich bin noch nicht dazu gekommen, deine AllinOne Variante zu testen, derzeit hämmere ich an zich Varianten ffmpeg, xine-lib, dshowserver herum, um HD überhaupt wieder ruckelfrei zu sehen, sehr demprimierend das Ganze derzeit :(


    Grüße vom Alex

    Tach Team,


    Da, wie ichs verstehe, Michael auf der Mailingliste von ffmpeg ohne Bsp. nicht nachvollziehen kann, was der Unterschied "vorher / nachher" ist, anbei 2 Beispiel Files :


    Vor encoder Umstellung 1 Minute Discovery 1080i hier als mkv ~ 105 MByte :
    http://uploaded.to/?id=fxfwcx


    nach der encoder Umstellung von heute 1 Minute Discovery 1080i hier als mkv ~ 90 MByte :
    http://uploaded.to/?id=0gqbo8


    ciax
    ich hoffe, das kann helfen, die Streams zu analysieren. Im Prinzip gehts ja nur ums abspielen im xine mit Aufruf der exteren ffmpeg-libs zum dekodieren.
    Beispiele werden auf dem Bugtracker von ffmpeg ausdrücklich gewünscht.


    Grüße vom Alex

    Tach Team,


    Zeit für Die V7, bitte mal testen. Da umfangreiche Änderungen, bestimmt auch der eine oder andere Bug :


    - Die Audiospuren Zurordnung ist nun neu, sortiert wird in der Priorität :
    -- 1. AC3 >= 5 Spuren
    -- 2. AC3 < 5 Spuren
    -- 3. mp2 deklarierte Audiospuren in ihrer Reihenfolge im Original
    -- 4. mp3 deklarierte Audiospuren in originaler Folge


    - Die Scriptausgaben im Normal Modus etwas übersichtlicher



    CBArts :
    32 GiG klingt sehr nach einer FS Grenze, ich hab mal auf den RAM geschaut, den die Tools belegen, bei einer Discovery 5 GIG Aufnahme blieb dabei alles im grünen Bereich.


    Vielleicht kann mkvmerge nicht mehr als 32GIG adressieren ?
    Perl selber hat ja auch die unangenehme Eigenschaft, belegten Speicher nicht wieder freizugeben, in der Cut-Engine werden aber umlaufend immer nur 16MByte Häppchen geschrieben.


    Zu den iframes, ich denk, da gehts dann in Richtung teilweises Neukomprimieren ( an den Schnittkannten ), Ich bin aber nicht so tief in der h264 Struktur bewandert, um wenigstens mal in den derzeitigen Stream rein zu analysieren.


    Das könnte aber interessant werden.


    Grüße vom Alex

    Tach Team,
    derzeit gehts ja bei HD bissel drunter und drüber ( no Iframes im datenstrom )


    siehe : http://vdr-portal.de/board/thread.php?threadid=77664


    Ich habe ein paar Dirty Hacks eingefügt, um falsch ausgegebene Timecodes im Nachhinein für mkvmerge akzeptabel zu machen, doll ist das nicht, spielt aber erstmal.


    Da derzeit kein flüssiges Abspielen ( bei mir ) der neuen Aufnahmen nach Encoder Umstellung möglich ist, heist's erstmal Abwarten.


    Die Schnittfunktion hackt derzeit irgendwo in den Datenstrom ein, da keine Iframes mehr als Schnittkanten existieren.


    Grüße vom Alex

    Tach Team,


    nachdem ich nun 2 Tage am Problem "verpixelt, ruckeln" herumgewerkelt habe, mein aktueller Stand :


    Ich habe die letzten svn bzw. cvs versionen von ffmpeg und xine-lib ( sprich checkout von gestern abend ) installiert und verglichen mit einer H264 Aufnahme von Premiere vor der Encoder Umstellung auf non Iframes .


    Die alte Aufnahme mit Iframes skaliert bei mir sauber auf 2 CPU's wenn auch nicht 50/50 eine läuft 100 die nächste mit biszu + 60% , Ergebniss Ruckelfrei :


    http://www.abload.de/image.php?img=noiframes2rqm.jpg


    Die neu Aufnahme von gestern Abend ( hier Sunshine ) skaliert nur auf eine CPU und läßt Daten aus, sprich ruckelt ( max 15 frames gefühlt ) , vereinzelt sehe ich Blockartefakte :


    http://www.abload.de/image.php?img=noiframes3jhd.jpg


    Testumgebung :
    mkv Files die direkt aus den Streams erzeugt wurden, abgespielt im Xine, welches über vdr-xine auch meine VDR Ausgabe ist.


    Nun denn, ich glaube, die Bildekodierung des neuen Encoder-Formats ist bei weiten nocht nicht angepasst, da heißt es erstmal abwarten, was die Entwicklung so bringt.


    BTW, schneiden des neuen Encoder-Formats ist dank der fehlenden Iframes ein Krampf.
    Das Script zum Umsetzen in mkv wird hier besprochen :
    http://www.vdrportal.de/board/thread.php?threadid=73791


    Grüße vom Alex

    Tach team,


    nun mal ein kurzes Lebenszeichen,


    Die Probleme mit "cannot write to closed FIlehandle" liegen zu 99% daran, das der User der das Script ausführt nicht auf die Verzeichnisse zugreifen kann und dort nicht schreiben kann.


    Sinnvoll ist es die Scripte als der User auszuführen, dessen Homeverzeichnis in der vdrtransxvid.conf angegeben ist , ala :


    ### Dein Heimatverzeichnis, muss existieren und beschreibbar sein
    Home = "/home/alex/"


    dann als User alex ausführen.


    Damit die fertigen Aufnahmen im Videoverzeichnis von [cut] auf [del] umbenannt werden können, sollte der User ( hier "alex" ) im Videodir Schreibrechte haben.


    Das könnte z.B. über Gruppenzugehörigkeit ( user vdr , Gruppe vdr mit Schreibrechten ) gelöst werden.


    Um die Geschwindigkeit der Transcodierung zu erhöhen habe ich zu Hause "transcode" Version 1.5.0 laufen, das die Geschwindigkeit gegenüber den vorherigen Versionen um gut 20 % erhöht.


    In der Beispielstruktur :


    /home/alex/mpeg2avi/Info/Wacken Open Air 2007-Black Metal


    enstehen während vdr2mpg.pl und mpeg2avi.pl folgende Dateien :


    /home/alex/mpeg2avi/Info/Wacken Open Air 2007-Black Metal/audio.info
    Info über die vorhanden audio Spuren


    /home/alex/mpeg2avi/Info/Wacken Open Air 2007-Black Metal/epg.txt
    Der EPG Eintrag zur Aufmahme


    /home/alex/mpeg2avi/Info/Wacken Open Air 2007-Black Metal/frames.dat
    Anzahl der Frames


    /home/alex/mpeg2avi/Info/Wacken Open Air 2007-Black Metal/mpg2avi.data
    Die ermittelten Daten der Aufnahme fürs transcodieren


    /home/alex/mpeg2avi/Info/Wacken Open Air 2007-Black Metal/mpg2avi_done
    Transcodieren fertig flag


    /home/alex/mpeg2avi/Info/Wacken Open Air 2007-Black Metal/vdr2mpg_done
    vdr in mpeg und Daten ermitteln fertig flag


    Wenn keine Infos zur Aufnahme geschrieben wurden, kann die Bitrate nicht zurückgelesen werden, und wird dann auf zu klein gesetzt, ebenfalls fehlen dann die Infos zu den Audiospuren.


    Soweit erstmal



    Grüße vom Alex

    Tach team,


    sigiberlin


    Nach

    Code
    -i      Video Dir : Ort des VDR - Videoverzeichnisses
            default : /video/


    durchsucht das Script die 2 Verzeichnisebenen über dem "2008-05-29.22.27.50.50" Verzeichnis. Das Script funktioniert also bei der Verzeichnishierarchie :


    Code
    /video/4400_-_Die_Rückkehrer/Ein_grosser_Sprung_nach_vorn/2008-05-29.22.27.50.50.rec/


    Aufruf wäre bei dieser Variante klassisch "-i /video/"



    Faudeer


    Eine neuere Version gibts leider nicht, ich habe ewig nicht dran gesessen, da ich mich gerade auf HD vdr --> mkv und h264 mit kleinen Bitraten konzentriere.


    Das unscharfe Suchen ist bereits aktiviert, allerdings findet es die feinen Unterschiede ( (1) gegen (2) dann nicht mehr.


    Der Unschärfegrad wird in Zeile 173 und 338 eingestellt :

    Code
    (173)			if ( amatch ("$OSerie" , ["20%"] , "$_")) {


    Code
    (338)				if ( amatch ("$Name" , ["20%"] , "$OEpisode" )) {


    Da kann mann durch Ändern der 20 % experimentieren.


    Grüße vom Alex

    Tach Team,


    Über die 500 KBit/sec Initiativen für HD Material im Netz, ausgelößt durch den neuen Flash Player von Adobe, , bin ich ein wenig am herumspielen, was man mit h264 für SD Material so machen kann.


    500Kbit HD Links :
    --> http://www.progettosinergia.co…hvideo/flashvideoblog.htm
    --> http://www.flashcomguru.com/index.cfm/2008/2/2/jaw-drop-h264


    Ich habe für Testzwecke ein paar Commandlines zusammengelegt, die ein 400 KBit/sec ( Video ) mit aac als mp4 erzeugen.


    Originale Bildbreite bleibt dabei erhalten. Dienen soll das Ganze erstmal als Spielwiese, um die optimalen Encoding Parameter zu ermitteln, daher hier auch erstmal eine Studie.


    kurzes Beispiel mp4 hier :


    --> http://uploaded.to/?id=uh416m


    - 10 Minuten
    - 720x416
    - 400 Kbit Video ( 28,6Mbyte ) ,
    - 86Kbit Audio ( 6 Mbyte )
    - zusammen --> 37,4 MByte)



    Full Length Beispiel mit selben Codec Parametern :


    --> http://uploaded.to/?id=hcm53v


    - 41min 11 sec
    - 720x416
    - 400 Kbit Video : 117,8 Mbyte
    - 86Kbit Audio : 24,7 Mbyte
    - zusammen 153,6 Mbyte


    Die Rechte am Bildmaterial liegen beim jeweiligen Urheber, die Files werden hier nur zur technischen Demonstration verwendet.


    gebraucht wird :


    - transcode
    - x264
    - faac
    - mp4creator aus mpeg4ip


    fest codierte Bedingungen :
    - Ausgangsmaterial noninterlaced, 720x576 @16:9, mpg
    - Codierbereich 1-15000 Frames ( 10 min )


    Aufruf :
    aktuelles Verzeichnis beschreibbar ( für tmp dateien )
    Infile --> mpg mit voller Pfadangabe
    Outfile --> Endung .mp4 mit voller Pfadangabe


    Code
    ./transcode_2_h264.sh Infile Outfile


    Code transcode_2_h264.sh


    Bin gespannt, was bei euch so rauskommt, vielleicht wirds ja mal ein Script vdr -> mp4 ( SD ), der 300 Mbyte Spielfilm rückt in greifbare Nähe :)


    PS : Multipprozessor Maschine von Vorteil um die Frame/sec zu erreichen :
    hier Phenom 4 x 2,2 Ghz -> pass 1 / 52fps -> pass 2 / 23 fps


    Grüße vom Alex

    OFFTOPIC ....


    Hallo tcash,


    So knallhart sehe ich die Lage nicht, auch ich habe hier ein funtionierendes S3200 xine Sytem für hdtv laufen.


    Bevor ich aber anfange große ( und nachvollziehbare ) Howtos ( für meinen speziellen Fall mit chroot Sytsem im System ) in die User-Welt zu setzen, muß alles sauber spielen und ich den Kopf frei haben für die Anfragen für andere User.


    Ich denke Qberts Problem ist zudem noch ein spezielles ( Mischung DVB-C und DVB-S ) , das hat auch nicht jeder HDTVer hier im Forum.


    Also Gemach, die Entwicklung ist ( treiber wie auch vdr ) sehr in Bewegung, da gehts auch schon mal paar Tage rückwärts statt vorwärts.


    OFFTOPIC off..


    PS : mein wiki Eintrag ( Baustelle ) :
    gentoo hdtv vdr experimentell


    System : 1.5.14 - h264 patches
    xine-lib 1.2 hg
    xine-ui 0.99-5
    ffmpeg svn
    xine-plugin 0.8.2
    multiproto-plus


    Grüße vom Alex