TVHeadend Standardformat

  • Ich habe den TVHeadend (unter Linux) in der Standardeinstellung laufen. Das heißt Aufnahmen werden als TS Files gespeichert.

    Nun würde ich gerne eine Aufzeichnung weitergeben, also wäre MP4 wohl praktischer. Dafür werd ich nun mal der Anleitung hier folgen und KDEnlive nutzen.

    Wobei sich nun die Frage aufdrängt:
    Sollte ich lieber im TVHeadend von vornherein ein anderes Format als Standard nutzen?
    Da gibt's ja diverse...wenn ja welches?

    Aktueller Stand meines PoC Produktivsystems:
    Server: NAS, AMD Ryzen 3, 8GB RAM | Debian 10 Buster, NFS via ZFS, TVHeadend, Emby
    Clients: RPi3, Kodi 18 | Android Box, Kodi 17 | Emby App für Tablets und Smartphones

  • Ich muss vorrausschicken, dass ich weder Experte in TvH noch A/V-Formate bin, oder irgendwelche Erfahrungen mit KDEnlive habe !

    ich würde die Aufnahme so lassen bzw. as-is weitergeben und den Empfängern einen Player empfehlen, der ts-files abspielen kann, z.B. VLC.
    Manche TV's können auch ts, aber nicht alle.

    Warum ?
    - im ts (transport stream) stecken alle Informationen drin: alle Video- und Tonspuren, aber auch Subtitle und Videotext.

    - Mein Blick ist in Richtung spätere Weiterverarbeitung nach deiner Weitergabe, z.B. einer deiner Empfänger möchte ev. später eine Audiospur aus einem Musik-Video extrahieren um den ggf. auf einen MP3-Player zu transferieren.

    - wenn ich es richtig sehe/verstehe ist eine HD-TV-Aufnahme bereits MP4 bzw. beinhaltet MP4;
    zumindest erzählt mir VLC, dass in einer HD-TV-Aufnahme u.a. ein Stream mit Codec: H264-MPEG-4 AVC (part 10) (h264) drin sein soll.

    desweiteren gibt es m.M.n. bei einer re-codierung immer Qualitätsverluste.

    ergo bleibe ich nach Möglichkeit beim Orginal, also ts.

    SD-Material konnte ich früher gut mit ProjectX bereinigen/fehlerkorregieren/de-muxxen, leider wird es nicht weiterentwickelt und hat auch keine Unterstützung f. HD-Material.
    https://www.linuxtv.org/wiki/index.php/ProjectX

    ich glaube aber, dass tsMuxeR HD-Material kann:
    https://www.videohelp.com/software/tsMuxeR

    2 Mal editiert, zuletzt von JoeAverage (23. Juli 2020 um 04:02)

  • Du mußt unterscheiden zwischen dem Container (quasi die Verpackung, z.B. mp4 oder mkv) und dem eigentlichen Codec (z.B. h.264).
    Aber zu deiner eigentlichen Frage: Erstmal würde ich klären, ob deine Hardware überhaupt dafür geeignet ist, "on-the-fly" also in Echtzeit die ankommenden Daten zu komprimieren: Die im ts-Stream erhaltenen Daten schreibt TvHeadend einfach nur auf die Platte, ohne sie weiterzuverarbeiten. Bei anderen Ziel-Codecs muß er die ankommenden Daten verarbeiten, hauptsächlich also komprimieren. Mein Intel Pentium G4560, so ein Stromspar-Prozessor, schafft das bei SD-Auflösung, aber bei der bspw. von den privaten Sendern benutzten HD-Auflösung von 1920x1080 geht der Rechner voll in die Knie, so daß ich ihn neu starten muß....
    Wenn du das geklärt hast, können wir die TvHeadend-Konfiguration klären, die in diesem Punkt (wie in einigen anderen Punkten) nicht unbedingt selbsterklärend ist ;)

  • Für mich der wichtigste Grund *gegen* TS ist, dass der tvh Client für iOS in den TS Dateien nicht Spulen / Springen kann.
    Auswendig kenne ich keine weiteren Beispiele, aber MKV ist da als Container viel verträglicher. Ich weiß nicht mal genau ob auch was an den Streams geändert wird.

    Meinen Einstellung ist jetzt „Matroska Build in“.

  • Mein Tipp: Aufnehmen als TS, dann kann man es anschließend noch Problemlos weiterverarbeiten und es generiert keine Last auf dem TVH Server.
    On-the-fly encoding macht meines erachtens nur sinn wenn man das Signal z.B. über das Internet streamen möchte.
    Aber selbst da könnte man ggf auch noch die GPU nutzen.

    TS Streams haben wirklich den Nachteil das Sie sich echt schlecht spulen lassen etc.

    Wenn man dann doch mal etwas weiter geben möchte dann kann man die TS immer noch in eine MKV muxxen (ist ne Sache von ein paar Sekunden ) oder aufwendiger bearbeiten.

  • Stimmt auch.
    Ich spekuliere mal, weil ich grad nicht danach googeln kann:

    Wenn du auf Matroska Build In umschaltest wird da auch nix umcodiert, das ist meiner Meinung nach nur muxen /Containersachen.
    Ich stelle da keine Nachteile oder höhere Last fest.

  • Moin,

    ein Nachteil, wenn man Aufnahmen direkt als MKV speichert: es ist sehr zäh, in einer noch laufenden Aufnahme zu springen (z.B. Werbung überspringen). Das geht mit TS dagegen ad hoc.

    Ist natürlich nur relevant, wenn man diesen Use Case auch benutzt (Aufnahme eines Films starten und dann z.B. eine halbe Stunde später das anschauen beginnen).

    Ciao Louis

  • Bei TS wird der originale Stream (wie er von der Karte kommt) gespeichert, bei MKV wird der Stream (Video, Audio+, Untertitel+) nur in einen MKV-Container verpackt. Zusätzlich setzt TVHeadend Kapitelmarken an den Stellen, wo sich das Bild- und/oder Tonformat ändern - z.B. am Anfang und Ende der Werbung. Hier kann man dann bei beendeter Aufnahme in Kodi wunderbar Werbung überspringen. Auch diverse Schnittprogramme (VideoReDo) zeigen die Kapitelmarken an.

    AZi (DEV): Nexus auf LibreElec | Asrock J4205 | 4 GB RAM | 128 GB Sandisk| Rii mini
    DEV: PC Ubuntu 20.04 | Matrix
    AZi: Tanix TX3 | Android/CoreElec Dualboot (EMMC), Nexus
    WoZi: Nexus auf LibreElec | Asrock J4205 | 4GB RAM | 128 GB Sandisk SSD | Atric IR | URC7960

    NAS: unRaid, 3x6TB, 2x12TB | TV-Server: Futro S550 mit Hauppauge QuadHD DVB-C
    PayPal: paypal.me/pvdbj1

  • Ich danke euch allen für die erhellenden Antworten, da hab ich jetzt aber 'ne Menge über die Formate gelernt.

    Ich hatte meine Aufnahme mit Handbrake relativ zügig umkodiert. KDEnlive ging auch, aber ist schon sehr umfangreich.

    Je nach Wünschen und Anforderungen gibt's ja diverse Optionen, allerdings muss ich sagen, dass zumindest in meinem Anwendungsfall ein direkt nutzbares Format (wie mp4) am passendsten ist. Liegt halt einfach an den Empfängern :rolleyes:

    Mal ganz abgesehen von den jeweiligen Dateigrößen. Die TS Datei hat mal gute 5GB Größe, meine MP4 dann noch 900MB.
    Und was ich später gesehen habe, die gleiche Sendung aus der Mediathek 500MB.
    Klar ist Speicher heute nicht mehr das Problem, aber ich möchte keine 5GB mit nem lahmen Hotel-WLAN runterladen oder womöglich per Mobilfunk in DE :S

    Alles in Allem, ich bleibe also bei TS. So oft exportiere ich nix, da ist mir das Spulen in einer Aufnahme - wie @louis72 geschreiben hat, schon deutlich wichtiger - und auch häufiger.

    @BJ1: Hab ich das richtig verstanden, dass ich MKV nutzen sollte, wenn ich die Kapitelmarken für Werbung haben möchte?
    Funktioniert das zuverlässig?

    Aktueller Stand meines PoC Produktivsystems:
    Server: NAS, AMD Ryzen 3, 8GB RAM | Debian 10 Buster, NFS via ZFS, TVHeadend, Emby
    Clients: RPi3, Kodi 18 | Android Box, Kodi 17 | Emby App für Tablets und Smartphones

  • Ganz ehrlich, wenn ich die Möglichkeit habe etwas von den ÖR aus der Mediathek zu laden, dann tu ich das auch.
    Dann muss ich mir das die ganze Arbeit mit schneiden etc. damit nicht machen.

    Hast ja recht. Aber ich hab tatsächlich nicht gleich dran gedacht, war so darauf fixiert das Schneiden zu testen ;)

    Der Lerneffekt war ja da :D

    Aktueller Stand meines PoC Produktivsystems:
    Server: NAS, AMD Ryzen 3, 8GB RAM | Debian 10 Buster, NFS via ZFS, TVHeadend, Emby
    Clients: RPi3, Kodi 18 | Android Box, Kodi 17 | Emby App für Tablets und Smartphones

  • [Kapitelmarken im Stream] Funktioniert das zuverlässig?

    Nur, wenn tatsächlich auch eine Formatänderung stattfindet (z.B. Audio 5.1 nach 2.0 - z.B. Werbung) - und zurück, oder bei Änderung der Anzahl der Tonspuren. Wirklich 100% zuverlässig ist das nicht, aber es funktioniert.

    Bilder

    AZi (DEV): Nexus auf LibreElec | Asrock J4205 | 4 GB RAM | 128 GB Sandisk| Rii mini
    DEV: PC Ubuntu 20.04 | Matrix
    AZi: Tanix TX3 | Android/CoreElec Dualboot (EMMC), Nexus
    WoZi: Nexus auf LibreElec | Asrock J4205 | 4GB RAM | 128 GB Sandisk SSD | Atric IR | URC7960

    NAS: unRaid, 3x6TB, 2x12TB | TV-Server: Futro S550 mit Hauppauge QuadHD DVB-C
    PayPal: paypal.me/pvdbj1

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!