Mich treibt gerade ein Problem so stark um, dass es mir manchmal den Schlaf raubt. Vielleicht könnt Ihr ja Licht ins Dunkel bringen?
Ich würde liebend gern komplett auf Linux umsteigen. Seit einigen Jahren beschäftige ich mich sehr stark mit Arch Linux und komme inzwischen sehr gut damit klar (nutze sogar den I3 als WM ;)).
Ich werde immer noch 2 Rechner mit Windows haben müssen (Einen fürs Musik-Machen, da ich hier mit Studio One arbeite und Einen fürs Spielen von aktuellen Triple-A-Titeln, die noch nicht für Linux portiert wurden), aber gerade beim HTPC-/Alltags-/Surfrechner, der am TV hängt, will ich komplett zu Linux (ohne Dualboot oder super-kompliziertes VGA-Passtrough in der VM).
Linux kann inzwischen einfach alles, was ich brauche... alle Formate (H265 in 10 Bit kommt dann später, wenn die Kaby Lake-Prozessoren am Start sind), automatische Framerate (mpv mit Xrandr-Script), etc., bis auf eine "Kleinigkeit": 3D in vernünftiger Qualität
Ich hätte entweder 3D-ISOs oder MVC-MKVs zur Verfügung - Die ISOs hab ich mir schon komplett abgeschminkt... dazu müsste ja die SSIF-Datei gelesen werden können... das wird in 100 Jahren wahrscheinlich nicht funktionieren. Aber bei den MKVs hätte ich noch Hoffnung.
Zur Info: Ich besitze einen TV mit passivem 3D !
Mit MakeMKV wird ja ein Header-Eintrag gesetzt (und zwar die 13, die für "Frame Sequential" steht, oder?) - dies deutet doch darauf hin, dass man mit einer Software, die Frame Sequential als Input versteht und Row Interleaved ausgeben kann (passend zum Passiv-TV) das 3D zum Laufen kriegen würde... ? also zumindest theoretisch...
bino3D und sView können das ja beide... und ich habe es inzwischen auch ausprobiert. Was am TV ankommt, ist schon 3D - das Bild hat eine Tiefe, man merkt, dass da grundsätzlich was funktioniert... aber es ruckelt sehr stark und die Bilder "überlagern" sich seltsam... Ich könnte mir vorstellen, dass es daran liegt, dass meine Hardware (noch) zu schwach auf der Brust ist (G4500 Prozessor mit integrierter HD530-Grafik), da bino und sView ja kein Hardware-Decoding können...?!
Was denkt Ihr? Ich versteh das einfach nicht - irgendwie muss es doch möglich sein, 3D aus einer Linux-Maschine rauszukriegen; v.a., wenn man einen passiven TV hat (mpv kriegt's z.B. super hin, ein HOU-File ins Interleaved-Format zu wandeln...)
3D MVC im MKV-Container unter Linux - Selbst bei Passiv-3D unmöglich?
-
-
Liegt vielleicht an der Erkältungsmedizin... aber ich verstehe gerade die Ausgangskonstellation nicht. Du spielst eine MVC-MKV mit bino/sView ab? Seit wann kann denn einer der beiden Player MVC-Video decodieren :hm: ? Wäre mir neu...
Abgesehen davon:
Es macht keinen Sinn, dass der Header-Eintrag für das "Stereoscopic Flag" bei einer MVC-MKV auf "13" steht. Das Flag sagt nämlich darüber etwas aus, wie das 3D-Video in der MKV vorliegt - und "13" steht für "Field(!) Sequential (left eye = first field)"... aber bei MVC-Videos liegt das 3D-Bild nun einmal nicht "Field Sequential" vor.EDIT:
Mein 666. Beitrag ;D ! -
Jetzt muss ich erstmal etwas loswerden (und ich hoffe, dass das für Dich nicht zu unangenehm ist, lieber Tom Keller?!): Ich hatte so gehofft, gerade von DIR eine Antwort zu bekommen Ich kenne Dich aus etlichen anderen Foren und Dein Wissen zu, u.a., Video-Themen ist nicht nur enorm, sondern Deine Antworten sind v.a. IMMER extrem kompetent und hilfreich... so... genug geschleimt... hihi..
Zu dem Header: Das finde ich jetzt schon etwas seltsam - Du hast ja nämlich definitiv Recht... aber... wenn man aus einer ISO mit MakeMKV eine MVC-MKV generiert, dann setzt das Programm hier immer, zumindest bei den Sachen, die ich bisher umgewandelt habe, die "13"... ich frage mich halt auch, was es denn sonst setzen sollte? Bei allen 14 möglichen Einträgen gibt es ja keinen Eintrag, der für "Frame Packing" steht
Deswegen bin ich ja verwirrt - mir war ja klar, dass die beiden Player das Ganze so oder so nicht können... umso mehr hat mich dann einerseits die "13" erstaunt und andererseits die Tatsache, dass ich ein Bild mit einer Tiefeninformation sehe (eben nur verlangsamt und ruckelnd - aber eben nicht "verschoben" o.ä.).
Ich hätte ja noch einen "Plan B": Da ich ja eh einen passiven TV habe, könnte ich ja einfach HOU-Files nutzen... vielleicht ist es nur Vodoo, aber irgendwie hätte ich da Angst, eine schlechtere Qualität zu sehen, als bei "nativem" Frame Packing... ist aber großer Quatsch, oder? Wenn das Videofile mit hoher Bitrate konvertiert wurde, dürfte (fast) kein Unterschied zu sehen sein, oder?
Und wenn ich den "Plan B" umsetzen wollen würde: Wie würde ich denn überhaupt unter Linux aus einer 3D-BD-(ISO) ein HOU-File generieren können (also jetzt nicht en detail, nur grob...)? Merci und Gute Besserung -
wenn man aus einer ISO mit MakeMKV eine MVC-MKV generiert, dann setzt das Programm hier immer, zumindest bei den Sachen, die ich bisher umgewandelt habe, die "13"... ich frage mich halt auch, was es denn sonst setzen sollte? Bei allen 14 möglichen Einträgen gibt es ja keinen Eintrag, der für "Frame Packing" steht
Das liegt schlicht und einfach daran, dass es meines Wissens keine offizielle Unterstützung für MVC-Video im Matroska-Container gibt. Moritz Bunkus hat laut eigener Aussage auch kein großes Interesse daran. Daher ist MakeMKV auch das einzige Tool, das MVC-MKVs (abseits der offiziellen Specs) erstellen kann.Dass es das Flag auf "13" setzt ist daher umso merkwürdiger - besser wäre es wohl, gar keins zu setzen. Denn ein Player, der zwar NUR den H.264-Anteil des MVC-Videos decodieren kann, aber sehr wohl das "Stereoscopic Flag" auswertet, wird dann nämlich ein 2D-Video decodiere, das Video in gerade und ungerade Bildzeilen aufteilen und diese dem linken und rechten Auge getrennt zuführen (was vermutlich in deinem Fall passiert und logischerweise kein wirkliches 3D-Bild liefert, da ja nur ein 2D-Bild decodiert wurde).
Wie würde ich denn überhaupt unter Linux aus einer 3D-BD-(ISO) ein HOU-File generieren können (also jetzt nicht en detail, nur grob...)? Merci und Gute Besserung
Gute Frage - nächste bitte . Von Videobearbeitung unter Linux habe ich leider nicht die geringste Ahnung. Unter Windows sollte es mit AviSynth + FRIMSource möglich sein. -
Dass es das Flag auf "13" setzt ist daher umso merkwürdiger - besser wäre es wohl, gar keins zu setzen. Denn ein Player, der zwar NUR den H.264-Anteil des MVC-Videos decodieren kann, aber sehr wohl das "Stereoscopic Flag" auswertet, wird dann nämlich ein 2D-Video decodiere, das Video in gerade und ungerade Bildzeilen aufteilen und diese dem linken und rechten Auge getrennt zuführen
Warum? Für row-Interleaving hat das Flag andere Werte. -
Ach... sorry - war spät und ich hatte auf die Schnelle nur eine Seite gefunden, wo Flag 13 als "Field Sequential (Left Eye First)" beschrieben wurde. Die Beschreibung von hier klingt aber eher nach "Frame Sequential (Left Eye First)". Läuft aber auf's Selbe hinaus: dadurch werden bei der Auswertung durch den Player die Frames 1, 3, 5, usw. für's linke und Frame 2, 4, 6, usw. für's rechte Auge angezeigt - was aber immernoch nichts mit der Art und Weise zu tun hat, wie bei einem MVC-Video das Bild gespeichert wurde und natürlich auch nichts bringt, wenn nur der "2D-Anteil" decodiert wird. Das bringt dann höchstens bei Kameraschwenks eine Pseudo-3D-Ausgabe ähnlich dem Pulfrich-Effekt...
-
Und wenn ich den "Plan B" umsetzen wollen würde: Wie würde ich denn überhaupt unter Linux aus einer 3D-BD-(ISO) ein HOU-File generieren können (also jetzt nicht en detail, nur grob...)?
Vermutlich gar nicht, fab gibts nur für Windows und OS X. -
Ach... sorry - war spät und ich hatte auf die Schnelle nur eine Seite gefunden, wo Flag 13 als "Field Sequential (Left Eye First)" beschrieben wurde. Die Beschreibung von hier klingt aber eher nach "Frame Sequential (Left Eye First)". Läuft aber auf's Selbe hinaus: dadurch werden bei der Auswertung durch den Player die Frames 1, 3, 5, usw. für's linke und Frame 2, 4, 6, usw. für's rechte Auge angezeigt - was aber immernoch nichts mit der Art und Weise zu tun hat, wie bei einem MVC-Video das Bild gespeichert wurde und natürlich auch nichts bringt, wenn nur der "2D-Anteil" decodiert wird. Das bringt dann höchstens bei Kameraschwenks eine Pseudo-3D-Ausgabe ähnlich dem Pulfrich-Effekt...
In den Specs steht, daß beide Ansichten in einen Block gepackt werden. Da dürfte eigentlich kein Player, der das Flag versteht durcheinander kommen. Ist natürlich alles recht hypothetisch. Ich müßte erst mal nachschauen, wie MakeMKV das überhaupt tatsächlich macht. Und ob das Interleaving bei Bearbeitung mit ffmpeg oder mkvmerge erhalten bleibt. Und ob es überhaupt einen Player gibt, der da Probleme macht.
Ich habe aber auch den Verdacht, daß das bei x264 mit frame-packing nicht beachtet wird./edit:
Hab's getestet, wird tatsächlich weder von x264 noch von mkvmerge gemacht. -
-
Ein großes Dankeschön schon mal an alle Nachdem ich gestern nochmal alles ausprobiert hatte, was geht (einen seltsamen und falschen Beitrag aus einem MakeMKV-Forums-Thread umgesetzt; mehrere ffmpeg- und libav-Versionen neu kompiliert... etc. ), ist die ernüchternde Erkenntnis: Der Weg führt (erstmal) zurück zu Windows 10...
-
Der Weg führt (erstmal) zurück zu Windows 10...
Oder du nimmst wine als Hilfe?: http://blog.nomoketo.de/3d-blurays-mul…o-coding-linux/
Participate now!
Don’t have an account yet? Register yourself now and be a part of our community!