Beiträge von Limit

Als Linux-User bin ich natürlich ein Fan von Config-Files im Home-Dir. Der Vorteil daran ist, dass diese dann separiert von den Programme und dem OS liegen. Wenn man eine eigene Partition dafür benutzt, hat man nach einer OS-Neuinstallation direkt die alte Config am laufen. Userdaten beim IRC/ICQ-Client eintragen, Kontodaten + eMails für Thunderbrid konfigurieren, Lesezeichen bei Firefox, Sender und Daten beim TV-Browser, die DVB Senderliste für szap und natürlich die ganzen Einstellungen für Themes, Töne usw.

Das macht irgendwie keinen Sinn. CRF sollte in bei einem festen Wert in etwa immer die gleiche Qualität abliefern, d.h. bei einem detail- und rauscharmen Quelle, wird die Bitrate niedrig, bei vielen Details und/oder Rauschen wird die Bitrate hoch ausfallen.

Von daher würde ich eher einen festen CRF-Wert nehmen. Alternativ nimm einfach die Xvid-Bitrate und zieh davon je nach eigenem Gefühl 20-30% ab und nutze das Ergebnis für ein 2pass x264 Encoding.

Selbst mal ein paar Werte ausprobieren ist sicher die beste Methode. Ich würde bei Werten um 20 herum anfangen. Persönlich nehme ich meist crf22. Bei deinen Vorgaben würde ich aber eher eine Nummer niedriger ansetzen (niedrigerer Ratefactor => höhere Qualität).

Vostro und Latitude haben grundsätzlich matte (Anti-Glare) Displays. Was die Seite betrifft, ja, die ist nicht gerade Übersichtlich.

Ich würde mir mal die Dell Vostro Serie anschauen. Die haben ein ganz ordentliches Preis-/Leistungsverhältnis. Bei besserer Ausstattung wie das Alternate Gerät (bissl mehr Takt, 3GB Speicher, 250GB HDD, 1440x900er 15" Display) kostet es inkl. MwSt exkl. Versand etwa ein Hunderter weniger.

Zitat von LoRd_MuldeR

Über den Container würde ich mir nich all zu viele Sorgen machen, da man bei Bedarf ja jederzeit verlustfrei re-muxen kann.
MKV scheint zwar "im Netz" recht beliebt zu sein, gerade bei "Hardware" Playern wird man aber auf absehbare Zeit nicht um MP4 und M2TS herum kommen.
Letztendlich wird man den Container abhängig davon wählen müssen, was der jeweilige Player schluckt...

Generell gebe ich dir mit dem Remuxen Recht. Allerdings denke ich, dass zukünftige Player durchaus MKV integrieren werden. Hauptsächlich weil DivX-HD darauf aufbauen wird und es mittlerweile auch ein paar Chips gibt, die das Format in Hardware gegossen haben. MP4 hat ja den Haken, dass es viele Codecs nicht nativ unterstützt, vor allem die bei Blu-Ray/HDTV häufig genutzen DTS bzw. AC-3.

Hab mal deine Settings getestet. Ohne das i4x4 bei den x264encopts und mit einer inputfile statt null funktioniert's bei mir.

Übrigens, was machst du mit MP4Box? Wieso nimmst du nicht gleich mkvmerge?

Ich würde übrigens faac statt lame empfehlen. Hat bei gleicher Bitrate besser Qualität. StandAlone Geräte, die AVC dekodieren können, können in der allermeisten Fällen auch AAC dekodieren.

Es wäre gut, wenn du dein genaues Vorgehen beschreiben würdest.

Mencoder benutzt ja die gleichen Bibliotheken wie Mplayer um Inputvideos zu dekodieren. x264 dagegen nimmt dagegen nur bereits dekodiertes Material als Input (zumindest die Linux Version).

Solltest du also versucht haben die .ts Datei direkt mit x264 zu öffnen, ist es klar, dass das nicht funktioniert. Du brauchst dafür einen "Zuspieler".

Es gibt da verschiedene Varianten.
1) Du benutzt mencoder / mplayer und leitest deren output über eine Pipe direkt zu x264.
2) Du benutzt wine + avs2yuv und leitest deren output über eine Pipe direkt zu x264. Du musst dann aber auch noch entsprechende Decoder für Windows installieren, z.B. ffmpeg. Das hat den Vorteil, dass du die allermeisten Avisynth Filter benutzen könntest.
3) Du benutzt statt avs2yuv + Linux x264 Build gleich die Windows x264 Version mit AVS-Untersütztung. Das hat den Vorteil, dass die Windows x264 Builds meistens schneller sind als die Builds der gängigen Linux Distributionen. Wenn du selbst compilierst, fällt das Argument natürlich weg.

Ich benutze letztere Methode, da ich bis jetzt noch keine brauchbare Möglichkeit gefunden habe mit mencoder/mplayer gescheit zu schneiden. Falls da wer etwas weiß, bin ich offen für Tipps.

Zitat von truthy

dass ich nicht die gecroppte auflösung zb 720x304 beibehalte sondern auch wieder den beschnittenen inhalt auf 720x576 anamorph encodiere

Zitat von SethGecko

Ich denk in dem Punkt hast Du den Post falsch verstande bzw es wurde sich nicht klar ausgedrückt. Es wurde wohl gemeint, das das gecroppte Material dann nicht durch den Resizer "gejagt" wird, sondern eben die gecroppte Auflösung ohne Resizing verwendet wird.

ICh würde grds. sagen, wenn die Zielgröße und SAP Kompatibiltät beim Encode keine Rolle spielt, dann die sollte die größte Auflösung gewählt werden die nach Cropping erzielt werden kann.

Ich denke, ich hab es schon richtig verstanden. Falls doch nicht, wiederrufe ich alles und schließe mich deiner Meinung an ;D

Gibt es DVBViewer auch für Linux? Falls ja und falls DVBViewer eine passende Schnittstelle anbietet, könnt ich was basteln.

Prinzipiell kann das Skript auf verschiedenen Plattformen benutzt werden, sofern es für die Plattform Python und die benötigten Tools (szap/dvbstreamer/TV-Browser oder etwas vergleichbares) gibt.

Zitat von truthy

mhm, ich meinte damit (auch Filme mit 2.35/1.85 AR) auch wenn ich einen DVDRip mache mit Xvid im AVI-Container nicht MPEG-2, dass ich nicht die gecroppte auflösung zb 720x304 beibehalte sondern auch wieder den beschnittenen inhalt auf 720x576 anamorph encodiere

Du willst das Video von 304 auf 576 Zeilen aufblasen? Wieso? Das würde allenfalls etwas bringen, wenn du irgendwelchen hochkomplexen Upscaler benutzen wolltest, aber selbst dann wäre der Unterschied wohl kaum den zusätzlichen Speicherplatz wert. Anders sieht das natürlich aus, wenn du eine HD-Quelle hast, die von Haus aus genügend Zeilen besitzt, selbst bei 2.35 AR. Da könnte man sich überlegen so etwas wie PAR 1,88 zu benutzen, wobei sich dann wiederum die Frage stellt auf welchem Display man das ganze ohne Schwarze Ränder anschauen kann. Aus dem gleichen Grund haben vermutlich auch die DVD-Entwickler keine PARs für breitere Formate als 16/9 vorgesehen.

Generell hätte ich gesagt, immer soviel Auflösung wie möglich ohne Upscaling zu betreiben. Für höchste Qualität einfach die Zeilenzahl vom Original behalten und dann die PAR so wählen, dass es vom AR hinhaut. Bei 1,85 / 2.35 AR wird das auf einem 16/9 oder 4/3 Bildschirm zwar kaum Vorteile gegenüber der Variante mit schwarze Balken auf 16/9 und dann anamorph geben, aber man weiß ja nie, vielleicht hat man später mal ein 2.35 AR TV/Monitor.

Hallo zusammen,

ich hatte mal wieder zuviel Zeit und habe daher beschlossen mein altes Aufnahmeskript über Bord zu werfen und ein (fast) komplett neues zu entwerfen.

Zu dem Skript:
DVBRec besteht aus einem Python-Skript und einer kleinen TV-Browser Gerätedatei um direkt aus dem TV-Browser Aufnahmen zu programmieren bzw. wieder zu entfernen, wie man es aus verschiedenen EPG-Anwendungen kennt. Als zusätzliches Feature unterstützt das Skript auch das gleichzeitige Aufnehmen mehrerer Sender mit einer einzigen DVB-Karte, sofern die Sender auf der gleichen Frequenz senden.

Voraussetzungen:
- eine funktionierende DVB-Karte
- Channelliste im zap Format
- Cron
- szap (dvb-utils)
- dvbstream

Die Software ist noch recht frisch, also nicht wundern, wenn sie noch nicht 100% fehlerfrei ist, auch wenn ich sie schon ein wenig getestet habe.

Aus dem Geschreibe überhaupt etwas sinnvolles herauszulesen ist schon eine kleine Kunst.

Ich denke nicht, dass es an Nero liegt. Welche Mediacode hat denn der Rohling? Ich würde am ehesten drauf tippen, dass der Pio einfach nicht mit der Rohlingssorte zurecht kommt.

Es gibt eine neue Fimrware von 11/2008, Version 1.22

Änderungen:
Format erroe problem on WindowsVista DVD-RAM Full Format are solved.
DVD-R 16X Writability has improved.
DVD+R 16X Writability has improved.

Download: siehe obigen Post.

Rohling: Maxell DVD-R 16x
MID: Ritek F1
Brenner: Plextor PX-712A 1.09 / Pioneer DVR-215 1.18
Brenngeschwindigkeit: 8x / 8x / 12x / 16x
Scanner: Plextor PX-712A 1.09
Scanngeschwindigkeit: 2x

Das ist wohl einer wenigen Rohlinge, die sich mit dem Plextor besser vertragen als mit dem Pio. PIF sind bei beiden ok für einen 13c-Rohling. Aber bei mehr als 8x kann man die Rohlinge vergessen. Die Rohlinge aus der alten Spindel waren da wesentlich besser.

Medium : SONY DVD-R 16x made in India
MiD : Sony16D1
Brenner : Plextor PX-712A 1.09 / Pioneer DVR-215 1.18
Brennspeed : 8x / 16x
Scanner : Plextor PX-712A 1.09
Scanspeed : 2x

Mal wieder gute Ergebnisse mit den Sonys.

Ich denke, es liegt auch daran, dass es keine wirklich neuen Rohlingssorten oder Brenner mehr gibt. Bei altbekannten Brenner und Rohlingssorten ist der Informationsbedarf nicht sonderlich groß. Am interessantesten sind dann noch die Sonderangebote bei den großen Rohlingshändlern, die es immer mal wieder gibt. Bei den Preisen der "Markenrohlinge" lohnen sich solche Experimente finanziell allerdings kaum noch.

Zitat von Kruemel2

11. Frage: Im PARanoia-Skript steht eigentlich "dgdecode_mpeg2source("....d2v")". Muß ich das "dgdecode_mpeg2source" auch in mein Skript übernehmen? Sonst schreibe ich immer nur "Mpeg2Source" ohne "dgdecode" davor.

Musst du in der Regel nicht, allerdings kenne ich PARanoia nicht. Ich benutze das normale DGMpgDec-Packet und schreibe die Scripte selbst und da benutz ich ebenfalls immer mpeg2source. Evtl. benutzt PARanoia unterschiedliche Mpeg2 Importfilter und muss daher die Funktionsnamen ändern, aber das ist nur eine Vermutung.

Zitat von Kruemel2

Mein eigentliches Anliegen aber war ja, eine AVI-Datei (H.264) von 16:9 nach 4:3-letterboxed umzuwandeln.

Meine Frage zum Schluß: Muß ich die AVI unbedingt vorher nach MPEG2 umwandeln und dann wie oben beschrieben vorgehen? Möchte natürlich so wenig Qualitätsverlust wie möglich.

Musst du natürlich nicht. Du kannst sie auch direkt verarbeiten, es geht sogar einfacher.

AviSource("video.avi")
filter()
filter2()

Einfach den Dateinamen und Filter anpassen.

Zitat von MaxPower99

Die Videos sollen möglichst klein sein, aber auf eine bestimmte Dateigröße kommt es mir nicht an (bei Actionszenen soll genügend Bitrate sein, bei ruhigen Szenen soll nichts verschwendet werden).
MfG

Du könntest im CRF-Modus kodieren. Du gibst praktisch nur die "Qualität" vor, die du haben willst. Der Encoder entscheidet dann je nach Quelle, wieviel Bitrate er braucht um die Qualität zu erreichen. Die Dateigrößen können dabei allerdings sehr schwanken. Ich habe bei manchen Serien, die ich aufnehme teilweise Dateigrößen zwischen ~240mb und ~600mb und zwar bei der gleichen Serie und Staffel.

Ansonsten würde ich einfach ein paar Tests machen mit vorgegebenen Bitraten. Mit der Zeit bekommt man ein ungefähres Gefühl dafür, wieviel man braucht.