Ist der Empgang des Linkin Park Konzerts am MIttwoch möglich?

  • Habs am mac mit dem vlc nightly probiert


    da läuft der stream an


    jeweils mit und ohne VDA-decoder


    aber das bild hängt nach einer sekunde nur der ton läuft noch weiter


    cpu ungefähr bei 1/3 der möglichen leistung


    I7 8kern mir 3,8 ghz

  • Ja, so ist das bei mir auch: Ton läuft weiter, bewegte Bilder sieht man nur am Anfang eine halbe Sekunde und manchmal dann beim Skippen noch ein bisschen Ruckelbild. Die vier Kerne meines Core i5 sind auch nur zu 30% ausgelastet gewesen.


    Interessanter Sender. Ich kann mich nicht beschweren, bei mir läuft es prima, allerdings nicht mit VDR! DVBViewer mit LAV schafft es auf dem i7 gerade so, am Limit. Wenn Du mir Zugang zu http://henningpingel.de gewährst, gerne Screenshots.


    Albert

  • Nutze dochbspw.
    http://www.pic-upload.de

  • hepi : Wundert mich, dass das mit VLC nicht klappt. Ich habe eigentlich nur deinen VLC Aufruf mit dem cvlc-Aufruf aus dem Ubuntuuser Wiki, der DVB-T aufnimmt kombiniert. Bei mir unter Xubuntu 14.04 startete VLC, aber zeigte die geposteten Fehlermeldungen.


    Der Stream ließ sich auf alle Fälle unter Windows mit dem DVDFab Videokonverter umrechnen. Das dauert von 4k nach 1080p zwar ne Weile, aber immerhin. Ich werde mich mal mit einem aktuellen Build von ffmpeg mit HEVC Support versuchen. Der sollte den Stream in einem MKV-Container umschieben können.


    Das finale Konzert am Mittwoch werde ich dann wohl auch nach 1080p & h264 umkodieren. Unter Linux bleib aktuell wohl nur entweder eine "Bleeding Edge" Distro zu haben oder ffmpeg komplett selbst zu bauen.


    Edit: Generell finde ich es aber "interessant", dass sowohl VLC als auch TVHeadend die Aufnahme "verweigern", wohingegen die Aufnahme mittels copy / scan stressfrei funktioniert. So ganz koscher scheint der HEVC Empfang in TVHeadend nicht zu sein.
    Wenn Interesse besteht, kann ich noch ein bisschen was zur Verarbeitung schreiben, wenn ich das Konzert am Mittwoch aufgenommen habe. Das wäre zwar Windows-spezifisch, aber auch unter Linux machbar.

  • Hi,


    ich hab mir das Ganze jetzt auch mal angesehen. VLC-Version ist bei mir "VLC media player 2.1.5 Rincewind (revision 2.1.4-49-gdab6cb5)".
    Damit kann ich problemlos den Stream aufzeichnen. Man kann zusätzlich den vlc noch mit der Option "--novideo" starten, dann wird bei der Aufnahme die CPU nicht so gebraten, die Videospur wird trotzdem mit auffgezeichnet.


    Mit "ffmpeg version 2.1.5 Copyright (c) 2000-2014 the FFmpeg developers" kann ich diese Aufnahme dann auch in eine h264 umwandeln, dauern tut es natürlich seine Zeit.


    Video vorher:
    Input #0, mpegts, from 'Downloads/vlc-record-2014-11-16-12h30m39s-dvb-s2___frequency=10994000000-.ts':
    Duration: 00:00:57.20, start: 4001.236267, bitrate: 17248 kb/s
    Program 1
    Metadata:
    service_name : SES UHD Demo Channel
    service_provider: SES
    Program 2
    Metadata:
    service_name : Astra Ultra HD Demo
    service_provider: SES ASTRA
    Stream #0:0[0xd2]: Video: hevc ([36][0][0][0] / 0x0024), yuv420p10le, 3840x2160, 50 tbr, 90k tbn, 90k tbc
    Stream #0:1[0xdc]: Audio: aac ([15][0][0][0] / 0x000F), 48000 Hz, stereo, fltp, 63 kb/s


    Video nachher: (habe ich in der Mitte abgebrochen)
    Input #0, mpegts, from 'vlc00001.ts':
    Duration: 00:00:26.00, start: 4002.636267, bitrate: 13776 kb/s
    Program 1
    Metadata:
    service_name : Service01
    service_provider: FFmpeg
    Stream #0:0[0x100]: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p, 3840x2160, 50 fps, 50 tbr, 90k tbn, 100 tbc
    Stream #0:1[0x101]: Audio: aac ([15][0][0][0] / 0x000F), 48000 Hz, stereo, fltp, 65 kb/s


    Die gewandelte Aufnahme ist auch eine 4k und kann bei mir mit ca. 60% CPU vom vlc abgespielt werden.
    Umgewandelt habe ich wie folgt:
    ffmpeg -y -i Aufnahme -acodec copy -vcodec libx264 -coder ac -level 41 -b:v 15000k -refs 2 -flags +loop -me_method umh -subq 9 -me_range 16 -qmin 10 -qmax 50 -g 24 -keyint_min 2 -copyts Datei


    Zum Testen habe ich dann noch die Originalaufnahme auf mein Tablet (Note 10.1 2014) gespielt und konnte dort mit dem MX-Player das Video mit SW-Dekodierung quasi in einer Art "Zeitlupe" (ohne Framedrops) abspielen. Zumindest kann man so beurteilen, ob die Aufnahme fehlerfrei ist und das war sie. (Man staunt schon, was die ARM-CPUs für eine Softwareleistung haben)
    Der VLC auf dem Tablet zeigt übrigens das gleiche grüne Bild wie auf dem Desktop. Der VLC hat also noch genügend Optimierungspotenzial und sollte zukünftig auf einem vergleichbaren Rechner in der Lage sein h265 wie h264 in Software wiederzugeben.

    VDR 2.6.0: ASUS Prime X470-PRO, Ryzen 7 2700, 64GB, 6TB HD, GT1030, Fedora 35 Kernel 5.15 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

  • Ab 21 Uhr bis zur Zugabe... Welches EPG wüsste das schon, wann die letzte Zugabe gemacht wird? Bei Live-Tennis weiß man auch nicht, wann das Spiel zu Ende ist. Gruß hepi


    Valider Punkt ! Na ja...ich denke 4 Stunden sollten es tun... :]


  • Der VLC hat also noch genügend Optimierungspotenzial und sollte zukünftig auf einem vergleichbaren Rechner in der Lage sein h265 wie h264 in Software wiederzugeben.


    Na das eher nicht. H265 wird definitiv Hilfe von der Grafikkarte brauchen und auch dann eine harte Nuss sein.
    Dekodieren braucht etwa 3..5x mal soviel Rechenleistung. Encodieren 4..10x bei gleicher Auflösung.

  • Aufzeichnung funktioniert jetzt, zwar mit Holzhammer gestrickt, aber egal.


    Code
    1. Input #0, mpegts, from '00001.ts':
    2. Duration: 00:04:38.84, start: 45888.638400, bitrate: 15925 kb/s
    3. Program 132
    4. Stream #0:0[0x6e]: Video: hevc (Main 10) ([36][0][0][0] / 0x0024), yuv420p10le(tv), 3840x2160, 50 fps, 50 tbr, 90k tbn, 50 tbc
    5. Stream #0:1[0x78]: Audio: aac ([15][0][0][0] / 0x000F), 48000 Hz, stereo, fltp, 74 kb/s


    Im Anhang der Patch (2.0.6)

    Files


    vdr-User-# 755 to_h264 chk_r vdr-transcode github

  • jo aufnehmen geht


    hab mal dvdfab am macbook installiert


    wenn man endlich das ding dazu bewegt hat den de-interlacer aus zu machen läufts icht gaaanz so extrem ruckelig ^^
    aber flüssig ist was anderes ^^

  • Finds immer wieder coll, was durch Wissen und engagement hier seit Jahren im VDR-Portal alles geht!
    Hut ab.
    Meinen Horizon übersteigt das bei weitem, aber wenn jemand eine (gerne uach runtergerechnete) Version des Konzerts bei Sigi deponieren könnte, wäre das cool .
    Danke!

  • DVDFab hat leider (für mich) den Nachteil, dass der Videoencoder ab und an ein Logo einblendet, weil ich das Videokonvertermodull nicht lizensiert habe, sondern ein anderes, aber damit könnte ich leben.

  • Ich kann das mit ffmpeg problemlos konvertieren, 1080P und 720P bekomme ich hin, 1080i habe ich noch nicht geschafft. 1080P wird bei mir von softhddevice nicht, bzw. ruckelhaft wiedergegeben. XBMC kein Problem.


    Ich weiss noch nicht, ob ich das aufnehmen werde, ich kenne dir Gruppe nicht, meine Tochter meinte, das sei Punk/Rock, nicht so unbedingt meine Richtung.


    vdr-User-# 755 to_h264 chk_r vdr-transcode github

  • Hi,


    auf welche vdr-Version ist der patch anwendbar?


    Ich bin hier mit der amd64-Version aus debian sid unterwegs:


    Code
    1. # apt-cache policy vdr
    2. vdr:
    3. Installiert: 2.0.6-1
    4. Installationskandidat: 2.0.6-1
    5. Versionstabelle:
    6. *** 2.0.6-1 0
    7. 500 http://http.debian.net/debian/ unstable/main amd64 Packages
    8. 100 /var/lib/dpkg/status


    Wenn ich den patch anwende werden drei hunks zurückgemeldet:


    Code
    1. # patch /usr/bin/vdr < ~/vdr-2.0.6-hevc.diff
    2. patching file /usr/bin/vdr
    3. Hunk #1 FAILED at 373.
    4. 1 out of 1 hunk FAILED -- saving rejects to file /usr/bin/vdr.rej
    5. patching file /usr/bin/vdr
    6. Hunk #1 FAILED at 744.
    7. Hunk #2 FAILED at 1459.
    8. 2 out of 2 hunks FAILED -- saving rejects to file /usr/bin/vdr.rej


    Mache ich etwas verkehrt?


    Gruß dsat

    vdr1 | ea35 | ASRock B250M Pro4 | Intel Celeron CPU G3900TE | Zotac GeForce GT 710 (passiv) | TT-budget S2-3200 HDTV-S2 CI

    vdr2 | ea35 | Zotac IONITX-T (NM10) | Intel Atom D525, 2x1.80GHz (onboard) | GeForce G210, 512MB DDR3 (nVIDIA NextGen ION) (onboard) | DD cineS2 V6

    vdr3 | buster | ASUSTeK PRIME A320M-C R2.0 | AMD Athlon 3000G | Zotac GeForce GT 710 (passiv) | TT-budget S2-3200 HDTV-S2 CI

  • Also die vier Zeilen kann man auch notfalls noch per Hand editieren. Anonsten patched man den Sourcecode und nicht das Binary File.

    - Client1: Thermaltake DH 102 mit 7" TouchTFT * Debian Stretch/vdr-2.4.0/graphtft/MainMenuHooks-Patch * Zotac H55-ITX WiFi * Core i3 540 * 4GB RAM ** Zotac GT630 * 1 TB System HDD * 4 GB RAM * Harmony 900 * satip-Plugin

    - Client2: Alfawise H96 Pro Plus * KODI
    - Server: Intel Pentium G3220 * DH87RL * 16GB RAM * 4x4TB 3.5" WD RED + 1x500GB 2.5" * satip-Plugin
    - SAT>IP: Inverto iLNB

  • patching file /usr/bin/vdr

    Ähm, ja. Nicht das binary bitte..

  • Ich kann das mit ffmpeg problemlos konvertieren, 1080P und 720P bekomme ich hin, 1080i habe ich noch nicht geschafft. 1080P wird bei mir von softhddevice nicht, bzw. ruckelhaft wiedergegeben. XBMC kein Problem.


    Ich weiss noch nicht, ob ich das aufnehmen werde, ich kenne dir Gruppe nicht, meine Tochter meinte, das sei Punk/Rock, nicht so unbedingt meine Richtung.


    Das ist interessant...bei mir (unter Windows 7) hat sich eine relativ aktuelle Build von ffmpeg beschwert. Zum Einen war Stream Copy wegen Audio nicht möglich und zum Anderen brach das vollständige "Umkopieren" in einen anderen Container (wie MKV) sofort ab.


    Kannst du deine ffmpeg Version und Commandline vielleicht mal posten ?


    Danke im Voraus !


    Gruß,
    Holger

  • ffmpeg version 2.2.10


    vdr-User-# 755 to_h264 chk_r vdr-transcode github