Woran auch immer das Problem gelegen hat: der ION hat den VP3, den auch die Desktop-Lösungen von NVidia haben. Der kann mehrere FullHD-Streams gleichzeitig bewältigen.
Beiträge von sneaker2
-
-
Mal so ins blaue geraten:
Die CPU ist zu langsam um das neu encodete Material abzuspielen,...Er will DXVA nutzen.
An und für sich sollten fast alle Einstellungen von x264 problemfrei auf dem ION laufen. Ist hier also ein Problem mit der Software. Habe aber keine Ahnung wie man es lösen könnte - kannst höchstens mal andere Grafiktreiber testen.
-
Ja, so wie Selur es gesagt hat, geht es. FFVideoSource() indexiert Dateien automatisch, mußt es also nicht manuell vorher machen.
-
Die neueste, experimentelle VirtualDub-Version unterstützt externe Encoder/Muxer, ist aber vermutlich nicht ganz trivial einzurichten. (Hab es selbst noch nicht getestet)
-
in RGB24, welches VirtualDub im "Full Processing Mode" verwendet
VirtualDub kann schon seit längerem auch ohne Zwischenschritt nach RGB filtern. -
Das ist Unsinn.
(Ich weiß übrigens gar nicht, ob oder ob nicht der VP7-Codec nur Mono-Threaded arbeitet, aber...) ... WENN ein Codec nur Monothreaded arbeitet, dann kannste an noch so vielen Knöpfen der Vdub-Config drehen: der Codec wird immer noch nur monothreaded arbeiten. Etwas anderes ist technisch gar nicht möglich.
Ist mit der aktuellen, experimentellen VirtualDub-Version nur noch halb richtig: Die kann einen Encoder mehrfach aufrufen. Soll aber nur mit Encodern gehen, die nur I-Frames setzen - habe es aber selbst nicht getestet. Also für XviD und x264 müßte weiterhin das bisherige gelten. (Wenn man nicht das Keyframe-Intervall auf 1 stellt)
-
Falls es das von LigH angesprochene Problem ist:
In den Optionen den Haken bei "Kopfdatenkompression bei Audio- und Videotracks standardmäßig ausschalten" setzen und anschließend neu muxen.
http://bunkus.org/videotools/mkv…val_compression -
Außerdem:
1.) "--min-keyint 24" am besten ganz weglassen, hat eigentlich nur Nachteile
2.) "--vbv-maxrate 40000" alleine wird ignoriert, Du mußt zusätzlich noch "--vbv-bufsize 30000" setzen.
3.) Sicher, daß Dein Quellmaterial "--fullrange on" rechtfertigt? Wenn ich mich recht erinnere, dann liefern DVDs und Blu-Rays nur TV range. -
Warum sollte der Buffer bei mkv Level 4.1 überlasten, aber nicht bei Level 4.1 Blu-Ray? Zumal wir hier von DVDs reden, die in diesem Fall die maximale Bitrate sogar noch wesentlich weiter herabsetzen. Und was hat die Länge einer GOP mit der Menge des Speichers zu tun? Es stimmt zwar, daß das Spulen mit längeren GOPs entsprechend langsamer wird - das ist aber allgemeingültig und nicht auf Blu-Ray-Player beschränkt. Ich habe noch von niemandem gelesen, der Probleme mit zehn Sekunden GOPs hatte.
-
Naja, darauf achten, daß Level 4.1 eingehalten wird, bedeutet für mich, daß man auf ref frames und Bitrate achten muß. Und beim x264cli beschränkt eine Levelangabe sogar tatsächlich die Anzahl der ref frames automatisch, solange man sie nicht manuell mit --ref überschreibt. Die meisten Blu-Ray-Einschränkungen kann man sich für mkv sparen - H.264 in Matroska ist nunmal keine Blu-Ray und damit auch nicht deren strengen Auflagen unterworfen.
-
Wenn ein Blu-Ray Player mkv beherrscht (was ein großer Teil der aktuellen Modelle auch tut), wird er auf jeden Fall auch H.264 unterstützen. Bei mpeg2 in mkv ist das nicht der Fall. Solange man sich an die Presets und Tunings von x264 hält, muß man eigentlich nur darauf achten, daß level 4.1 eingehalten wird, also die Anzahl der ref frames begrenzt bleibt und dann noch mit vbv-maxrate and vbv-bufsize die Bitrate begrenzen. Wobei hier wohl schon die Lesegeschwindigkeit der DVD-Laufwerke noch vor dem Chip im Player die Bitratenbegrenzung vorgibt. Empfohlen werden meist 15000 bit/s.
-
Seit V4.2 standardmäßig abschaltbar.
Seit 4.4.0.WD hat es wohl für den "Live" mit einer neuen Firmware gefixt, aber bei den "TV"-Modellen tut sich nichts...
-
Zu Frage 1: Ist hier vielleicht etwas verwirrend von "absolut" und "relativ" zu sprechen. Man sollte sich klarmachen, daß x264 immer mit absolut unkomprimierten Rohdaten gefüttert wird. Der Encoder hat keinen Schimmer davon, wie groß Deine Ursprungsdatei ist.
Frage 2: DGAVIndex hat Probleme mit Interlaced-Material. Wenn Die Tipps von Ligh (Cypheros TS-Doctor, FFmpegSource2) nicht funktionieren, könntest Du auch die neuen Tools von neuron2 ausprobien: DGDecNV für NVidia-Karten bzw. DGAVCDecDI, falls Du DiAVC besitzt. Eine für beide Werkzeuge gültige Lizenz kostet allerdings 15 US-Dollar.
-
Ein Build gibt es hier: http://x264.fushizen.eu/?p=291
Die Optionen sind in der fullhelp beschrieben. Ist allerdings noch nicht im offiziellen git. -
Ich denke mal, daß LigH mit seiner Vermutung richtig liegt, daß die header removal compression verwendet wurde, welche tsMuxer nicht unterstützt. Um das Problem zu lösen, muß die Datei entweder noch einmal mit mkvmerge gemuxt werden (dabei für alle Video- und Audio-Spuren Komprimierung=keine einstellen) oder - wie TiLT es verschlägt - die Spuren demuxt werden.
-
1.) Welche Version von mkvmerge nutzt Du?
2.) Funktioniert die ursprüngliche Datei, die noch keinen Untertitel enthält?Falls die Antworten auf die Fragen 1.) "4.2.0" und 2.) "ja" sein sollten, versuche folgendes:
Markiere im mkvmerge GUI die Videospur, klicke auf den Reiter "Zusatzoptionen" und wähle "Komprimierung" = "keine" aus. -
Bevor Du neuenkodierst noch ein Hinweis: mkvmerge hat in der Version 4.2.0 einen Fehler, der bewirkt, daß ass-Untertitel nicht gemuxt werden. Falls Du diese Version benutzt, teste einmal die neueste Beta, in der der Fehler behoben wurde: http://www.bunkus.org/videotools/mkv…7-301-setup.exe
-
Das liegt meine ich daran, daß die Knöpfe zwar für alle Arten von Tracks gleich beschriftet sind, aber in Wirklichkeit andere Methoden verwenden werden. Bei Untertiteln werden wohl keine Header entfernt, sondern die werden mit zlib komprimiert, und das schon seit Ewigkeiten. Die Header-Entfernung bei neuen Versionen und Audio-/Video-Tracks ist dagegen neu und hat mit der zlib-Kompression nichts zu tun.
-
Achtung, er encoded ja SD Material, da sollte das nicht so problematisch sein.
Ok, ein wirklich solch miserables Ergebnis wie HD sollte nicht dabei herauskommen. Werde es evtl. gleich mal bei SD-Material testen.
Die alte Version vom MEncoder hat das gleiche gute Ergebnis erziehlt, wie das direkte verwenden von x264.
Ein Fehler in mencoder? Das hatte ich gar nicht auf dem Schirm - gut, daß Du Dein Problem selbst lösen konntest...
-
Alles anzeigen
(1.)
Doch!
Sowohl im preset "veryslow" als auch in "placebo" wird ref auf 16 gesetzt. Hier ein Auszug aus der man-Page:
- veryslow:
--b-adapt 2 --bframes 8 --direct auto
--me umh --merange 24 --partitions all
--ref 16 --subme 10 --trellis 2
--rc-lookahead 60
- placebo:
--bframes 16 --b-adapt 2 --direct auto
--slow-firstpass --no-fast-pskip
--me tesa --merange 24 --partitions all
--rc-lookahead 60 --ref 16 --subme 10
--trellis 2Nein. Ich bin mit den Presets durchaus vertraut. Das x264cli nutzt folgende Priorität bei der Festlegung der Anzahl an refframes:
1. manuelles "--ref"
2. level
3. tune
4. preset
5. standard (=preset medium=3)Im vom mir weiter oben genannten Beispiel überschreibt also die Begrenzung durch "--level 4.1" die "--ref 16" Vorgabe vom Preset/Tuning.
Aber der MEncoder hat auch bei vbv-Werten um die 300000 keine sehenswerten Ergebnisse geliefert, deshalb mach ich nur noch das "crop" mit MEncoder und crf=0 und dann nochmal per "YUV4MPEG.y4m" direkt mit dem x264 und crf=23.
Selbst bei HD-Filmen sollten vbv-Werte von 30000 keinerlei sichtbare Verschlechterung erwirken. In der Praxis nutzt x264 nur selten solch eine hohe Bitrate, falls man auf eine Dateigröße kleiner Blu-Ray abziehlt.
Wie Selur bereits schrieb: maxrate wird nur dann benutzt, wenn man auch eine bufsize angibt. Und bei einer maxrate von nur 2128 wird man kein gutes Ergebnis erzielen können. Wie bereits gesagt: maxrate ist nicht dazu gedacht, die Dateigröße zu deckeln!
