Beiträge von TomKeller

Vielleicht ganz interessant...

Es gibt einen relativ aktuellen Versuch, einen freien DirectShow-Filter (dslibbluray) zum Lesen und Anzeigen von BD-J basierten BluRay-Menüs zu entwickeln:

http://forum.doom9.org/showthread.php?t=164314

Der hätte dann theoretisch in DirectShow-basierte Player wie MPC-HC integriert werden können. Der Entwickler von dslibbluray hatte 2014 sogar eine gepatchte MPC-HC Version veröffentlicht, die mit der beiligenden Alpha-Version von dslibbluray funktionierte und bei diversen Discs schon halbwegs funktional BluRay-Menüs anzeigen konnte. Aber dank mangelndem Interesse scheint die Entwicklung seit 2015 still zu stehen.

Ist irgendwie schade. Aber offenbar existiert wohl kein Bedarf an Menü-basierter BluRay-Navigation bei den Usern "kompakter" Software-Player wie MPC-HC, MPC-BE, ZoomPlayer & Co. ...

Zitat von MacLeod

TomKeller: Wenn man sich entsprechend auskennt, ist das sicherlich ein Klacks

Also ich weiß nicht - AviSynth-Grundlagenwissen reicht eigentlich dafür aus . Die 'Crop Funktion kennt man üblicherweise vom Abschneiden schwarzer Balken - hier wird sie halt benutzt, um die jeweilige Bildhälfte abzuschneiden. Die 'Resize' Funktionen sollten auch bekannt sein.

Frei festlegbare Script-Variablen (wie in diesem Fall 'Video', 'Links' und 'Rechts') sowie 'StackHorizontal' sind das einzig "exotische" - aber eben trotzdem: interne Funktionen, die ohne irgendwelche Plugins funktionieren. Im Vergleich zu ellenlangen Anime- oder komplizierten Deinterlacing-Scripten, die noch auf zig zusätzliche Plugins und manuelles Finetuning angewiesen sind, ist es daher meiner Meinung nach AviSynth-Basiswissen.

Zitat von MacLeod

Getrennt codieren ... Bekommt man das per Avisynth hin? Müsste man ja jeweils einen Bildbereich in Pixeln angeben und dann aber auch wieder einen Befehl haben, um die Bereich wieder zusammenzufügen.

Wo ist das Problem? Einfach zwei Crop-Aufrufe (einmal wird die linke, das andere Mal die rechte Bildhälfte abgeschnitten) mit Resize dahinter im Script und am Ende mit einem StackHorizontal abschließen. Ein entsprechendes Script (für H-SBS @ 1080p -> H-SBS @ 720p) sähe dann z.B. so aus:

Piece of cake! Ist außerdem nur notwendig, wenn man resized... und selbst dann nicht zwingend. Ohne die getrennte Behandlung der beiden Bildhälften entstehen bei einem derartigen Resizing vielleicht "schlimmstenfalls" zwei verwaschene Pixelspalten anstelle einer klaren Trennlinie in der Mitte. Wer sich dann an den kaum bis gar nicht sichtbaren Auswirkungen dieses "Dilemmas" im 3D-Betrieb stört, muss schon wirklich ziemlich pedantisch sein .

Jegliche von Flash genutzte DRM-Varianten sind nicht geknackt - also geht speichern schonmal leider überhaupt nicht. Und: nein, der Stream wird während der Wiedergabe auch nicht mal eben unverschlüsselt in einem temporären Verzeichnis zwischengespeichert... das würde ja schließlich denn Sinn und Zweck vom DRM-Schutz zunichte machen :p .

Das einzige, was da (und immer) funktioniert:
Den Bildschirm (bzw. den entsprechenden Bildschirmausschnitt) mit einer Screencapturing-Software "abfilmen" - von Tunebite bis hin zu Replay Video Capture gibt's da ja diverse Tools, um das zu bewerkstelligen. Verständlicherweise ist das aber mit diversen Einschränkungen (hinsichtlich der Framerate und Videoqualität) verbunden.

Das Video ist ein DRM-geschützter Adobe HDS Stream -> einfach so wie es ist runterladen/abspeichern NICHT möglich!

Achte mal vor allem (wegen der umbenannten Datei) auf der Autobahn darauf, ob die Anzeige mit den Ausfahrten:

... fehlerfrei funktioniert. Ich glaube nämlich irgendwie nicht, dass sich die NavigonRealityView_EU.nfs und die RealityView_EU.nfs beliebig miteinander vertauschen lassen...

Auf meinem uralten Navigon 2100 sind (neben den *.map Dateien) noch folgende *.nfs Dateien im Map-Ordner:

• Brunnel_EU.nfs
• Citymodels_EU.nfs
• Landmarks_EU.nfs
• MapDrawer.nfs
• NavigonRealityView_EU.nfs
• Poicats.nfs
• Sat_EU.nfs
• TMC.nfs

... sowie die Dateien Advisor.nfs, DrawSettings.nfs und CountryProfiles.nfs im Settings\Core Unterverzeichnis. Das ganze läuft mit den Q3/2015 Karten auf einer selbst "zusammen gehäkelten" MN 7.4.3 build 793 Version. Da die unter anderem kein Panorama View und auch keine Sprachsteuerung unterstützt (und letzteres das Navi sowieso nicht), brauche ich z.B. solche Dateien wie Terrain_EU.nfs und Phoneme_EU.nfs nicht.

Zusätzlich ist ein kleines Startmenü drauf, wo ich zwischen der ursprünglich enthaltenen MN 6 Version (für die aber seit 2013 keine Karten mehr kommen) und der MN 7 Version Marke "Eigenbau", sowie 'nem Videoplayer, ScummVM und der Windows CE Oberfläche wählen kann

Es geht? Die Frage ist: wie gut ? Normalerweise sind in den Karten-Paketen, die überall angeboten werden, auch diese zugehörigen *.nfs Dateien dabei:

Zitat

Advisor.nfs = Richtung Pfeile anzeige und korrekte ansage.
Brunnel_EU.nfs = Positionen der Tunnel für schnellen Satfix.
MapDrawer.nfs = für die Darstellung der Karten zuständig
RealityView_EU.nfs = stellt Autobahnkreuze und Autobahnausfahrten real dar
NavigonRealityView_EU.nfs = verbesserte Version von RealityView_EU.nfs
Landmarks_EU.nfs = zeigt Sehenswürdigkeiten und Sonderziele in 3D
Landmarks small_EU.nfs = zeigt Sehenswürdigkeiten und Sonderziele in 3D Icons werden etwas kleiner dargestellt als mit Landmarks_EU.nfs Datei (gibts ab MN 8 )
CityModels_EU.nfs = Städte und Ihre Gebäude so realistisch wie möglich 3D bis MN 7.6.x Versionen
GTACityModels_EU_XXX.nfs (für 17 Ländern) = Städte und Ihre Gebäude so realistisch wie möglich 3D (City View3D 2.0) ab MN 7.6.x Versionen
poicats.nfs = Darstellung der Pois
sat_EU.nfs = Darstellung der Übersichtskarte ohne GPS-Empfang
TMC.nfs = TMC empfang
Terrain_EU.nfs = Darstellung der 3D Landschaften (Panorama View)
Phoneme_EU.nfs = für die Sprachsteuerung des Navis zuständig
PhonemeV3_EU.nfs = Sprachsteuerung ( ab MN 7.7.1 )
TruckAttributes_EU.nfs = Profile für LKWs und Wohnmobile
GCM_EU.nfs = RealCity 3D nur bei 84xx
BasicPhonemeFetcher.nfs = für die Sprachsteuerung im Telefonbuch Menü.
CountryProfiles.nfs = ohne funktioniert Adresseingabe nicht!?

Alles anzeigen

... von denen man allerdings nicht alle zwingend benötigt. Welche gebraucht werden, hängt von der Mobile Navigator Version und der Hardware des Navis ab (Navis ohne Sprachsteuerung benötigen z.B. die ganzen Phoneme Dateien nicht). Die benötigten sollten aber zwingend zu den Karten passen - ansonsten kann es unter Umständen Probleme geben.

Solange es Leute runterladen weil sie das "Kinofeeling zu Hause" haben wollen, wird's auch Leute geben, die sowas hoch laden .

Theoretisch: ja. Man könnte zwar über die Halbbilder einer 1080i @ 25fps (bzw. 720p @ 50fps) BluRay einen Film mit 50hfps (bzw. 50fps) in den Handel bringen - aber sowas ist extrem unwahrscheinlich (weil: PAL... und: PAL = böse). Und 48fps (bzw. 48hfps = 24i) sind - wie du schon selbst festgestellt hast - bekanntermaßen im aktuellen BD-Standard nicht erlaubt.

Praktisch lässt sich aber ein ECHTES 48fps Release trotzdem nicht prinzipiell ausschließen. Schließlich könnte eine 48fps Version als "Digital Copy" der BluRay beiliegen, oder online als kommerzieller Web-Stream vertrieben werden. Nicht, dass sowas schon jemals passiert wäre - denkbar ist es aber trotzdem.

EDIT:
Ich hab mal einen Blick auf die ersten paar MB des Samples vom Hobbit-Release geworfen - da wurde definitiv ein Algorithmus wie MVFlowFPS verwendet, um die 24fps auf 48fps hoch zu rechnen. Schon bei den ersten paar Frames sieht man nämlich rund um den Federkiel, der sich über das Papier bewegt, wie die Struktur des Papiers rund diesen Federkiel und seinen Schatten bei Bewegung (mal deutlicher, mal weniger deutlich) verzerrt wird. Das ist ein typischer Fehler, der bei derartigen Algorithmen auftritt.

Da wurde wohl entweder jedes Frame verdoppelt, oder halt ein Interpolationsalgorithmus verwendet, um die Framerate hoch zu rechnen. Ich tippe mal auf letzteres. Je nach Algorithmus hat man dann aber entweder mit jedem zweiten Frame ein "blended" Frame (also: eine durch Überlagerung entstandene Mischung aus zwei Ursprungsframes), oder teilweise leichte bis starke Bildfehler bei viel Bewegung (bei auf Bewegungsvektoren basierten Algorithmen wie z.B. MVFlowFPS).

LSMASHSource und FFmpegSource können als Input-Plugins für AviSynth schon längere Zeit HEVC-Videos decodieren. Und wenn man ein Video in ein AviSynth-Script laden kann, dann bedeutet das, dass man auch x264 per Script mit diesem Video füttern kann... oder das Script eben in AviSynth-basierte Frontends wie MeGUI oder Handbrake laden kann. Alternativ kann man das AviSynth-Script auch per AVSF mounten und erhält dann eine virtuelle AVI-Datei, sie sich an wirklich JEDEN Encoder verfüttern lässt...

Zum Überprüfen, ob das Material telecined ist: die Avisynth-Filter TFM() oder(!) Telecide() darauf anwenden und dann (idealerweise bei einem Kameraschwenk o.ä.) schauen, ob alle 5 Frames eins doppelt vorhanden ist. Oder alternativ: das Material per internem AviSynth-Filter SeparateFields() in seine Halbbilder zerlegen und dann schauen, ob sich 3 identische Halbbilder mit 2 identischen abwechseln.

Zitat von cmxxx

Wobei ja 60 Fps ja auch 59.940 und PAL sicher auch keine genauen 25,0 und 50,0 FPS haben wird nehm ich mal an?

Du nimmst falsch . Bei NTSC-Video spricht man deshalb von 60 bzw. 30fps (obwohl in der Praxis typischerweise 59,94 bzw. 29,97fps vorliegen), weil NTSC-TV-Übertragungen zu früheren S/W-TV-Zeiten tatsächlich mit 60 Halbbildern erfolgten (machte ja Sinn wegen der Wechselstrom-Frequenz, die zu Beginn des TV-Zeitalters als Grundlage für die Aufzeichnungsfrequenz der TV-Kameras genommen wurde). Auf Wikipedia ist die Erklärung verbuddelt, warum mit Einläutung des Farbfernseh-Zeitalters die Bildwiederholrate von NTSC-TV-Geräten auf 59,94Hz herunter korrigiert wurde:

Zitat von Wikipedia

Die NTSC-Bildwiederholrate lief anfangs, in Anlehnung an das in den USA übliche Wechselstromnetz, mit genau 60 Hz. Es war günstiger, die Bildwiederholrate an die Frequenz der Energiequelle anzupassen, da sonst in der Nähe starker Stromquellen oder im Licht von Leuchtstoffröhren laufende Balken auf dem Bildschirm sichtbar gewesen wären. Die Angleichung der Wiederholrate an die Stromversorgung war außerdem für die frühen Liveübertragungen hilfreich: Es war dadurch sehr einfach, die Kamera dazu zu bringen, ein Bild zu speichern, indem man die Wechselspannung als Blendenauslöser verwendete. Im Farbsystem wurde die Wiederholrate dann leicht nach unten auf 59,94 Hz (genauer: 60.000 Halbbilder je 1001 s) abgesenkt, da sich so gewisse Interferenzen zwischen Farbträger und Tonträger verringern lassen (Bildfrequenz = 59,94005994… Hz, Zeilenfrequenz = 262,5 × Bildfrequenz = 15.734,265734… Hz, Farbträgerfrequenz = 227,5 × Zeilenfrequenz = 3.579.545,454… Hz, Tonträgerfrequenz = 286 × Zeilenfrequenz = 4.500.000,000 Hz: Farbträger und Tonträger unterscheiden sich um ein halbzahliges Vielfaches der Zeilenfrequenz)

Und deshalb erfolgen NTSC-Ausstrahlungen (immernoch) mit 59,94 bzw. 29,97fps - auch wenn diesbezüglich ab und zu von 60 bzw. 30fps gesprochen wird. Das ist also keine zufällig Schwankung der Framerate, sondern eine präzise herbei geführte Korrektur aus der Urzeit der TV-Geschichte, die Bildstörungen verhindern sollte. Bei PAL war so etwas hingegen nicht nötig - weshalb wir es hier seit jeher mit 50 bzw. 25fps zu tun haben.

An den alten Drachen:

Du kannst ja mal versuchen, die SRTs in SSA umzuwandeln, in der SSA-Datei dann die Untertitel per Styles zu positionieren und zu gestalten (so dass die Texte exakt über der original Schrift liegen und sie optimal überdecken) und die fertige SSA-Datei letztendlich per AviSynth-Script zu laden. Ist schon länger her, dass ich das mal gemacht hatte (für eine DVD-Version von "Lord of War") - hatte aber recht gut funktioniert... auch wenn ich da wenig elegant vorgegangen bin und einfach die Kontur der Schrift hochgedreht habe, um den Hintergrund zu überdecken:

Ein schwarzer Kasten, auf dem die Schrift sitzt, müsste aber auch über den SSA-Style definierbar sein - siehe hier:

Ich hab hier nur zwei *.ssa Dateien rum liegen, die ich vor Jahren als Grundlage für die Erstellung von deutschen DVD-Untertiteln zu einer US-Cartoon-Serie ("Clerks - Uncensored") geschrieben hatte. Dort sind einfach nur mehrere Styles für verschiedene Untertitel-Positionen definiert - z.B. um gleichzeitig mehrere Untertitel an verschiedenen Bildpositionen anzuzeigen. Ich hab die mal hier an den Beitrag angehängt...

Ich hab auch schon vor längerer Zeit Leute gesehen, die Animes richtig kreativ mit *.ssa Untertiteln übersetzt haben. Das ging dann sogar so weit, dass da bei Schildern die Übersetzungen direkt über die original Schrift positioniert und per Style ein balkenartiger Schrifthintergrund in der exakten Farbe des Schildes definiert wurde. Das geht natürlich nicht bei Kameraschwenks (da sich die Untertitel nicht wirklich animieren lassen) - aber da es in dem Fall nur Standbilder waren, wirkte das Ergebnis ziemlich gut.
Und ich habe vor Jahren einen Rip von "Avatar" gesehen, wo die entsprechende Na'vi Schriftart (als *.ttf Datei) in den Matroska-Container rein gemuxt war (ja... Matroska erlaubt sowas) und über eine (ebenfalls rein gemuxte) *.ssa Untertiteldatei geladen und für die Anzeige verwendet wurde. Der Nachteil ist da aber: sowas funktioniert auf quasi keinem Hardware-Player (da die üblicherweise die Schriftart nicht laden und verwenden können)... aber eben super am PC.

Zitat von cmxxx

Silvio: Danke für das Beispiel...diese Subs sind aber auch eher grob verpixelt (weil .srt sind zumindest soweit ich sie kenne scharf dargestellt)

Das liegt aber auch im Wesentlichen daran, dass VobSub-Untertitel aus 4bit Bildern bestehen, die über das Video gelegt werden... während SubRip-Untertitel (*.srt) die Untertitel einfach als Text enthalten, der erst während der Wiedergabe in das angezeigte Videobild rein gerendert wird. Die 4bit Bilder-Untertitel bei VobSub sind in ihrer Farbpalette begrenzt und liegen auch nur in der Quellauflösung des Videos vor (also häufig: SD). Für die Vollbild-Wiedergabe auf einem HD-Monitor oder -Fernseher müssen die bildbasierten Untertitel also hoch skaliert werden - und das sieht nunmal nicht besonders toll aus. SubRip-Untertitel können im Gegensatz dazu mit der vollen Bildschirmauflösung in das (während der Wiedergabe hochskalierte Videobild) rein gerendert werden - mit voller Farbtiefe. Dementsprechend ist es logisch, dass sie qualitativ überlegen sind.

SubRip ist allerdings das denkbar schlechteste textbasierte Untertitelformat. Denn es erlaubt in der Untertiteldatei selbst(!) keine Positions-, Textgrößen-, oder Schriftart-Angaben. Einzig eine Definition der Textfarbe und die Angabe von fetten, kursiven und unterstrichenen Textabschnitten ist möglich (siehe hier) - alles andere was die Darstellung betrifft, muss man im Player einstellen (sofern der das erlaubt).
Aus diesem Grund sind von allen textbasierten Untertitelformaten im Anime-Fansub-Bereich eher *.ssa bzw. *.ass Untertitel beliebt. Das SubStation-Alpha- bzw. Advanced-SubStation-Alpha-Format erlaubt nämlich die Definierung von mehreren "Styles", die man individuell den einzelnen Untertitelzeilen zuweisen kann. Dadurch ist VIEL mehr möglich, als mit *.srt Untertiteln. Man kann z.B. einzelne Untertitel-Zeilen beliebig postitionieren, größer oder kleiner als den Rest darstellen, Dialoge von zwei Personen mit zwei unterschiedlichen Schriftarten gestalten und noch viel, viel mehr (siehe hier). Allerdings ist die vollständige Unterstützung aller Möglichkeiten des SubStation-Alpha-Formats verständlicherweise vor allem für Hardware-Player ein Problem. Daher genießt es ein Nischendasein - obwohl es z.B. SubRip-Untertiteln haushoch überlegen ist.

Zitat von cmxxx

bis ende des letzten Jahrtausends (oder ist es gleich die HDTV Ära, die diese Umstellung brachte?) wurden alle Inhalte interlaced (also in Halbbildern) übertragen und dann vor Ort in den TV Geräten deinterlaced (und damit wurden wieder 50 bzw. 60 Bilder angezeigt).

Jain. Standard-Röhrenfernsehgeräte haben NIE das Bild deinterlaced. Mussten sie auch gar nicht - denn die Bilddarstellung erfolgte halbbildweise. Sprich: es wurden abwechselnd (mit 50 bzw. 60Hz Frequenz) die ungeraden und geraden Bildzeilen angezeigt = Zeilensprungverfahren. Das war also früher ideal für Aufnahmen, die halbbildweise erfolgt sind und interlaced abgespeichert wurden.

Zitat von cmxxx

wieso verwendet überhaupt jemand 1080p25/30? Wenn doch die Vorteile von 50/60 Vollbildern so deutlich sind?

Neben den von 'Q-the-STORM' angesprochenen Mehrkosten für die Speicherkapazität darf man auch nicht die Mehrkosten bei der Übertragungsbandbreite vergessen. Eine Transponderfrequenz zu mieten kostet einen Programmanbieter schließlich nicht wenig Geld... und die Bandbreite ist dabei begrenzt. Trotzdem quetschen da einige Programmanbieter unzählige Sender drauf - teilweise an der Grenze des bildqualitätsmäßig Erträglichen. Die doppelte Framerate verlangt zwar nicht nach der doppelten, aber eben doch nach einer höheren Bitrate für annähernd gleiche Qualität. Bitrate, die einfach nicht vorhanden ist.
Abhilfe können da nur neue Übertragungstechniken und Kompressionsverfahren bringen - die sich aber erst einmal etablieren müssen. Und das dauert. Denn mit derartig massiven Änderungen geht auch ein Neukauf der Empfangshardware einher.

Zitat von Q-the-STORM

Hat jetzt so lang gedauert bis sie endlich interlacing in HEVC gedropped haben, wenn dann die neuen TV standards mit HEVC kommen wird es kein interlacing oder telecining mehr im TV geben...

Wieso wird das immer behauptet ? Es stimmt zwar, dass es bei HEVC (anders als bei H.264) keine Interlace-spezifischen Encoding-Modi (wie MBAFF und PAFF) mehr geben wird - trotzdem wird auch mit HEVC interlaced Video möglich sein. In den Film- und TV-Archiven lagert einfach viel zu viel interlaced Videomaterial, als dass die Industrie eine mit einem Schlag durchgeführte, radikale "Ausrottung" von Interlacing zulassen würde .

• Da musst du vermutlich manuell an das AviSynth-Script ran, um das Wandeln zu 23,976fps plus Beschleunigung auf 25fps in einem Abwasch zu erledigen.
• Ohne das Quellmaterial gesehen zu haben, lässt sich nur EXTREM schwer sagen, ob und wie man die 29,97fps SINNVOLL umwandelt. Sind Frames in 'nem regelmäßigen Muster doppelt, könnte man z.B. einfach Decimate() drüber jagen... sind Frames ohne erkennbares Muster doppelt, wäre TDecimate() besser geeignet. Sind da keine Frames doppelt (sondern z.B. "Blendings"... also: "Mischbilder" vorhanden), sieht die Sache wiederum GANZ anders aus. Daher (wie gesagt): ohne das Quellmaterial zu kennen, lässt sich da kein pauschaler Tipp geben. Klar scheint nur zu sein: das Quellmaterial ist scheinbar NICHT "telecined", denn ansonsten gäbe es bei einer IVTC keine/selten Interlacing-Streifen.

Mal abgesehen davon, dass Maxdome unter Garantie NICHT von einem so sicheren Schutz-System wie Silverlight DRM zu einem unsicheren gewechselt haben wird, seh ich da z.B. auf den ersten Blick schon den Begriff drmurl im Quellcode. Da kommt also definitiv weiterhin ein DRM-Schutz zum Einsatz - eventuell Akamai DRM. So oder so: meines Wissens ist keine der aktuellen DRM-Techniken geknackt - die Chancen dafür, dass jetzt tatsächlich wieder ein Stream-Rip von Maxdome möglich ist, gehen daher gegen Null.

Ja, hast du...

Da muss ein groß geschriebenes -W statt einem klein geschriebenen -w stehen. Das macht einen RIESIGEN Unterschied, weil es zwei verschiedene Parameter sind:

• -w ist die Kurzform von --swfhash und verlangt, dass dahinter der SHA256-Hash der entpackten SWF-Datei in Hexadezimalform angegeben wird (notwendig für verschlüsselte RTMPE-Übertragungen)
• -W ist hingegen die Kurzform von --swfVfy -> dahinter muss einfach nur der Link zur SWF-Datei stehen... rtmpdump errechnet dann automatisch den SHA256-Hashwert

In alten Versionen von rtmpdump gab es nur die erste Variante mit der Kleinschreibung - da musste man für den Download von RTMPE-Streams noch manuell die SWF-Datei herunterladen, entpacken und einen Hashwert berechnen lassen. Aktuelle rtmpdump-Versionen machen das alles mit -W vollautomatisch - daher: Groß- und Kleinschreibung beachten!