[ALT] PDAExport 0.0.6b: Aufnahmen über OSD als AVI konvertieren (auch z.B. für PDAs o. iPods)

Natürlich!
Der Parameter war im Profil 1 nicht mit drin.
Zeile:

SERIE="1"

eingefügt und fertig ist der Fisch.

Nochmal herzlichen Dank für die tollen Scripte!
Du hast mich sehr glücklich gemacht.

Jetzt hätte ich mal eine Frage.
Mein mplayer (0.8.4) unter linvdr kann die Dateien, die mit Profil 1 (für PDA mpeg4 im AVI-Container bzw. als mp4 abgespeichert.) erstellt werden, nicht abspielen.
Das geht dann nur auf PDA bzw. PC.

Das Erstellen als mpeg4 geht aber ziemlich schnell (etwa Echtzeit) während das Profil 3 (HQ-Xvid) zwar auf dem mplayer abgespielt wird, aber bei der Konvertierung auf meinem auf 1000 MHz gebremsten Duron etwa 3-4-fach so lange als Echtzeit benötigt.

Jetzt hätte ich gerne eine Empfehlung für die Parameter, die eine wesentliche Verkleinerung der Dateien (auf ca. ein Drittel oder so) ergeben, unter mplayer 0.8.4 abspielbar sind und nicht wesentlich länger als maximal Echtzeit konvertieren.
Ziel ist eine erhebliche Erhöhung der Stundenkapazität.

Sollte es nur mit einer anderen mplayer-Version gehen, bräuchte ich eine Installationsanweisung für mein linvdr 0.6.

Danke

Never touch a running system!

Die Installation läuft stabil auf einem Xeatre. Handoptimiert by Lordjaxom himself.
Der vdr ist hier im täglichen Volleinsatz für die ganze Familie.
Sicherlich hätte ich gerne das ein oder andere Schmankerl aus einer neuen Version. Ich bin aber nicht bereit die Stabilität für eine Featuritis zu opfern.

Lieber wenn möglich das ein oder andere "dranfummeln", wobei ich alles selbst gemacht habe und es auch wieder rückgängig machen kann, weil ich genau weiss, was ich verändert habe.

Gesucht ist also eine Möglichkeit nur den mplayer zu aktualisieren.

**edit on ** Folgendes ist wohl bereits berücksichtigt. siehe 2 Postings weiter unten. Sorry. **edit off**

So meine Forschungen haben imho einen kleinen Denkfehler bei den Scripten für 16:9-Auflösungen aufgedeckt.

Die Aspect-Ratio wird korrekt gesetzt, aber eine Auflösung von 320x240 auf einem typischen PDA-Display macht bei echten 16:9-Sendungen eigentlich keinen Sinn!

Eine Konvertierung in 320x176 Pixel mit Aspect-Ratio 16:9 trifft es viel besser und weil die zur Verfügung stehende Bitrate auf weniger Pixel verteilt wird, ergibt sich auch ein besseres Bild!
Der PDA (namentlich der TCPMP) muss so nicht die überflüssigen Pixel interpolieren, was zu zusätzlicher Artefaktbildung führt.

Imho müsste also bei erkannter 16:9 Auflösung nicht nur die Aspect-Ratio anders gesetzt werden, sondern auch eine andere Zielauflösung verwendet werden.
Das würde zu einem zweiten Satz Parameter führen.

Für optimale Ergebnisse wird in der Literatur auf eine ganzzahlige Teilbarkeit der Auflösungen durch 16 verwiesen.
Also sollte für den Bereich PDA Auflösungen von 320x240 für 4:3 Sendungen und 320x176 für 16:9-Aufzeichnungen eine optimale Lösung darstellen.
Meine Versuche bestätigen das.

Jetzt stellt sich die Frage, ob Toxic-Tonic seine Scripte dahingehend ändern kann.
Afaik müsste das relativ einfach sein, weil ja nur die Aufruf-ffmpeg-Zeile entsprechend minimal anders zusammengesetzt sein müsste.
Im entsprechenden Profil müsste nur ein weiterer Parameter mit der Auflösung für erkannte 16:9-vdr-Dateien eingefügt werden. (ggf. auch eine zweite geringere Bitrate, weil ja die Auflösung auch ca. 1/3 geringer ist)

Eine weitere Anregung habe ich auch noch:
Im Logfile kann man leider nicht sehen, mit welchen Parametern der ffmpeg-Aufruf erfolgt.

Hi
ich habe mir diesen Thread mal wider überflogen.
Was hier (bzw. dem Paket) fehlt ist ein kleines Readme - wie man die Scripte in den VDR einbindet etc.
Ausserdem scheine ich Probleme mit meinem FFMPEG zu haben, da dieses nicht mit "--enable-mp3lame" compiliert wurde....

Gibt es eigentlich ein statisch compiliertes FFMPEG?

Gruß
Thorsten Gehrig

Zitat

Original von Toxic-Tonic
CouchPotato
Verstehe dein Problem nicht, mein Script passt doch die Auflösung basierend auf der 4/3-Auflösung an!
...

Öha!
Ich bin wohl einer Reihe von Aufnahmen auf den Leim gegangen, die falsch als 4:3 erkannt worden sind. Die Erkennung erfolgt wohl nur über den Anfang der Aufnahmen. Irgendwie sind die noad-Schnitte so erfolgt, dass noch ein 4:3 Schnipsel vorne dran war.

Ok, also mein Fehler! Sorry für die Aufregung!
Allerdings wird im Spezialfall in 320x180 konvertiert. Besser wäre 320x176 wegen der Teilbarkeit durch 16.

Der ffmpeg-Aufruf wird aber tatsächlich nicht mitgeloggt.

Afaik sind die modernen Kompressionsalgos (mpeg4, xvid, avc usw) auf 16x16 Pixel-Bereiche optimiert.
Das resultiert in einer "zusätzlichen" 16er-Reihe, die kodiert werden muss, um die im o.g. Beispiel 4 zusätzlichen Pixel darzustellen.
Also ein "Verschnitt" von 12 Pixeln*320 oder 75 Prozent Verschnitt in der 12. Reihe.
Darüber hinaus ist die "scharfe" Grenze, also benachbarte Werte mit krass abweichendem Inhalt bitratenintensiver zu kodieren, schwächt also zusätzlich die mögliche Kodierung des übrigen Bildes.

Wenn ich die Algo-Beschreibungen richtig verstanden habe, ist eine vom 16er-Raster abweichende Auflösung aus den oben genannten Umständen ziemlich schlecht und daher wenn möglich unbedingt zu vermeiden!

Hoffe, dass ich mit meiner Einschätzung nicht grob falsch liege, aber so habe ich die Darstellungen verstanden.

Hallo Toxic,

Das display ist ja in der regel (oder nicht !?) eher für 4:3 als für 16:9 ausgelegt, das bedeutet das man die bekannten schwarze streifen oben+unten bekommt. Man kann natürlich im tcpmp player zoomen, das schafft die cpu aber nicht immer so richtig flüssig.

Wie wäre es wenn man das ganze auch noch während der konvertierung beschneiden könnte, also vorher das "zoomen" erledigen ? ich glaube man nennt es cropping, bin aber nicht ganz sicher

Das kann bei 16:9 eine standard einstellung sein, bei 4:3 sollte man das irgendwie beinflußen können (verschiedene profile !?). Optimal wäre wenn man die schwarzen streifen in 4:3 irgendwie detecten könnte und dann beschneiden.

Gruß
viking

Cropping ist bei Cinemascope zu empfehlen (also noch breiter als hoch als 16 :9). Begründung siehe oben. (aufwendige Kodierung der Randbereiche)
Bei gegebener Bitrate führt Cropping der schwarzen Balken zu besserer Kodierung und damit zu weniger Artefakten.
Das Bildverhältnis auf dem Zielbildschirm (z.B. Pocket PC mit 320x240 ergo 4:3) muss natürlich erhalten werden. Sonst bekommt man fürchterliche Eierköpfe bzw. verliert links und rechts Bildinhalte. Wie früher bei RTL.

Optisch (Darstellung bezüglich Seitenverhältnis) macht es theoretisch keinen Unterschied, ob ich schwarze Balken mit kodiere oder sie durch den Player hinzufügen lassen muss, damit das Seitenverhältnis wieder stimmt.
Rechenintensiver ist natürlich das Einkodieren der schwarzen Balken, das also prinzipiell besser zu vermeiden wäre.
Die korrekten Werte durch ein Programm zu ermitteln ist aber nicht ganz trivial und dürfte durch ein Script nicht so ohne weiteres zu erledigen sein.

Was aber auch bei Toxic-Tonics Lösung ohne weiteres machbar ist, die Cropping-Parameter als Spezial-Parameter bereits in einem "Cinemasco-Profil" mitzugeben, die man vorher experimentell ermittelt hat.
Denn ein solcher Film (und es betrifft ja eigentlich nur Filme) kann ja bereits bei der Profilauswahl als solcher gekennzeichnet werden. Das ist dem Benutzer ja durchaus zuzumuten, oder nicht?

Wer passende Werte für die gängigen Formate ermittelt hat, kann diese ja hier posten, damit Toxic-Tonic diese in zukünftigen Versionen als Muster-Profil mitliefern kann.

Viel schlimmer finde ich, dass z.B. Pro7 und SAT1 immer noch die meisten Filme in 4:3 mit großen Balken senden. RTL hat ja lobenswerterweise endlich auf 16:9 umgestellt (mit nur kleinen Balken bzw. ohne).

Zitat

Original von Toxic-Tonic
Meinst du das 16x9 Bild so weit zoomen, bis oben und unten die Balken weg sind?

Na ja, ich denke mal nicht alles aber evt. doch. Hängt evt. von dem film/der serie ab.

Habe zwar noch nicht ganz verstanden was du eingebaut hast aber aber wenn man einstellen kann das flexibel "gezoomt" werden kann dann kann man ja ausprobieren wie viel zu verschmerzen ist ...

Wenn jemand schon werte ermitelt hat dann her damit

Evt. kann man ja vorsehen das wenn text A vorkommt dann profil A nehmen und wenn B dann Profil B.

also z.b. einnen configfile mit dem inhalt :

CSI_Miami
Movies
...

Und wenn dann "CSI_Miami" im namen vorkommt dann schauen ob es einen profil mit dem namen pdaexport.conf.CSI_Miami gibt und diesen dann verwenden.

Alternativ config datei :
CSI_Miami:pdaexport.conf.4-3
Movies:pdaexport.conf.16-9

und dann den zweiten teil nach dem : als dateiname für den profil nehmen. Die zweite lösung gefällt mir besser Die selbe serie ist ja in der regel gleich kodiert.

Gruß
Viking

Zitat

Original von Toxic-Tonic
... könntet ihr mal dübergucken, ob mann alles versteht ...

5 Euro in die Chauvi-Kasse!