Codec Wandlung nach Hevc

Anzeige

Das kommt darauf an wie die Daten des Bildsensors ausgelesen werden. Zeilenweise seriell oder parallel.
Jedenfalls müssen die Daten eines Bildes innerhalb 1/Framerate beim Bildsensor ausgelesen sein.
Also bei 50 Frames/sek muss jedes Einzelbild des Sensors innerhalb 20 ms ausgelesen sein.

Ja, aber... spätestens mit dem Raspberry Pi 3 ist die Nutzung des Hardware-MPEG2-Dekoders nicht mehr notwendig, weil die ARM-CPU genügend Rechenleistung hat um MPEG2-Video in Software zu dekodieren.

Mir ist auch nicht bekannt dass die Raspberry Pi Foundation für aktuelle Modelle noch die Freischaltung anbietet;
und beim Modell 4 des Raspberry Pi ist die Sache ohnehin hinfällig, weil im SoC gar kein Hardware-Decoder für MPEG2-Video mehr eingebaut ist.
Hingegen sind Hardware-Decoder für H.264 und H.265 eingebaut. H.265 in Hardware ist neu beim Raspberry Pi4; ist aber nur wohl deshalb kostengünstig realisierbar weil Broadcom eine Volumenlizenz für den Codec erworben hat. Broadcom stellt eine ganze Palette an Chips für Set-Top-Boxen her. (Broadcom ist der Hersteller des SoC "Herz" eines Raspberry Pi.)

 

ich habe Winx HD Konverter getestet.
Software H.264 in H.264
3/4 Std. 1,2 GB
Hardware h.264 in H.264
1/2 Std. 760 MB.

bisher bestes Ergebnis. die 2 Quelldateien konnten auch zu einer Datei zusammengeführt werden.
Nachteil: vermutlich ohne Videotext übernahme. H.265 konnte wegen Langsamkeit nicht getestet werden. Sowohl software als auch hardware. Vermutlich Programmfehler. Support sagt, mein PC reicht nicht aus.
Sonderangebot 2019 - DVD Video Software Giveaway & Gutschein

Bedienung ist übersichtlicher. Batch ist aber nur eingeschränkt nutzbar. Kein Protokoll vorhanden.

 

Da die verseuchten Codecs ja noch eine Weile vorhanden sein werden, ist das natürlich gut, für die Besitzer solcher Hardware. Was über Software geht, ist einfacher, weil, soweit ich weiß, nur einfach das Bundeln Gebühr kostet, der Nutzer aber kostenfreie Programme zum decodieren nachinstallieren kann. Wegen so einer Seuche ist auch mal gescheitert, den Firefox mit nem Decoder auszuliefern.

Langfristig hoffe ich, dass aus av1 was wird. Genügend große Akteure sind ja daran beteiligt. Von der Hardwareseite müssten es sogar fast alle sein. Jedenfalls lese ich da Intel, AMD, nVidia, ARM, etc.

Die Tools sind halt noch nicht so ausgereift dafür. In sowas wie x264 stecken halt viele Jahre Arbeit und Optimierung bis zum Anschlag.

Ich weiß nicht, wie digitale Sensoren genau arbeiten, aber kurzes suchen ergab, dass die tatsächlich auch eine Belichtungszeit brauchen, sich diese aber auch im tausendstel Bereich bewegen kann. Vielleicht war bei dem was ich damals gelesen hatte, die Belichtungszeit zu kurz eingestellt worden. Die Technik gäbe es her. Aber scharfe Bilder von bewegten Vorgängen sehen halt nicht gut aus für unser Auge. Da braucht es ähnlich wie bei Ego-Spielen eine höhere Bildrate.

. Für was auch immer die da werkeln lassen. Dass h265 auf deinem Hobel codiert werden kann, weißt du ja aus Erfahrung.

Solange du da mit klar kommst, kannst du natürlich nehmen, was du magst.

Die eigentliche Arbeit macht ein Encoder und da gibt es nicht sooo viele. Auf der Kostenlosen Schiene und extrem ausgereift, findest du x264/5 und ffmpeg. Beides kann in anderen Projekten unter der Haube werkeln, wie etwa in Handbrake. Oder StaxRip. Oder auch in einem Videoeditor wie Avidemux.

Was es da an echten Bezahlcoder überhaupt gibt, wüsste ich gar nicht. Vor allem, weil die kostenlosen so gut sind. Die meisten Tools in dem Bereich sind frei verfügbar. Was es öfter mal als Bezahlsoft gibt (und auch mit gutem Grund), sind richtige Videoeditoren. Aber reines Konvertieren, Muxen und all das, gibt es normal für lau.

Aber was genau sagt denn nun dein Test aus? Dass der Hardwareencoder für h264 und der Softwareencoder für h264 in diesem Konverterprogramm unterschiedliche Filegrößen produziert haben und der Hardwareencoder schneller war? Nun. Das sagt alles und gar nichts.

Es ist unwahrscheinlich, dass der HW in 7/12 der Größe die gleiche Qualität gepackt hat, wie der SW. Wenn du den entsprechenden Regler bei SW verstellst, damit die Qualität sinkt, wie sieht es dann aus?

Jedenfalls, solang mich niemand vom Gegenteil überzeugt, gehe ich davon aus, dass HW-Encodierung nur auf Geschwindigkeit geht und Qualität vernachlässigt. In einem Maße, dass ich meine Videosammlung auf gar keinen Fall mit einem HW-Encoder umwandeln würde. Oder mit einem SW-Encoder auf 1pass mit fester Bitrate oder auf den schnell-schnell Voreinstellungen.

Schnell-schnell oder HW mag gut sein, wenn man sich das für's Handy oder Tablet im Zug geschwind klein rechnen will. Oder wenn man Echtzeit braucht (z.B. Transcodieren für dlna).

 

Ah stimmt ja. Du bereitest deine Dateien nicht vorher auf. Das würdest du in dem Schritt machen.

Dein Receiver hat das hoffentlich nicht mit einem Übergang geteilt. Das wäre komplizierter.

So ginge das Zusammenführen:

1) du machst ein copy /b datei1 datei2 datei3 zieldatei.

2) Du nimmst ein Tool mit Knöpfen, statt das Windows-eigene copy. Die Funktion würde file merger oder file join oder sowas heißen oder concatenate. Gibt es auch spezifischs für .ts Files, aber wozu. Das ist eher für Aufnahmen einer Digitalkamera gedacht.

3) Du nimmst einen Muxer der das kann. Mkvtoolnix beispielsweise. Teletext geht nicht, dafür aber dvb-Untertitel (das ging vor ein paar Jahre noch nicht mit den Untertiteln!!!). Und selbst wenn man die redundaten Tonspuren nicht wegläßt, wird ein ts so schonmal gut 10% kleiner beim Wechsel auf mkv.

4) Du führst die Dateien beim Aufbereiten zusammen. Ich verwende den TSDoctor. Für mpeg2 ist ProjectX empfehlenswert. In dem Arbeitsschritt kannst du auch noch schneiden. Da kann man sogar Videotextuntertitel in srt konvertieren mit den beiden Tools. (Warum auch immer man sonst den Videotext aufheben wollen würde.)

In jedem Fall würde ich dir dringend mal raten, ein paar deiner Aufnahmen auf Fehler zu prüfen. Ein wunderbares aber relatives unbekanntes Tool dafür ist der ptvm ts checker Ich kenne sonst nichts vergleichbares in dieser Einfachheit. Du kannst auch eine Probeversion vom TSDoc nutzen oder mit ProjectX schauen. Aber halt mal wirklich kucken, wie schlimm dein Empfang ist. Wenn da 0 Fehler der Normalfall sind bei dir, kannst du das mit dem Aufbereiten vernachlässigen.

 

mkvtoolnix kann bei mir keine Dateien anhängen. 1. Datei 6 Audiospuren, 2. Datei 2 Audiospuren Mp2 Datei vom Satellitenempänger SD. Warum der Satellitenempfänger beim Aufteilen in 2 GB Dateien unterschiedliche Audioformate speichert, ist mir unklar. Die Codecs sind identisch. VLC zeigt 7 Spuren. Vielleicht ist mkvtoolnix da durcheinandergekommen.
Videotext kann er auch nicht kopieren. Datei wird zwar 10% kleiner, aber der Videotext wird ja auch weggelassen. Muss also kleiner werden. Bei der Wiedergabe gibt es am Anfang eine Fehlermeldung, funktioniert aber ansonsten.

ProjektX habe ich kein ausführbares Download gefunden. Ich gehe auch davon aus, dass Java in Win10 vorhanden ist, weiß ich aber nicht.
konvertieren von Videotext in srt kann garnicht funktionieren, weil beim Senden der Videotext im Datenstrom enthalten ist und srt möglicherweise von VLC nicht wiedergegeben wird.

TS Checker bringt haufenweise Fehlermeldungen, Handbrake sagt aber 0 Fehler.

 

Der kann eh nur bis Mpeg2.

 

Die Zahl der Spuren muss natürlich übereinstimmen. Ich hab das mit total unterschiedlichen .ts getestet, aber vom gleichen Sender.

Vielleicht brauchst du doch eine Bereinigung, wenn die Spurinformationen so durcheinander sind.

Ein copy /b sollte aber in jedem Fall funktionieren, wenn dein Receiver einfach nur die Aufnahme gesplittet hat.

6 Audiospuren sind schon viel. Ich kenne 1 video 1 ac3 2 mp2 1 videotext (kann mkvtoolnix nicht) 1 dvb-sub und 1 epg (kann fast nix) bei diversen ÖR.

Aaaalso. Meine 2,2 GB Datei von ard alpha. 90 mb mp2 x2 208 mb ac3 115 mb teletext. Wieder was gelernt. Von den 10% Ersparnis ist die Hälfte tatsächlich der Videotext.

Mit was hast du denn gesucht

ProjectX Complete das richtige aussuchen

ProjectX 0.91.0 Free Download - VideoHelp Weiter unten bei den Portable Versionen.

Nur für ProjectX brauchst du dir kein Java antun. Java ist kein Bestandteil von W10 und die halbe Versionsnummer ProjectX mehr, die du mit der Java-Version bekommst, reißt es nicht raus. Nimm eine der anderen Versionen, wo die notwendigen Bibliotheken mit dabei sind.

Bahnhof?

Videotext ist maschinenverarbeitbar ohne OCR. Um Untertitel zu extrahieren brauchst du bei ProjectX die jeweilige Texttafel einstellen. Sind eh immer die gleichen, je nach Sender. Auch beim TSDoctor kannst du die Standard-UT-Seiten beim bearbeiten einfach als Textdateien (= .srt) extrahieren. TSDoc 2 hat sogar ein OCR Modul für die dvb-UT. Bei ProjectX ist ein Konverter für dvb zu nem anderen Bildbasierten UT-Format, aber dafür brauchst du die richtige Farbtabelle einstellen, z.B RTLdeu für die Sender der RTL-Gruppe.

Und VLC, nun, der kann sowohl Videotext als solches, als auch jede nur denkbare Form von Untertitel. Da stehen etwa zwei Dutzend verschiedene Dateiendungen zur Auswahl. Jeder Feld- Wald- und Wiesenmedienplayer kann .srt. Sogar mein Fernseher kann .srt.

Das Kunststück ist es manchmal, die Untertitel automatisch zu laden, oder aus dem Container sichtbar zu machen. Lustigerweise kann mein Standardmedienplayer dvb-Untertitel nicht aus dem .ts, aber als ich das die Tage in mkv umwandelte, war die Untertitelspur plötzlich auswählbar.

Für .srt ist die Konvention, dass das File genauso heißt wie das Videofile und nur die Endung .srt hat. Manche Player erwarten die UT auch in einem Unterordner. Und wenn man am muxen ist, kann man viele UT auch als Datenstrom in den Container muxen.

Es gibt verschiedene Fehler und Fehler sind ggf. verschieden schlimm.

Prüft handbrake ein Eingabefile irgendwie? Solange ein Encoder nicht abstürzt, frisst der schon alles, was man ihm so vorwirft, aber die Fehler von denen ich rede, können dann halt als Artefakte sichtbar werden, weil so ein Encoder nicht von der Fehlerrate eines Live-TV-Datenstromes ausgeht, sondern von Quellen aus dem Computerumfeld. Da sind solche Fehler nicht vorhanden. Wenn du von Festplatte oder Grafikkarte liest, gibt es keine Übertragungsfehler, wie bei dvb.

Je nach Art der Fehler kannst du tatsächlich 1000 Fehler die Stunde haben und nichts auffälliges im Bild sehen und umgekehrt 3 Fehler haben, über die dann dein Ton knackst oder mehrere Sekunden grüne Balken im Bild.

Wenn dir der ts checker einen Haufen Fehler bringt, solltest du eine der ProjectX Versionen ohne Java installieren und dein File mal da durchpumpen.

 

Dafür aber super gut.

Ich hatte schon massive Bildfehler, die der TSDoc nicht reparieren konnte, die hat PX wegbekommen. Also so Fehler, wo für paar Sekunden das Bild weg ist. Vermutlich in nem i Frame, wo dann der Decoder drüber stolpert.

Und weil halt für ein Rekodieren zuerstmal Decodiert werden muss, braucht es normalerweise diesen Zwischenschritt, außer man hat sehr guten Empfang. Aber da man da auch gleich Schneiden und Tonspuren oder Videotext wegwerfen kann ... halt alles, um es mundgerecht für eine Codierung vorzubereiten, ist es generell nicht verkehrt. Teilweise kann man es auch einfach demuxed lassen und so dem Encoder geben - der braucht sowieso nur die Videospur. Wo man da allerdings aufpassen muss, dass der Audioversatz richtig gemacht wird, sonst ist die Tonspur beim muxen versetzt. Bei HD musste ich diesen Umstand auch erst lernen, weil PX das ja nicht kann.

 

Mal eine Frage zur Hardwarebeschleunigung. Wenn man ein Videofile recodieren möchte, beispielsweise um Platz zu sparen ohne allzuviel Qualität zu verlieren ... wie sieht es da mit der Decodierung aus?

Ein Encoder braucht ja den unkomprimierten Datenstrom. Der muss zwar nicht auf Platte vorliegen, es reicht die Ausgabe eines Decoders in die Eingabe des Encoders zu leiten. Aber Decodieren muss man sein File trotzdem irgendwie.

Nun ist es ja so, dass da auch viel mit Hardwarebeschleunigung gemacht werden kann. Ich weiß halt, dass genauso wie die Encodierung, die Decodierung kein eindeutiger Vorgang ist. Sprich verschiedene Decoder liefern verschiedene Ergebnisse. Und teilweise sind bestimmte Filter Teil des Decodiervorganges bzw. das ist ein fließender Übergang.

Also kann es vorkommen, dass ein File auf einer Maschine anders encodiert wird, weil das Konverterprogramm meinte, eine bestimmte Hardwarebeschleunigung beim Decodieren der Quelle auszuwählen? Und wieviel Einfluss hat sowas? Beim Encodieren scheint es ja so zu sein, dass die Hardwarebeschleunigung eher schlechter in der Qualität ist. Ist das beim Decodieren auch so?

Ich nehme mal an gerade bei mpeg2 ist das irrelevant, weil man normal keine HW-Beschleunigung zum Darstellen bzw. Decodieren braucht und einfach eine bewehrte SW-Lösung hernimmt. Aber hevc ist da halt schon anspruchsvoller.

 

Soweit ich das bisher mitbekommen habe, wird immer über Hardware decodiert, auch beim Softwareencoding. Qualitätsprobleme habe ich bisher noch keine gesehen, eher Geschwindigkeits und Größenprobleme. Hab auch den Qualitätsunterschied zwischen Mpeg2 und H.264 (HD) gesehen nach dem Umwandeln. Ist eben nur etwas unschärfer.

Bei Winx und Mpg2 nach Mpg4 (H.264) Softwareencoding dauert es 20 min. für 1 1/2Std. Video. Problem, das Video wird nicht in Bildschirmgröße angezeigt. Bei Handbrake wird es nach der Codierung und VLC in Bildschirmgröße angezeigt. Ich habe dann bei WinX ein etwas größeres Ausgabeformat eingestellt, dann funktioiert es. Aber das kann doch nicht die Lösung sein. Die Datei wird dadurch 50% größer.