Linux Schneide-Skript: MulticutMKV

[drraven]

Hallo,

funktioniert das mit einer ungepatchten x264 Version?

Gruß
Raven

[SGE]

Wenn du multicutmkv forkst und denn Fork auch multicutmkv nennst, trägt das sicher zur Verwirrung auf dem Schneide-Skript-Markt bei. :-)
Aber von Hagen Meyer gab es nur das heute noch laufende multicut. Wer dann dieses mkv da eingebaut hat weiß ich nicht

[gense]

Hey,

hab das Sktipt auf Hinweis von monarc99 entdeckt.... auf x86-Basis läuft das Skript super! @drraven Ich hab die vorkompilierten Bins von monarcs Otr-Verwaltung++ genommen. Damit laufen Sie. Unter Debian Whheezy mit zusätzlicher sources.list von deb-multimedia.org liefs nicht. Da lagen einige Bin ins nicht kompatiblen vor. Einer hat sogar ne komplett Option gefehlt (und ich hab mich noch gewunderet warums nicht geht :-) ) Eine Bin musst du dir aber kombinieren.... die dev-Abhänigkeiten aus den debian-Repos haben alle funktioniert. War ne Sache von 10min. Wenn nur alles bisher so gut geklappt hätter! ;-) Wenn du Probleme hast kann ich dir ggf. helfen, habs ja gerade erst durch und meine Erinnerungen sind noch frisch. Bin aber echt kein Linux-Profi.

@monarc99 Du wolltest ja noch was zur Qualität der Schnitte wissen. Bin erst gestern spät abends wieder dazuzukommen an OTR zu arbeiten. Und hab dann nacht um 1:30 das Skript mit 2 Files durchlaufen lassen und mir die Schnitte angesehen. Mir fielen fast die Augen zu. Bei einem Cut war definitiv en paar Sekunden nach dem Schnitt eine Veränderung der Farbe festzustellen. Sättigung? Helligkeit? Kein Plan..... bei den anderen Cuts ist mir das nicht direkt aufgefallen.... da ich aber echt müde war und du die Cuts so gut sind, dass du schon höllisch aufpassen musst, kanns auch gut sein, dass ich es echt nur übersehen habe. Die Qualität der Cuts sind für mein Laien-Verständis aber echt super, nicht bemerkbar. Ich habe aber keine Vgl-Files zur Verfügung. Ich werde die Woche aber definitiv noch eine Menge Files testen und dir dann noch mal Rückmeldung geben. Wenn du möchtest kann ich dir auch 1,2 geschnittene Files zur Verfügung stellen. Beachte aber, dass ich sowieso deine Version von mkvmerge und x264 verwende (fast alle Bins). Könnte also wenns Unterschiede gibt nur an der Ansteuerung der Bins liegen.

Gruß Gense

PS. So lange die Erinnerungen noch frisch sind, kann ich ja ggf. die verwendeten Bins noch mal alle auflisten, inkl. Quelle (im Zweifel immer monarc99 Bins ;-p ) @Johnny... les gerade, dass du die Bins aus den Repros genommen hast?????

[Jonny007MKD]

funktioniert das mit einer ungepatchten x264 Version?

@Jonny... les gerade, dass du die Bins aus den Repros genommen hast?????
Ich habe das x264 (und auch den anderen Kram) aus dem Repository von Debian Jessie genommen, also brauchte ich keinen Patch. Wie das mit anderen Quellen aussieht weiß ich nicht :) @gense: Das darfst du gerne mal beschreiben!


Wenn du multicutmkv forkst und denn Fork auch multicutmkv nennst, trägt das sicher zur Verwirrung auf dem Schneide-Skript-Markt bei. :-)
Aber von Hagen Meyer gab es nur das heute noch laufende multicut. Wer dann dieses mkv da eingebaut hat weiß ich nicht
Naja, ich habe das Skript von irgendwo kopiert und Fehler behoben. Deshalb wollte ich es jetzt nicht umbenennen. Ich möchte aber auch keinen fremden Ruhm einheimsen, sondern sehe mich eher als Maintainer ;) Erweitert wurde es 2013 mal von Christof Schulze, vielleicht hat der ja mkv angehängt ;)


Bei einem Cut war definitiv en paar Sekunden nach dem Schnitt eine Veränderung der Farbe festzustellen. Sättigung? Helligkeit?

Gestern ist mir auch aufgefallen, dass ein paar Sekunden lang die Sättigkeit höher war (die Gesichter waren plötzlich so rötlich, als ob allen heiß wäre). Dann fiel mir ein, dass ich das auch schon früher bemerkt, aber noch nie mit dem Schneiden in Verbindung gebracht habe. Besonders gestört hat es mich auch nie.

greetz

[gense]

Er hat die binaries nur für x86 kompiliert. Weiß das, da er zuerst dachte, ich hätte so ne fertig NAS auf arm.

[monarc99]

Bei mir läuft es mit x264 0.142.2431+gita5831aa-1+rpi1+b1. Entweder hatte ich Glück, Christof Schulze hat irgendwas richtig gemacht oder x264 ist besser geworden :D


Nein ;)

Beim SmartRendern entfernst du Teile des Streams und ersetzt sie durch neue.

Vergleichbar - wie bei einem Auto, wenn du ein Ersatzteil einbaust. z.B. einem VW Model von 1970 die Kurbelwelle austauscht.
Und da nimmst du ja auch ein Ersatzteil von einem 1970 VW Model und baust nicht ne Kurbelwelle eines VW von 2010 ein, bloß weil auf beidem VW steht.

Die Version bei den anderen Binaries ist nicht so wichtig, sofern sie die Funktionen unterstützen. Aber die x264 muss genau sein, sonst schneidet ihr den Stream kaputt.
Das merkt man im Software Player am Anfang vielleicht nicht, aber viele andere Player spielen die Dateien dann nicht. z.B. Fernseher/Medienplayer usw ...

[Jonny007MKD]

Die Version bei den anderen Binaries ist nicht so wichtig, sofern sie die Funktionen unterstützen. Aber die x264 muss genau sein, sonst schneidet ihr den Stream kaputt.
Das merkt man im Software Player am Anfang vielleicht nicht, aber viele andere Player spielen die Dateien dann nicht. z.B. Fernseher/Medienplayer usw ...
Mhm, und ich dachte für sowas gibt es Standards und so. Damit nicht jede neue Version die andere kaputt macht. Aber mein RasPi, mein Handy (beide mit Hardware-Decoder) und mein Tablet (da weiß ichs nicht) haben bisher alle geschnittenen Filme problemlos abgespielt.

Was hindert OTR denn daran, ihr x264 mal auf einen aktuellen Stand zu bringen? :)

greetz

[monarc99]

Hi,
Anschließend sollte es auch ohne LC_ALL=C funktionieren. Falls nicht, wüsste ich gerne, welches Programm den Fehler ausgibt. Du kannst beispielsweise bash -x multicutmkv.sh benutzen, um jeden einzelnen Befehl des Skripts zu verfolgen.

Das dürfte von meiner statischen mkvmerge kommen. Ich hatte schon mal ne neue kompiliert, die das Problem hoffentlich nicht mehr hat. (https://github.com/monarc99/otr-verwaltung/tree/master/data/tools)
Aber bei otrv++ tritt das Problem nicht auf, weil bei jedem Binary-Aufruf sowieso die Sprachvariablen temporär auf C gestellt wird, weil man ja nicht 20 unterschiedliche Sprachen parsen möchte.

[Jonny007MKD]

Aber bei otrv++ tritt das Problem nicht auf, weil bei jedem Binary-Aufruf sowieso die Sprachvariablen temporär auf C gestellt wird, weil man ja nicht 20 unterschiedliche Sprachen parsen möchte.

Da ich von externen Programm meistens den Exit-Code verwende (verwenden kann) und nicht die Ausgabe parsen muss, überlasse ich die Sprache gerne dem Nutzer (vielleicht hilft im ja die spanische Ausgabe von mkvmerge :) ). Ich muss aber gestehen, dass ich bisher nicht wirklich darauf geachtet habe (bei grep und so).

Grüße

[monarc99]

Bei einer GUI kann man schlecht eventuell mehrere Minuten warten, bis der oder die Befehl(e) durchgelaufen ist/sind. Sonst meint der User, es ist abgestürzt, wenn sich nix rührt.
So parse ich ein wenig die Ausgaben und aktualisiere die GUI ( als Unterhaltung für den User ;) )

[Jonny007MKD]

So muss es sein :) Auf Android habe ich eine App für ICMP-Ping. Die wartet auch, bis der Befehl fertig ist, und gibt mir erst dann die Ausgabe. Wenn das Gegenüber nicht antwortet, dauert das ganz schön lange :D

In einem Skript sieht der User ja dann direkt die Ausgabe des anderen Programms, da muss ich mich nicht um die Unterhaltung kümmern :)

[gense]

Hola,

sorry.... hatte die letzten Tage eher Frauen, Alkohol, meine Kids und andere Sachen als OTR im Kopp! Jaja... je oller (älter), desto doller ;-)

Hab mich aber gestern Nacht mal wieder an den Rechner gesetzt und weiter gearbeitet.

@monarc99 ... ich zieh mir gerade das TestFile. Schneide es jetzt die Tage und stell es euch zur Kontrolle zur Verfügung. Grmpf.... mein VDSL lässt auf sich warten! Ansonsten wäre das ne gute Upload-Einweihung für den FTP geworden.... so müßt ihr euch dann mit nem 1 mbit/s Upload zufrieden geben ;-)

@Johnny.... Das mit den locales scheint sich ja geklärt zu haben. Is auch kein Ding... setzt die L_ALL jetzt sowieso im Script temporär auf C. Da die locales durch Debian eingerichtet wurden, gehe ich nicht von ner falschen Konfig aus.

Bis denne.... gense

[PyroDragonfly]

Eine Frage, wie genau muss dieses Script verwendet werden? Gibts dazu eine Readme o.ä.? Einfach script.sh Filename? Weil da kommen bei mir Fehler hoch.

[gense]

Hey du!

Hab das Script problemlos am laufen! Habe mich die letzte Zeit nur gaaanz wenig damit beschäftigt. Kann es dir (gerade auf ARbeit) nicht ausem Kopp heraus sagen wies aufgerufen wird. Guck aber gern heut abend mal nach. Hast du alle Abhänigkeiten installiert und welche Fehlermeldungen kommen denn?

Das Skript solle, wenn z.B. Abhängigkeiten fehlen oder es falsch aufgerufen wird entsprechende Meldungen rausgeben. Schau mal auf Seite 1 dir die Hinweise von Johnny und mir an. Vlt hilft es dir ja. Ansonsten wäre ne aussagekräftige Fehlerbeschreibung schon mal en erster Schritt ;-)

Gruß Gense

PS. Verfolge dieses Forum auch nur, wenn ich gerade selbst nach ner Info suche. Da mir hier aber super geholfen wurde, versuch ich gern das an dich weiterzugeben ;-)

[gense]

Eine Frage, wie genau muss dieses Script verwendet werden? Gibts dazu eine Readme o.ä.? Einfach script.sh Filename? Weil da kommen bei mir Fehler hoch.

Wenn ich mich richtig entsinne, musst du noch den Pfad wo das geschnittene File hin soll mit als Parameter übergeben. Aber eigentlich müsste das Skript die Parameter angeben, wenn du es falsch aufrufst...

[PyroDragonfly]

Das funktioniert aber nur, wenn man Avidemux hat, oder? Weiß wer, ob es das für ARM gibt (will es auf dem Banana Pi automatisieren)

[breorg]

ich habe ein Problem mit der Codierung. ä wird zu 303. kennt ihr den Fehler? ich habe UTF-8 laufen.


Tatsaechlicher Inhalt: Übereinstimmungen in Binärdatei 10182441.at.xml.
(standard_in) 1: illegal character: 303
(standard_in) 1: illegal character: 234

7648

[tegg]

Hallo,

ich habe ein Linux ARM System mit Wheezy und darauf alles scheinbar nötige installiert. Jetzt hänge ich bei mkvmerge:



Length: 822.96, Start cut: 6603.48
start: 165087 end: 185661 length: 20574
start ist kein keyframe
end ist kein keyframe
mkvmerge v5.6.0 ('Kenya Kane') built on May 28 2012 12:28:19
Error: Invalid split size in '--split parts-frames:8168-28478,38811-60526,71011-94207,102249-124113,132743-154880,165088-185520'.
mkvmerge failed


ist die Debian Wheezy Version zu alt, oder ist das ein anderer Fehler ?

[tegg]

da ich nicht mehr editieren kann, ich habe wohl selbst die Lösung gefunden, mit einer deb binary der Version 6.0.0 und damit funktioniert das ganze zumindest mal im ersten Versuch. Falls noch einer das Problem haben sollte mit Debian 7
https://launchpad.net/ubuntu/+source/mkvtoolnix/6.0.0-1/+build/4254134

[Jonny007MKD]

Hallo zusammen,

bitte entschuldigt meine Abwesenheit, ich wurde nicht über neue Posts benachrichtigt.

Auf das Problem von freddy321 bin ich (glaube ich) auch mal gestoßen, das sollte in einem Commit behoben worden sein. Letztlich waren das wohl Leerzeichen im Dateinamen o.ä.

Die Kodierungsprobleme müsste ich selbst mal sehen. Dabei brauche ich vor allem die Dateigröße, um die cutlist finden und das Script laufen lassen zu können.

Für den --split Fehler von mkvmerge ist wohl die zu alte Version verantwortlich, wie das tegg berichtet hat. Falls das die anderen bestätigen, baue ich gerne noch eine Überprüfung und eine schöne Fehlermeldung ein ;)

Grüße
Jonny007