Muß es "handgemacht" sein? das Tool "MSU VQMT" vergleicht einen Stream mit bis zu 2 anderen. Die Dateien werden per AviSynth übergeben, so daß sich verschiedene Filter einbauen lassen. Und es stehen verschiedenste Metriken zur Verfügung.
Gruß
akapuma
Hallo,
ich habe einen Film per DVB-S aufgenommen. Dieser hat durchgehend eine Auflösung von 720 x 576 Punkten. Ich möchte ihn in x264 codieren, und in eine mkv packen.
Der Anfang der Aufnahme (= der eigentliche Film) ist ein 4:3-Film. Das Ende (Erläuterungen zum Film) ist hingegen 16:9.
Ist mein Vorhaben überhaupt sinnvoll möglich? Kann ich in einer mkv das AR ändern?
Gruß
akapuma
Hatte jemand bisher irgendwelche Probleme irgendeiner Form mit einem MPEG-2 in einem mkv?
Was sollte es für Probleme geben? Für mkv steht ein aktueller gepflegter Muxer zur Verfügung. MPEG2-Muxer sind nur altes Zeugs. Und MKV's spielt an sich jeder Player ab, egal ob Windows oder Android.
Gruß
akapuma
Ich habe auch so eine kleine Überwachungskamera, allerdings (wie von Rübezahl erwähnt) Bewegungsgetriggert. Egal - man hat jede Menge Bilder, und möchte diese gern aneinander hängen. Ich habe das mit MakeAVI gemacht. Simpel und gut für diesen Zweck.
gruß
akapuma
Die Sicherheitslücke, von der LigH hier berichtete, wurde in SeaMonkey 2.29.1 behoben, siehe hier und hier.
Gruß
akapuma
Ausgestattet ist er mit ARM-SoC i.MX6 als Quad-Core der etwas schneller als ein Raspberry Pi arbeitet und so gängige aktuelle Videos in HD-Auflösung flüssig abspielt,
Man sollte darauf achten, daß genügend CPU-Power da ist. Meist erfolgt die Decodierung nämlich nur per GPU. Und bei Decodieraufgaben, die nicht in's Schema passen, versagt die GPU, z.B. bei 10-bit codierten Videos (und hier meine ich nur SD). Dann ist eine schnelle CPU gefragt, die aber Geräte der Raspberry-Klasse nicht haben.
Gruß
akapuma
Nachdem Seamonkey 2.27 (Vollversion von FireFox 30) nicht erscheinen konnte, wurde Seamonkey 2.26.1 herausgebracht - siehe mein Post zuvor.
Auch mit Seamonkey 2.28 (Vollversion von FireFox 31) gab es Probleme, so daß diese Version einfach übersprungen wurde.
Jetzt ist Seamonkey 2.29 (Vollversion von FireFox 32) erschienen. Absichtlich etwa eine Woche später als FireFox 32, um mögliche Bugs sofort fixen zu können. Seamonkey 2.29
Die "Änderungen"-Seite ist noch nicht ganz fertig, kann aber über den Link zuvor abgefragt werden.
Gruß
akapuma
PC-Netzteile werden nach der EN 60950-1 gebaut. Ich werde morgen mal reingucken, was da drinsteht (ich glaube aber, es gibt da keine Anforderung).
Wie ich schon schrieb, es darf nach Herausziehen des Steckers nichts an den Steckerstiften sein. Innere Elkos dürfen geladen bleiben:
Die Einrichtungen müssen so bemessen und gebaut sein (en: so designed), dass an einer dem Benutzer zugänglichen äußeren Trennstelle von einem Versorgungsstromkreis die Gefahr eines elektrischen Schlags (gefährlichen Körperstroms) infolge gespeicherter Ladung aus Kondensatoren, die in der Einrichtung angeschlossen sind, möglichst gering bleibt.
Gruß
akapuma
Es gibt doch meines Wissens auch immer(? Pflicht?) parallel zu den Kondensatoren geschaltete Entladewiderstände oder -schaltungen, die dafür sorgen sollen, dass nach einer Abschaltung des Netzteils die Elkos entladen werden... oder?
Es gibt keine allgemeine Regel für Entladewiderstände. Verschiedene Geräte werden nach verschiedenen Normen gebaut, und jede Norm hält es anders. Allgemein sind diese Entladewiderstände nur Pflicht, wenn der Kondensator durch den Benutzer berührbar ist, also z.B. direkt an den Steckerstiften liegen würde. Die sind nämlich (nach Herausziehen des Steckers) berührbar. Da liegen dieser Kondensatoren aber nicht.
PC-Netzteile werden nach der EN 60950-1 gebaut. Ich werde morgen mal reingucken, was da drinsteht (ich glaube aber, es gibt da keine Anforderung).
Gruß
akapuma
Die auf mehrere 100V ausgelegten Elkos sind es meines Wissens aber seltener, als die für Spannungen im zweistelligen Volt-Bereich bestimmten.
Diese Kondensatoren (Nennspannung meist 350V, 400V oder 450V) sind die wichtigsten im Netzteil. Der DC-Ausgang muß permanent Energie abgeben. Das 50-Hz-Wechselstromnetz stellt aber nur im 100Hz-Sinus-"Takt" Energie zur Verfügung. Diese Elkos dienen zum Puffern der Lücken dazwischen. Gebräuchlich sind 2 Varianten:
Alte PC-Netzteile (passive oder garkeine PFC, kein Weitbereichseingang, fest 230V oder 115/2330V umschaltbar):
Hier wird der Kondensator auf maximal Wurzel 2 x Netzspannung = 325V (bei 230V) aufgeladen.
Problem: Die Netzspannung darf im Bereich 230V +10% -15% liegen. Die gespeicherte Energiemenge ist mit 1/2 x C x U² aber quadratisch von der Versorgungsspannung abhängig, und damit sehr von der tatsächlich vorhandenen Netzspannung. Das macht größere Kondensatoren erforderlich.
Neue PC-Netzteile (aktive PFC, oft mit Weitbereichseingang):
Im Prinzip handelt es sich um 2 Schaltregler. Der erste ist ein nicht trennender AC/DC-Wandler, der die Kondensatoren unabhängig von der Netzspannung auf etwa 400V aufläd.
Der zweite Schaltregler ist dann ein DC/DC-Wandler, der aus den 400V die geforderte Kleinspannung macht, und zwar vom Netz isoliert (Schutzkleinspannung SELV).
Die Kondensatoren sind mit allergrößter Vorsicht zu behandeln! Die Spannung kann noch viele viele Stunden aufrecht erhalten bleiben, und ist gefährlich!
Gruß
akapuma
Gegen wabbernde Wände bzw. Flecken (Banding) gehe ich wie folgt vor:
Codec:
- Codec: die 10-bit-Variante soll hier etwas besser sein
- Codec-Einstellungen die erste: Ich verwende die Einstellungen "--no-fast-pskip" und "--no-dct-decimate", weil diese mal in Verdacht standen, die genannten Probleme zu verursachen. Ob es dadurch wirklich besser wird, oder ob ich mir das nur einbilde, weiß ich nicht. Versuch macht klug.
- Codec-Einstellungen die zweite: AQ=1 habe ich immer verwendet. AQ=2 ist vielleicht einen Versuch wert.
Problem selbst durch Bearbeitung verursacht:
Mein Quellmaterial ist DVB-S. Die Filme sind mir oft zu dunkel. Ich helle sie dann mit HDRAGC auf, wobei ich verschiedene "Stärken" anwende (HDRAGC wird anteilig zu 25%, 50% oder 100% angewendet):
25%: merge(last,last.hdragc(),0.25)
50%: merge(last,last.hdragc(),0.5)
100%: hdragc()
Bei "flachen" Filmen bekommt man hierduch aber genau den Effekt, daß eine Wand zwar heller, aber fleckig wird. In diesem Fall lasse ich den Film lieber dunker - das ist dann das kleinere Übel.
Problem war schon vorher da:
Es gibt so viele Spartensender, die Filme mit kleinster Bitrate und mit geringer Qualität ausstrahlen. Hier ist das Material schon vorher fehlerhaft. Mit diesem Filter bekommt man das Problem recht gut in den Griff:
f3kdb(dither_algo=2)
Da der Film allerdings etwas kontrastärmer wird, empfiehlt sich die Anwendung nur, wenn es wirklich nötig ist.
Gruß
akapuma
das material hatte viel korn und ohne aq fing es in dunklen szenen an unschön zu wabern.
Gegen Wabbern hilft auch der 10-Bit-Encoder (etwas).
Gruß
akapuma
In "Brother Johns Encodingwissen" steht zu AQ:
"Der Standardwert 1 ist die sichere Wahl. 2 sollte zwar keine Probleme verursachen, ist aber noch zu neu, um endgültige Aussagen zu treffen."
und im verlinkten mewiki steht "experimental". Deshalb hatte ich mich immer vor AQ=2 gescheut. Wie sieht's aus? Kann man diese Einstellung bedenkenlos nehmen? Oder nur, wenn es zwingend nötig ist?
Gruß
akapuma
Bezüglich Trim-Befehle:
Ich schneide seit Jahren meine DVB-Aufnahmen mit MPEG2Schnitt, und zwar framegenau. Ich speichere jedoch nur die Audiodatei und die Projektdatei. In der Projektdatei stehen die Schnitte drin. Diese wandle ich mit einem kleinen Hilfsprogramm (agkpCUT) automatisch ein Trim-Befehle um, und zwar so:
Projektdatei (Stunden : Minuten: Sekunden: Frame):
Schnittpunktname=" 01 01 -- 00:01:45.21 -- 00:08:13.24"
Schnittpunktname=" 01 01 -- 00:16:44.06 -- 00:21:50.23"
Schnittpunktname=" 01 01 -- 00:30:21.04 -- 00:39:48.11"
Schnittpunktname=" 01 01 -- 00:51:31.10 -- 00:58:23.23"
Schnittpunktname=" 01 01 -- 01:09:15.08 -- 01:14:51.22"
Sieht dann so aus:
trim(2646,12349)+trim(25106,32773)+trim(45529,59711)+trim(77285,87598)+trim(103883,112297)
Vielleicht hilft dieses Beispiel bei der Umrechnung.
Gruß
akapuma
In diesem Fall versuch mal, ob Alt+Num:0228 (wichtig: mit null!) funktioniert.
Nein, es kommt auch ein "ë".
Ev.umstellen auf Schweizer Tastatur.
Auch wieder ein "ë".
Nächster Versuch: an einem anderen Rechner (Win7-32) funktioniert das "ä". Da habe ich nun meine CMD-Datei geschrieben, umd beim Start wird die Textmeldung "dauert etwas länger" richtig angezeigt.
Dann: Start der cmd-Datei am Win7-64-Rechner. Und wieder ein "ë" auf dem Bildschirm.
Es sei denn, du hast eine OEM-Zeichensatz-Schriftart. Die Wahl der Schrift kann auch entscheiden, v.a. bei Pixelschriften (wie Uwe Siebers DosFonts).
Und das war's. Bei den Eigenschaften des Fensters war "Rasterschriftart" eingestellt. Mit "Consolas" oder "Lucida Console" (ich habe nur diese 3 Möglichkeiten) klappt es prima -das kleine ä ist da.
Dankeschön.
Gruß
akapuma
Hallo,
ich habe folgendes Problemchen. Ich habe Win7-64, und öffne mit "CMD" eine DOS-BOX. Dort gebe ich "CHCP" ein, und erfahre, daß die Codepage 850 genutzt wird. Ich möchte ein kleines "ä" eingeben. Das kleine "ä" sollte "84" (hex) = "132" (dez) sein. Gebe ich nun "Alt 132" ein, dann erhalte ich allerdings ein "ë" statt einem "ä".
Was mache ich falsch? Ich komme einfach nicht dahinter...
Gruß
akapuma
Und wenn der erste Durchlauf so schnell ist, dass der Encoder vor allem aufs Frameserving wartet, wäre "keine Vollauslastung" auch keine Überraschung.
Hier wäre dann Multithreading angesagt. Wenn ich beispielsweise QTGMC benutze, ist Multithreading Pflicht. Sonst nimmt Avisynth einen Kern zu 100%, währen x264 die anderen 3 Kerne nicht auslasten kann, weil einfach nicht genug Arbeit da ist. Man kann es erkennen, wenn man sich anguckt, welche Prozesse welchen Lastanteil haben.
Gruß
akapuma
Hätten neuere Dekoder wir z.B. L-SMASH denn Vorteile gegenüber DGDecode?
Gruß
akapuma
