Beiträge von De-M-oN

Die 64bit Version wird schneller sein, kann aber auch weniger Videoformate.

Youtube hat die Qualitäten reduziert. 1440p nur noch 10 mbit, statt 15mbit

4k nur noch 15 mbit statt CRF/CQ.

Die Videos sehen somit wieder alle scheiße aus.

Zitat von sem

Spiel im Kompatiblitätsmodus gestartet

Bei 'nem frisch erschienenem Spiel erscheint mir das unlogisch

Ist das für Livestreams oder was hindert dich dran die gespeicherte Aufnahme der Kamera zu nehmen?

DirectInput haben auch noch heutige Spiele und es ist bei jedem Spiel traurig, welches kein DirectInput kann, nämlich diese, die nur 360 / One Gamepad unterstützen aus diesem Grund.
Kein DirectInput = Alle Lenkräder nicht nutzbar.
DirectInput ist zudem viel besser, da es viel mehr Achsen, Buttons usw unterstützt..

Oder die Gigabyte Extreme Gaming. Hochzufrieden und ziemlich gleichauf mit zotac. Zotac hatte lediglich minimal mehr VRAM Takt, kann man aber mit MSI Afterburner ja nachregeln.

Zitat von Sagaras

Ich würde dir vorschlagen du liest erst mal was es mit DC und DCT auf sich hat, und warum man da auch 9 und 11 Bit nutzen kann. Das hat nix mit der Bittiefe vom Encoder zu tun. Du kannst genausogut die DC Präzision beim 8Bit Encoder auf 9bit stellen. Dein Video wird dadurch trotzdem immer noch 8Bit anzeigen, aber die Präzision ist höher.
Das ist wie als würdest du dem Video mehr Schärfe verleihen.

Und genau das schrieb ich doch auch.......

Zitat von Sagaras

Jedoch ist auch der Farbraum höher.

Sonst würde es auch kein 10Bit RGB existieren, wenn es nur eine YUV basierende DC Präzisions Steigerung ist. Siehe UtVideo.
DC und DCT sind für die Verlustbehaftete Encodierung hauptsächlich interessant.

Nein der ist nicht höher...
Es ist immer noch normales YV12 und nichts weiter

Bei UTVideo ist es höher, weil dort nicht die DC Präzision gemeint ist, sondern wirklich 10 bit pro farbkanal.

Zitat von Sagaras

Du musst das unbedingt mal trennen. Farbtiefe und DC/DCT Präzision sind 2 verschiedene Dinge.

Das hast du damals nich gekonnt und ich hab dich daraufhin korrigiert und jetzt willst du mich belehren.
over and out.

Zitat von Sagaras

Bei UTVideo gibt es aber 10Bit RGB. Und die beschreiben in der Tat die Farbtiefe.

Ja. Ich meinte ja auch nicht UTVideo...
_
Jo. Nur schrieb ich nichts von RGB.

http://forum.doom9.org/showthread.php?t=158991

Der Thread behandelt das Thema sehr gut.

Zitat von Sagaras

In der Videoverarbeitung später nutzt man eine 8zu10 Bit Konvertierung aus (z.B.: Aufnahme -> x264_10bit) um A) die Dateigröße damit etwas zu senken und B) Banding zu reduzieren.
Bei einer Aufnahme mit 10Bit verschleuderst du aber Performance dabei.

Die 10bit beim 10bit x264 encoder beziehen sich jedoch auf die DC Präzision, nicht auf die Farbkanäle. Die sind weiterhin 8bit pro kanal minus chroma downsampling.

--fps 30
tuts auch. Ist schneller eingetippt ;D

Du hast doch schon selber ne fps eingetragen bei x264

Warum stellst du in x264vfw nicht ebenfalls 30fps ein? Dadurch machste dein Video sogar asynchron auf Dauer.

Und mit 1080p kommst du auf yt nich weit.

Mind. 2048x1152 sonst wird das eh nichts

Dann lass die vorigen doch re-encoden.

Naja 100% Rennen halt. Also so lange wie eben ein echtes F1 Rennen geht. Also 1 3/4 std bis 2 std je nach strecke.

Wäre ja etwas unschön so'n Rennen in x Teile zu schneiden. Da find ich's schon sehr sinnvoll das Rennen in einem Stück gucken zu können.

Zitat von strohi

Rennspiele würde ich maximal 20 Minuten am besten finden

Und bei einem F1 2016 100% Rennen?

Zitat von Sagaras

Das ist recht uninteressant und hat keine Relevanz auf die Qualität der Bilder.

Doch hat es:

Penalties for slice-based threading:
Each slice adds some bitrate (or equivalently reduces quality), for a variety of reasons: the slice header costs some bits, cabac contexts are reset, mvs and intra samples can't be predicted across the slice boundary.
In CBR mode, multiple slices encode simultaneously, thus increasing the maximum misprediction possible with VBV.
Some parts of the encoder are serial, so it doesn't scale well with lots of cpus.
Some numbers on penalties for slicing:
Tested at 720p with 45 slices (one per mb row) to maximize the total cost for easy measurement. Averaged over 4 movies at crf20 and crf30. Total cost: +30% bitrate at constant psnr.
I enabled the various components of slicing one at a time, and measured the portion of that cost they contribute:
* 34% intra prediction
* 25% redundant slice headers, nal headers, and rounding to whole bytes
* 16% mv prediction
* 16% reset cabac contexts
* 6% deblocking between slices (you don't strictly have to turn this off just for standard compliance, but you do if you want to use slices for decoder multithreading)
* 2% cabac neighbors (cbp, skip, etc)
The proportional cost of redundant headers should certainly depend on bitrate (since the header size is constant and everything else depends on bitrate). Deblocking should too (due to varing deblock strength).
But none of the proportions should depend strongly on the number of slices: some are triggered per slice while some are triggered per macroblock-that's-on-the-edge-of-a-slice, but as long as there's no more than 1 slice per row, the relative frequency of those two conditions is determined solely by the image width.

Und da sie völlig unnötig sind, ist jeder kleinste Verlust unnötig. Der Verlust wird einem je nach Bitrate nich vom Hocker hauen, aber es ist dennoch Verlust.

Zitat von MegaJaniX

Ich soll also jetzt konstante Bitraten benutzen?

Wenn du den max wert auf max machst, limitierst du den peak nich mehr.

Je mehr du den max wert an den schnittwert annäherst, desto mehr rückst du jedoch einer konstanten bitrate näher. Und genau das wollen wir ja eben nich.

Slices schonmal nich nehmen, statt 4 auf 1, 0 wäre besser, aber geht ja bei dem programm nich
Keine Max Bitrate definieren. Level auf High und dann maximalwert einstellen, da auch dieses Feld bei dem Programm nich deaktivierbar ist.
Schnittbitrate würde ich locker aufs 3-fache anheben.
Die Auflösung sollte mind. 2048x1152 wenn auf Youtube von dem Video noch was über bleiben soll.
Ein besserer Encoder wie x264 wäre anzuraten.

MagicYUV natürlich. Farbsampling nach Wunsch.

würde ich trotzdem nich wollen, 1,25 vs 1,30 ist immer nochn ordentlicher Unterschied. Außerdem ist Auto viel zu variabel. Konstante Spannung ist auf Dauer auch besser für Elektronik.