Debian: HD-Filme umkodieren...

Debian: HD-Filme umkodieren... (25 Beiträge, 487 Mal gelesen)

Du bist nicht angemeldet. [ Login/Registrieren ]

Falls einer von euch dasselbe Prob hat:

Ich hatte einige Aufnahmen eines SAT-Receivers (Universum HD) - und wollte die umkodieren. Mit Debian squeeze klappte es nicht - ffmpeg auf debian-multimedia.org ist in einer zu alten Version. Mit wheezy klappte es perfekt mit dem Paket von debian-multimedia.org.

Daher meine Empfehlung, einen Umstieg zu überdenken, wenn man mit Videos was unter Debian machen will...

Was spricht gegen direkt vom Source builden?

Dass Du dann händisch immer selbst nachziehen musst... Distris sind nicht unbequem

Dass Du dann händisch immer selbst nachziehen musst...

.... falls man ein neues Feature braucht, wobei ffmpeg nicht soooo ein umfangreicher Brocken ist. Da hab ich schon schlimmere SW-Kolosse + Dependencies + patches per Makefile halb-automatisiert = Wenn man einmal die paar configure-Options + libs beinander hat, flutscht's beim nächsten Mal fast von selbst.

Distris sind nicht unbequem

schon, aber je nach Anwendungsfall ist mir eine solide Debian allemal lieber

Auch sonst wirkt die squeeze im Vergleich schon seeehr alt... Wie auch immer, ist ja nur mein Tipp, muss ja nicht für alle zutreffen

Auch sonst wirkt die squeeze im Vergleich schon seeehr alt

IMHO stagnieren viele Teile des gesamten Unix-Ökosystems, gerade beim Desktop.

Auf einem Server für klassische Anwendungen ist (mir) das wurscht, aber für Enduser würde ich mir wieder echte Innovationen wünschen, denn Fenstersysteme, Usability, universelle Komponenten (denke da an eine Weiterentwicklung a la Powershell), Live-Transfer eines Desktops (ich mein jetzt nicht VNC/RDP, sondern so wie bei Sun Ray auf Basis von Java vor ~14 Jahren (!) vorgesehen war), überhaupt: ein richtiger Netzwerkdesktop (nicht nur cifs- und webdav-Plugins für Konqueror & Co), 100e gute Ideen sind wieder in der Versenkung verschwunden, und der status quo war eigentlich vor 10 Jahren auch keine Science Fiction.

Da ist die Effekthascherei von KDE, Gnome, Unity, Compiz, e16, Wayland und wie die Dauerstichwortgeber alle heißen, auch nur Farbe auf der Fassade eines Usability-Ansatzes, der sich in den letzten 20 Jahren (seit der OS/2 WPS) nicht wirklich vom Fleck bewegt hat.

Ob Debian keine bleeding edge in den Repos hat (nehm ich halt Mint, Kanotix oder GRML....) ist schon vernachlässigbar, solange man >90% der gewünschten SW darauf zuverlässig selbst compilieren kann.

Die Qualität der Installationstools bei ausgefallenen Konfigurationen (Notebooks, neueste oder embedded Hardware) steht auf einem anderen Blatt, aber da haben alle Distributionen regelmässig ihre mehr oder weniger peinlichen Ausrutscher.

19.04.2012, 00:13 Uhr - Editiert von user86060, alte Version: hier

universelle Komponenten (denke da an eine Weiterentwicklung a la Powershell)

Nah bitte absolutes NoGo so eine verquerte Architektur wie Powershell einführen. Was kannst mit der BASH nicht machen wofür du die Bauernshell brauchst ?

Live-Transfer eines Desktops (ich mein jetzt nicht VNC/RDP, sondern so wie bei
Sun Ray auf Basis von Java vor ~14 Jahren (!) vorgesehen war),

X11 ? Oder was meinst mit Live-Transfer ?

überhaupt: ein richtiger Netzwerkdesktop

X ist ein richtiger Netzwerkdesktop. Oder was kannst ned übers Netz machen (und ich mein auch nicht RDP/VNC).

Thou shalt not use the phrase "this should be simple" unless thou has confirmed it as such.

Was kannst mit der BASH nicht machen wofür du die Bauernshell brauchst ?

nicht nur Streams/Pipes verknüpfen und verarbeiten, sondern typisierte Objekte?

X11 ? Oder was meinst mit Live-Transfer ?

ausloggen und den Status auf einer anderen Maschine wiederherstellen (nennen manche AFAIR auch "floating desktop"), und zwar nicht nur mit zB per X11-Proxy-Server, der den Login offenhält (a la screen) sondern wirklich eine identische Umgebung anderswo startet und ~/ synced.

(Sun Ray war halt auch "nur" ein Terminalsystem)

X ist ein richtiger Netzwerkdesktop.

Netzwerkfähig, im Sinn von ein Fenstersystem mit remote-fähiger Darstellung,
aber kein Desktop, der Services quer durch das Netz transparent integriert,
das tun auch sämtliche GNOME-Fenstermanager und -Tools nicht, obwohl "GNOME"
sowas im Namen für sich andeutet.
Es bleibt ein lokales System mit Terminalfenstern.

Vieles ließe sich mit allerlei Kniffen zusammenbasteln, aber die größere
Vision, wie ein Desktop in Zukunft funktionieren soll fehlt, ich denke da
an Serien wie CSI, wo Arbeitsflächen gezeigt werden, auf denen Applikationen
mit einem Wisch vom Schreibtisch auf ein Tablet transferiert oder
Daten remote auf ein Handy gesendet werden.
Das wäre ja nicht einmal eine Hexerei, aber sämtliche Desktops arbeiten
exakt so, wie schon vor 20 Jahren.

Man freut sich, daß Cut&Paste zw. Gnome + KDE funktioniert, über Klickibunti-Effekte, die beweisen, daß man auch OpenGL endlich im Griff hat, über DBus und
Gecko-Engine-Updates, aber der Desktop als ARBEITSFLÄCHE stagniert in Sichtweite
der Vision, wie sie schon in den Xerox-Labs zu sehen war.

nicht nur Streams/Pipes verknüpfen und verarbeiten, sondern typisierte
Objekte?

Ne davon halt ich pers. garnix, man hat schon zu oft die negativen Seiten gesehen wenn alle alles dürfen. Außerdem kann man unter Unix schon extrem viel mit Pipes anstellen - das alles ein Object sein muß ist imo unnötig.

ausloggen und den Status auf einer anderen Maschine wiederherstellen (nennen
manche AFAIR auch "floating desktop"), und zwar nicht nur mit zB per
X11-Proxy-Server, der den Login offenhält (a la screen) sondern wirklich eine
identische Umgebung anderswo startet und ~/ synced.

(Sun Ray war halt auch "nur" ein Terminalsystem)

Wenn dein ~ auf einem Netzwerk ist ists ja kein Problem, bis auf concurrent Betrieb. Session schließen => andere Maschine => gleicher User => und weiter gehts.

der Services quer durch das Netz transparent integriert,

Das mußt mir mal jetzt genauer erklären. Meinst Du damit Daemons oder was für Services meinst du ?

lg.

Thou shalt not use the phrase "this should be simple" unless thou has confirmed it as such.

Ne davon halt ich pers. garnix, man hat schon zu oft die negativen Seiten gesehen wenn alle alles dürfen. Außerdem kann man unter Unix schon extrem viel
mit Pipes anstellen - das alles ein Object sein muß ist imo unnötig.

IMO ... sollte man die Möglichkeiten von Objektorientierung und Möglichkeiten von Ablauf- und Flußsteuerung einmal durchdenken.

Den Ansatz von Plan9 finde ich auch extrem sympathisch (wo zB nicht nur Dateien netzwerktransparent funktionieren, sondern auch named pipes und devices). Wenn man nun einen Layer analog SOAP oder CORBA bis zur Shell hinzufügt, ergäben sich ganz neue Arbeitsweisen.

Den Linux-Ansatz, alles auf unix-gemeinsame Nenner und grade aktuelle Hypes hin zu entwickeln, ist zwar pragmatisch + OK, aber einen Schub zu einem moderneren System bewirkt man damit nicht.

Da waren IRIX und BeOS vom Feeling her von einem anderen Kaliber.

oft die negativen Seiten gesehen wenn alle alles dürfen

Rechte und ACLs könnten bei Objekten genauso greifen, wie bei Pipes/Sockets usw.

Wenn dein ~ auf einem Netzwerk ist ists ja kein Problem, bis auf concurrent Betrieb. Session schließen => andere Maschine => gleicher User => und weiter gehts.

schon, aber was ist mit teils offline betriebenen Geräten (vulgo: Notebook)?
Warum gibt es keinen zentralen Dienst + eine Semantik für das Syncen und übertragen (an die sich Programme wiederum halten können)? Im Moment ist es schon mühsam genug, Browser-Bookmarks rechner- oder programmübergreifend synchron zu halten.

Nachtrag:

der Services quer durch das Netz transparent integriert,

Das mußt mir mal jetzt genauer erklären. Meinst Du damit Daemons oder was für
Services meinst du ?

Schauen wir uns die Arbeitsweise von Admins heute an:
mehr oder weniger großer Bildschirm, und was ist offen? Browser, Mailprogramm, und .... 7 Terminalfenster mit SSH quer durch die Weltgeschichte.

Besteht der Erfolg des PC-Unix-Desktops wirklich nur in ausufernder Auflösung für noch mehr Textfenster mit noch kleineren Fonts?

19.04.2012, 12:59 Uhr - Editiert von user86060, alte Version: hier

Den Ansatz von Plan9 finde ich auch extrem sympathisch (wo zB nicht nur
Dateien netzwerktransparent funktionieren, sondern auch named pipes und
devices). Wenn man nun einen Layer analog SOAP oder CORBA bis zur Shell
hinzufügt, ergäben sich ganz neue Arbeitsweisen.

Den Linux-Ansatz, alles auf unix-gemeinsame Nenner und grade aktuelle Hypes
hin zu entwickeln, ist zwar pragmatisch + OK, aber einen Schub zu einem
moderneren System bewirkt man damit nicht.

Das liegt aber AFAIK nicht wirklich an Linux sondern an der generellen Ausrichtung bei Open Source.

Rechte und ACLs könnten bei Objekten genauso greifen, wie bei Pipes/Sockets
usw.

Aber halt nicht mit dem ACL-losen Attributen die bei den meisten vorkonfiguriert sind. Ich schaudere halt immer bissl wenn ich sowas hör weil mich das an das ActiveX Fiasko erinnert.

schon, aber was ist mit teils offline betriebenen Geräten (vulgo: Notebook)?
Warum gibt es keinen zentralen Dienst + eine Semantik für das Syncen und
übertragen (an die sich Programme wiederum halten können)? Im Moment ist es
schon mühsam genug, Browser-Bookmarks rechner- oder programmübergreifend
synchron zu halten.

Ubuntu bietet sowas doch an. Aber wie soll ein Netbook offline was syncen ?
Wenn Herr X um 10:30 was ändert und Herr Y mit Netbook um 10:45 was öffnet ist es ja auch nicht synchronisiert (vielleicht versteh ich jetzt was total falsch was Du meinst).

Besteht der Erfolg des PC-Unix-Desktops wirklich nur in ausufernder Auflösung
für noch mehr Textfenster mit noch kleineren Fonts?

Ahso meinst Du so eine Servicesteuerung ala Windows die ich auch remote machen kann ?

lg.

Thou shalt not use the phrase "this should be simple" unless thou has confirmed it as such.

Das liegt aber AFAIK nicht wirklich an Linux sondern an der generellen Ausrichtung bei Open Source.

teils, wobei Linux eine schon nahezu stellvertretende Stellung einnimmt.
Aber viele Projekte werden wieder plattformübergreifender.
Ändert halt nichts am Linux-nahen Dilemma.

Aber halt nicht mit dem ACL-losen Attributen die bei den meisten vorkonfiguriert sind.

vgl. Torvald-Kritik an SuSE vor ein paar Wochen. Unix ist ein tolles, zeitloses Konzept, aber die best practices stecken in einer Sackgasse.

Ubuntu bietet sowas doch an.

sobald die 12.04 da ist werd ich wieder reinschnuppern.

Aber wie soll ein Netbook offline was syncen ?
Wenn Herr X um 10:30 was ändert und Herr Y mit Netbook um 10:45 was öffnet ist
es ja auch nicht synchronisiert (vielleicht versteh ich jetzt was total falsch
was Du meinst).

das wäre Groupware = wieder etwas andere Baustelle.
Mir geht es aber noch um den "personal desktop", ein bißchen "personal cloud", wob man eine Reihe von Geräten logisch verbindet nicht drüber nachdenken muß, was man wo zuletzt aktualisiert hat.
Ich weiß, meine Vorstellungen sind noch vage formuliert.
Momentan bleiben einem fast nur 2 Extreme: alles auf einem Notebook herumschleppen, oder alles auf einem Server belassen und grundsätzlich mit VPN + Remote Desktop arbeiten.

Ahso meinst Du so eine Servicesteuerung ala Windows die ich auch remote machen kann ?

unter anderem. Vor allem einmal weg von dem /etc-Wildwuchs mit zig Subformaten, hin zu einer Art (nicht entarteten) Registry auf XML-Basis und vereinheitlichter Semantik (sodaß auch zB eine Apache-Config (bzw. Teile davon) für nginx oder lighttpd benutzt werden kann, ohne in einer Script-Hölle zu landen).

Davon ausgehend sollte man auch ganze Services einfacher transferieren können, nicht nur als ganze VM, sondern zB auch von einer Plattform auf eine andere (Linux->BSD oder Cygwin)

Mir geht es aber noch um den "personal desktop", ein bißchen "personal cloud",
wob man eine Reihe von Geräten logisch verbindet nicht drüber nachdenken muß,
was man wo zuletzt aktualisiert hat.
Ich weiß, meine Vorstellungen sind noch vage formuliert.
Momentan bleiben einem fast nur 2 Extreme: alles auf einem Notebook
herumschleppen, oder alles auf einem Server belassen und grundsätzlich mit VPN
+ Remote Desktop arbeiten.

Na auch wenn Du eine Cloud hast, mußt ja zwangsweise online gehen. Und ob ich mich da so einwähle oder direkt in die Firma via VPN und mich dann einlogge in den Account ist ja egal eigentlich.

Vor allem einmal weg von dem /etc-Wildwuchs mit zig Subformaten, hin zu einer
Art (nicht entarteten) Registry auf XML-Basis und vereinheitlichter Semantik
(sodaß auch zB eine Apache-Config (bzw. Teile davon) für nginx oder lighttpd
benutzt werden kann, ohne in einer Script-Hölle zu landen).

Ah gut ja, da bin ich völlig Deiner Meinung. Da gehört mal aufgeräumt und alles in XML Formate gespeichert die sich ebenso nett validieren lassen.

Einzig schlimmer als /etc sind ODMs, Registrys oder sonstig total geschlossene Configurations.

Davon ausgehend sollte man auch ganze Services einfacher transferieren können,
nicht nur als ganze VM, sondern zB auch von einer Plattform auf eine andere
(Linux->BSD oder Cygwin)

Übernehmen kannst ja die Configs 1:1 (außer jetzt auf z.B. EBDIC Systeme).

Thou shalt not use the phrase "this should be simple" unless thou has confirmed it as such.

Na auch wenn Du eine Cloud hast, mußt ja zwangsweise online gehen. Und ob ich
mich da so einwähle oder direkt in die Firma via VPN und mich dann einlogge in
den Account ist ja egal eigentlich.

jein, hängt von den Datenmengen und Bandbreiten ab, die man grade hat, oder wenn man trotzdem einmal zwischendurch offline ist.
Die nächste Netbook/Ultrabook-Generation soll ja auch im Standby online bleiben können, da ergeben sich ganz neue Möglichkeiten, ich hoffe, die OS-Hersteller versauen es nicht wieder mangels Plan, wie man es zielführend ein- und umsetzt, so wie die U3-USB-Sticks

Übernehmen kannst ja die Configs 1:1

jein - wenn die Verzeichnisse unterschiedlich platziert sind (oder unterschiedliche Nomenklatur, vulgo: c:\...\htdocs vs. /srv/.../htdocs) oder einzelne Parameter eben unterschiedlich zu handeln sind (zB GW, hostname), kommt man im nullkommanix in Teufels Küche, dann hilft nur endlos aufdröseln (siehe /etc/apache/conf.d/) oder durch ausgefeilte Scripts + Environment parametrisieren ... (ich hab's mal geschafft durch konsequentes, lokales Shell-Environment zentral gelagerte und gewartete Shellscripts für unterschiedliche DB-Testserver universell zu halten, wobei Postgres-Tools sich wenigstens auch brav an die Env-Variablen halten, aber das ist nur der erste Schritt.)

Mit XML = klarer Semantik + universellen Werkzeugen wäre schon einiges gewonnen.

Wir verwenden vermehrt squeeze-backports weil in squeeze so viel veraltet ist.

http://packages.debian.org/squeeze-backports/ffmpeg

Einfach das ins sources.list:

deb http://backports.debian.org/debian-backports squeeze-backports main contrib non-free

Und dann bei veralteten Paketen explizit squeeze-backports durchsuchen:

apt-get -t squeeze-backports install ffmpeg

Das ffmpeg dort dürfte sogar neuer sein als das in wheezy.

ACTA wird Menschen töten | wikileaks.geizhals.org

"Wenn Behörden solche Trojaner in Auftrag geben und sie benutzen, handelt es sich um eine neue Form der Staatskriminalität" (Heribert Prantl, sueddeutsche.de)

"Ermittlungen in großen Wirtschaftsstrafsachen unterliegen wegen der Berichtspflichten der Ermittler zum Innen- und Justizministerium vollends dem politischen Würgegriff" (N. Haslhofer, ehem. StA)

Würd zum Konvertieren (also wirkliches re-encoden) kein FFMPEG (mehr) nehmen. Bei mir hat sich in Scripts (VDR Postrecord) http://handbrake.fr/ als wirklich optimale Lösung herauskristallisiert.

FFMPEG nehme ich nurmehr zum muxen der Streams.

Thou shalt not use the phrase "this should be simple" unless thou has confirmed it as such.

AFAIR benutzt Handbrake wiederum dieselben libs.

Das mag sein (ich habs mit dem beigelieferten Script kompiliert und nicht überall aufgepasst was er runterlädt). Bei mir gings auf jeden Fall auf Anhieb und total problemlos - was ich von FFmpeg ned immer behaupten könnte

.

Thou shalt not use the phrase "this should be simple" unless thou has confirmed it as such.

Bei mir gings auf jeden Fall auf Anhieb und total problemlos - was ich von
FFmpeg ned immer behaupten könnte

hängt meiner Erfahrung nach auch immer wieder davon ab, welche Plattform primär zur Entwicklung genutzt wurde.

Also für AVC Streams fand ich nix besseres als handbrake.fr.

Thou shalt not use the phrase "this should be simple" unless thou has confirmed it as such.

Also für AVC Streams fand ich nix besseres als handbrake.fr.

benutze es auch sehr gerne, wenn es nur um MPEG4 geht (=98% meiner Zwecke), ausserdem ist es am Mac sehr schnell, deutlich schneller als unter Win7 (weiß der Himmel, warum.....; ich weine VisualHub nach)

SUPER ist halt sehr praktisch, wenn es um re-packen geht, also von einem Container in einen anderen, oder Ton entfernen (nervt dafür aber mit der mühsamsten Download-Page und einem indiskutablen "stay-on-top+center"-Verhalten)

Ich benutze es in einem Script nach dem der VDR das Recording abgeschlossen hat. Dort laß ich dann das Mediainfo laufen um zu sehen ob es ein AVC Stream ist, wenn ja wird das angeworfen und encoded mir das ganze File (inkl. Pre und Post-Aufnahme) in ein mkv, das kannst mit den MKVTools wiederrum wunderbar und innerhalb von wenigen Sekunden schneiden.

Muß ich mal schaun welche Libs das Teil verwendet, jetzt hast mich neugierig gemacht

.

lg.

Thou shalt not use the phrase "this should be simple" unless thou has confirmed it as such.

MKV ist für mich kein Thema, nur .mp4 + .mov + h.264

Dieses Forum ist eine frei zugängliche Diskussionsplattform.
Der Betreiber übernimmt keine Verantwortung für den Inhalt der Beiträge und behält sich das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
Datenschutzerklärung