Zitat von HQ-LQeine CLI-schnittstelle hat es nicht oder?
Nicht dass ich wüsste.
Zitat von HQ-LQbasiert es auf ein CLI-programm oder ist das eine komplette eigenentwicklung?
Keine Ahnung - du kannst ja mal den Autor fragen; Auf moitah.net ist seine E-Mail-Adresse angegeben.
Da ich keinen Thread dazu gefunden habe, mache ich hiermit mal einen auf:
Ein nettes kleines Tool zum Demuxen von FLV-Dateien per Drag & Drop. Die neuste Version unterstützt auch Flash-Videos mit h.264/AVC-Video- und AAC-Audio-Streams.
Changelog:
1.4.0 (2008-Nov-16):* Supports H.264/AVC, written as a raw elementary stream.
* Supports AAC, written as .aac with ADTS headers.
* Extracts VP6 alpha channel to a separate file.
* Prompts before overwriting files.1.3.0 (2008-Feb-26):
* Added dialog that lists the status of all files, replaces the message box that was shown for each file.
* Doesn't leave files open upon error.
* Better handling of incomplete files.
* Changed VP6 FourCC from FLV4 to VP6F.
* A few fixes for rare files.
Automatische Übersetzungen sind eine tolle Sache! 
(Quelle: de.msn.com, Browser ohne Flash-Plugin)
Zitat von LigHDXDiag starten, alle Ergebnisse speichern lassen, nach "Video" suchen.
Sieht bei mir folgendermaßen aus:
Video Accel: ModeMPEG2_C ModeMPEG2_D ModeWMV9_B ModeWMV9_AZitat von LigH
Also über nicht beschleunigtes MPEG-4 brauche ich mich nicht zu wundern.
Doch, brauchst du... :
Laut dieser Liste:
http://www.nvidia.com/docs/CP/11036/…_Comparison.pdf
unterstützt deine 6800 GS H.264 Decode Acceleration. D.h. ich würde davon ausgehen, dass eine der beiden WMV9-Modes h.264 umfasst?
Und wenn ich das richtige verstehe, wollen die ihr PureVideo mit Hardware-Decoding nochmal extra bezahlt haben?!
http://www.nvidia.com/object/dvd_decoder.html
Und was mich noch etwas wundert:
a plug-in for Microsoft® Windows® Media Player and Media Center Edition
Also NUR dafür und nicht irgendwie DirectShow-basiert? Oder doch? Langsam steige ich nicht mehr durch...
/EDIT:
Und noch was gefunden:
http://www.anandtech.com/video/showdoc.aspx?i=2977
With the launch of its GeForce 8600 and 8500 GPUs, NVIDIA became the first to offer 100% GPU based decoding of H.264 content
D.h. die älteren unterstützen das Decoding offenbar nur teilweise.
Problem gelöst - NCQ (Native Command Queing) ist schuld. Mit deaktiviertem NCQ bekomme ich endlich einen anständigen 64k sequential read-Durchsatz (siehe Anhang) :ja:
Entweder ist das ein generelles RAID0-Problem oder ein spezifisches mit Samsung-Platten oder diesem speziellen Modell. Auf jeden Fall "stottert" der Transfer ohne NCQ nicht mehr in Abständen von einer Sekunde.
Trotzdem natürlich vielen Dank an Karl für die Tips!
P.S.:
Der 3ware-Support ist ziemlich schnell - ein paar Stunden nach meiner Anfrage hatte ich schon eine Antwort. Da stand die Lösung zwar nicht unmittelbar drin, aber etliche Links zu entsprechenden Themen in deren Knowledge Base. Da habe ich dann zufällig Muster-Benchmarks entdeckt, bei denen in der Test-Konfiguration deaktiviertes NCQ angegeben war.
Mal eine Frage am Rand, da es mir bei diesem Trailer aufgefallen ist:
Ich meine hier im Forum immer mal wieder gelesen zu haben (ich meine auch von dir, LigH?), dass die VMR-Renderer für nVidia-/ATI-h264-Hardwarebeschleunigung zuständig sind.
Allerdings ist der einzige Renderer (Media Player Classic unter Options > Playback > Output), mit dem ich diesen Trailer (nahezu) ruckelfrei dargestellt bekomme, der Overlay Mixer -
VMR9 (egal ob "windowed" oder "renderless", egal welche Option ich unter den "VMR7/9(renderless)" & "DirectX 7/9" settings wähle) scheint das Decoding der CPU zu überlassen, obwohl ich interessanterweise mit beiden Renderern beim Abspielen eine Gesamt-CPU-Auslastung von ca. 60 % habe (hier momentan ein Dual Core E8400) - nur mit dem Overlay Mixer läuft es nahezu flüssig.
Decodieren übernimmt ffdshow, GraKa ist eine GeForce 8500GT. Ich habe auch in die ffdshow-Optionen geschaut, da finde ich nichts Renderer-spezifisches - sollte auch mit dem reinen Decodierungs-Vorgang nichts zu tun haben, oder? Deaktiviere ich das h.264-Decoding in ffdshow, wird der MainConcept AVC/H.264 Video Decoder verwendet (wo auch immer der herkommen mag...); Setze ich den Merit dieses Filters mit dem "Direct Show Filter Manager" herunter wird überhaupt kein h.264-Video wiedergegeben.
Können der ffdshow- bzw. MainConcept-Filter überhaupt auf Hardware-Decoding zurückgreifen oder gibts dafür einen speziellen DirectShow-Filter von nVidia/ATI (den ich nirgendwo finde)? Und wie bzw. an welcher Stelle im Decoding-Prozess hat der Renderer damit etwas zu tun?
Zitat von Karl
...nur um Dein "Testprogramm" als pot. Fehlerquelle auszuschließen.Hier: http://www.hardwareluxx.de/community...d.php?t=350664 gips 'ne Menge zu lesen.
Stimmt - HDTach und HDTune scheinen insbesondere für Hardware-RAIDs nicht geeignet zu sein. Beim Stöbern habe ich noch das hier gefunden (direkt aus der 3ware KB):
Gehe ich exakt nach der gegebenen Anleitung für IOMeter vor, erhalte auch wieder ganz tolle Werte...:nein: (siehe Anhang).
Interessanterweise habe ich eine durchgängig exorbitante Rate im 64k sequential write, 64k sequential read pendelt sich ungefähr auf der Performance einer Platte im Array ein. Bei einem 64k sequential read auf einem 64k Stripe (also quasi "Laborbedingungen") sollte ziemlich exakt die doppelte Leserate einer einzelnen Platte herauskommen, oder?
Ich habe das ganze wieder in zwei Rechnern gemessen; Die Ergebnisse weichen kaum voneinander ab.
Interessant wirds allerdings wenn ich "Results Since" von "Start of test" auf "Last update" (also quasi Ansicht des aktuellen Werts) umschalte - hier pendelt die Leserate zwischen ~160 und ~0,5 MB/s, und zwar in regelmäßigen Intervallen von ungefähr einer Sekunde. Man hörts auch in den Platten: Eine Sekunde "Gerumpel", eine Sekunde Stille - entsprechend schwankt die Leserate zwischen voll und fast nix, wobei dann im Schnitt offenbar ziemlich genau die Hälfte herauskommt.
Ein sequential read mit 128k führt zu nahezu identischen Resultaten.
/EDIT:
Dear sir or madam,
I have a performance problem with a 3ware 9560SE-2LP.
My basic system setup:
- Mainboard: Gigabyte EP45-DS3 (latest BIOS, Revision F9)
- Processor: Intel Q6600
- RAM: 2 x 2 GB Kingston DDR2-1066
- 3ware 9650SE-2LP-Controller (latest Firmware, latest Drivers)
- Two Samsung HE502IJ ("SpinPoint F1 RAID 24/7", 500 GB) in a RAID 0 at the 9650-card
- new installed Windows XP SP2 (32 Bit) for testing purposes with the latest Intel chipset-drivers, no anti-virus-software, no software-firewall, Windows Index-Service deactivated and nothing else installed that could possibly decrease system performance.
9650 RAID-settings which I assume influencing the performance:
Drive Queing Mode: Enabled
StorSave Profile: Performance
Auto-Verify: Disabled
Auto Carving: Disabled
Auto-Rebuild: Disabled
Write Cache: Enabled
Link Speed Control: 3.0 Gbps (manually set)
Stripe-Size: 64k
A single Samsung HE502IJ-disc at the Intel onboard SATA-Controller is measured with the following results
(measured with HDTach):Burst Speed: ~235 MB/s
Average Read: ~75 MB/sBoth drives are producing nearly identical results only differing in one or two MB/s.
After measuring the performance of the RAID-Array with HDTach and getting a burst speed of ~130 MB/s and
a average read speed of ~105 MB/s I found the following knowledge base article:http://www.3ware.com/KB/article.aspx?id=15072&cNode=1R6H2L
I followed the steps for IOMeter in the article exactly and the measured read performance is even worse than
the HDTach results: Average read ~80 MB/s. (see attached screenshots)If I switch "Results Since" from "Start of Test" (average rate) to "Last Update" (rate at the moment) I can see
the problem: The read rate is changing between ~0,5 and ~160 MB/s in an interval of about a second, which I assume
results in the nearly exact half maximum speed in average. This can also be heard at the harddiscs - about one
second sound of operation, about one second silence.Interestingly the write rate (64k sequential write, also measured with IOMeter) is on a constant level of ~165 MB/s
(see attachment).
I also tried measuring the read speed with 32, 128 and 256k - the results are nearly the same.
No RAID-verification or anything else controller-specific process was running while testing.
I tried two different PCIe-Slots on the Gigabyte-Mainboard - one of the PCIe x1-Slots and the second PCIe x16-Slot - no changes in performance.
I also tested the card in another PC (Asus P5K-Mainboard, Intel E8400, 4 GB DDR2-800 RAM, PCIe x1- and PCIe x16-Slot) - same problem here.
I also tried the three possible stripe sizes (16, 64 and 256) (all of them are resulting in the same slow average read speed) and tried to use shorter SATA-Cable than the included ones; This also did not change anything.
The last thing I tried was deactivating all PCIe-onboard-devices on both mainboards to see if any component is interrupting the controller on the PCIe-Bus - no changes.
Regards,
Mal schauen...
Auf dem Gigabyte-Board habe ich alle potentiellen PCIe-"Verstopfer" im BIOS deaktiviert (z.B. LAN- und Sound-Chip) - ungefähr 105 MB/s.
Test in meinem momentanen Hauptrechner (Asus P5K-Mainboard im zweiten PCIe x16-Slot) - ungefähr 105 MB/s.
Stripe Size 16, 64 und 256 probiert - ungefähr 105 MB/s.
Kürzere SATA-Kabel verwendet (halb so lang wie die 3ware-Kit-Kabel) - ungefähr 105 MB/s.
Und immer Burst-Rates von 130 bis maximal 150 MB/s - meine recht alte 500 GB Samsung HD501LJ (im IDE-Legacy-Modus am onboard-Controller in meinem Hauptrechner) schafft 228 MB/s...
Die zweite 9560SE-2LP im Server ist im Burst auch sehr langsam, was für mich langsam nur noch einen Schluss zulässt:
Mein toller 190€ Hardware-RAID-Controller mag für RAID 1 geeignet sein, ist aber für RAID 0 offenbar absoluter Sch****dreck!
Für gerade mal 10 bis 15 MB/s mehr im Gegensatz zur dritten Single-SATA-Platte am onboard-Controller werde ich wohl kaum ein Stripe-RAID mit doppelter Ausfallwahrscheinlichkeit verwenden.
/EDIT:
Die Platten schaffen einzeln am onboard-Controller Burst ~235 MB/s und Average Read ~75,5 MB/s. Ergo sollten theoretisch Average 140 - 150 MB/ drin sein; PCIe x1 sollte ca. 250 MB/s packen.
Ich schreib' mal eine nette Anfrage an 3ware/AMCC...
Zitat von KarlHast Du noch andere SATA-Anschlüsse auf dem Controller frei?
Nein - ist ein 2-Port-Controller, d.h. nur RAID 0 oder 1.
...als Duke Nukem Forever angekündigt wurde und die ersten Screenshots auf der 3DRealms-Seite auftauchten? 
...als Twix noch Raider hieß? *SCNR*
Hallo Karl,
Zitat von KarlHast Du evtl einen anderen Steckplatz frei?
Leider nicht. Ein PCIe x1 ganz oben wäre noch frei, direkt dahinter kommt aber leider ein dicker Chipsatzkühler und die Board-Designer rechnen offenbar nicht mit langen x1-Karten. Mit dem aktuellen Steckplatz ist es schon eng - dahinter kommt auch ein Chipsatzkühler, allerdings ein flacher - da "schwebt" das Ende der Karte auch nur ein paar Millimeter drüber. Thermisch nicht sonderlich vorteilhaft...
Im zweiten PCIe x16-Slot steckt eine zweite Grafikkarte, auf die ich auch nicht verzichten möchte (nein, keine Monsterkarten im SLI/Crossfire für's Zocken, sondern zwei weil ich zwei LUTs (Lookup Tables für Farben) für zwei kalibrierte und profilierte Monitore brauche).
Auf jeden Fall werde ich die Karte aber mal testweise in den zweiten x16-Slot stecken.
/EDIT: Gerade probiert, keine Änderung.
Zitat von KarlChipsatz/Controller-Treiber aktuell?
Jupp, aktuelles MB-BIOS, aktuelle Karten-Firmware, aktueller Karten-Treiber und aktuelle Intel-Treiber für den P45-Chipsatz.
Zitat von KarlIrgendwelche Raid-Beschleuniger auf der Karte nicht aktiv?
Habe ich schon nachgeschaut - es gibt nur einen Punkt, in dem man in drei Schritten zwischen "Security" und "Performance" auswählen kann (muss ich nochmal nachgucken was das genau war, auf jeden Fall steht es auf "Performance"). Ebenso habe ich den SATA-Modus überall manuell von "Auto" auf "3.0 Gbps" gestellt, was der Controller aber an sich auch selbst erkennen sollte.
Ansonsten hat das Teil eigentlich nur diverse allgemeine Settings - RAID-Modus, Verify, Rebuild etc.
Background-Verify lief übrigens während der Messung nicht, darauf habe ich geachtet.
/EDIT:
Folgende Settings dürften Einfluss auf die Performance haben:
Drive Queing Mode: Enabled
StorSave Profile: Performance
Auto-Verify: Disabled
Auto Carving: Disabled
Auto-Rebuild: Disabled (sollte bei einem RAID 0 auch keine Rolle spielen, oder?)
Write Cache: Enabled
Link Speed Control: 3.0 Gbps
Das ganze läuft übrigens auf einem frischen Windows XP SP2 mit abgeschaltetem Indexdienst.
Momentan ist das ganze ein 64k Stripe - die Auswirkungen einer kleineren oder größeren Stripesize dürften für die Durchschnittsgeschwindigkeit aber nicht so extrem entscheidend sein, oder? Auf der ersten Partition des Arrays läuft übrigens das OS.
Und ich merke gerade, dass ich entweder ein kaputtes Board oder eine schlechte Board-RAM-Kombination (Kingston DDR2-1066) erwischt habe... Gigabyte "An-Aus-Bug" und plötzliche Reboots.....*AAAARGGGGHHHHHH*
Hallo,
im festen Glauben, endlich mal vernünftige Transferraten in den Rechner zu bekommen, habe ich mir jetzt ein RAID 0 gebaut.
Das ganze besteht aus folgenden Komponenten:
- 3ware 9650-2LP-Controller (PCIe x1)
- 2 x Samsung HE502IJ
- das ganze auf einem Gigabyte EP45-DS3-Board
Toll, jetzt wird alles mächtig beschleunigt, wahnwitzige Transferraten...
... denkste!
Die beiden Platten im RAID 0 (laut CHIP-"Bestenliste" durchschnittliche Leserate pro Stück ca. 70,9 MB/s) liefern bei mir gerade mal durchschnittlich 105,9 MB/s (siehe Screenshot 1). Erwartet hätte ich mindestens 130 MB/s...
Das ganze ist gerade mal knapp 10 MB/s schneller als eine einzelne Samsung HD103UJ im gleichen Rechner am Intel-Onboard-Controller im AHCI-Modus (siehe Screenshot 3).
Besonders wundert mich die niedrige "Burst Speed". Screenshot 2 stammt von unserem Server - gleiche RAID-Karte, hier allerdings zwei Samsung HE103UJ im RAID 1. Auch hier ist die Burst Speed sehr niedrig.
Ist das normal und hat dafür jemand eine Erklärung?
Nur falls es jemanden interessieren sollte und zum Vergleich noch Screenshot 4, auch bei uns aus dem Server. DAS nenne ich mal Transferrate... sowas ist leider in entsprechenden "Desktop-Kapazitäten" viel zu teuer. Momentan ist eine einzelne SAS-Platte am Dell-PERC-Controller also knapp 30% schneller als zwei SATA-Platten im RAID 0...
/EDIT:
Mit Partitionierung (ca. 200 / 800 GB) kann es nicht zusammenhängen, oder?
...als aktuelle Hochleistungs-Prozessoren noch passiv gekühlt liefen?
...als der Begriff "Gehäuselüfter" nahezu unbekannt war?
...als PCs außer ein wenig Plattengerumpel kaum einen Laut von sich gaben?
...als PC-Gehäuse noch aus mehrere Millimeter dickem Stahlblech bestanden?
...als Netzwerke noch 10Mbit/s hatten und per BNC-Kabel nebst T-Stücken und Terminatoren verkabelt wurden?
Tja, er will sie einfach nicht...
Hab jetzt eine andere bestellt (http://www.delock.de/produkte/grupp…A_II_89119.html) - diese hat einen JMicron JMB36x-Chip (im Gegensatz zu den anderen mit Sil-Chip). Funktioniert mit aktuellen Treibern von der JMicron-Homepage unter Windows 2003 SBS incl. "sicherem Entfernen". 
:welcome:
Forensuche => "Interlacing" oder "Zeilensprungverfahren".
Nachtrag: Das schabende Geräusch war wohl nur eine Vibrations-Übertragung auf das Gehäuse. Ich habe die Platte einmal aus dem Vibe-Fixer genommen und wieder reingesteckt, seitdem ist's weg. Im Prinzip steckt sie jetzt allerdings genau wie vorher zwischen den Gummibändern, ist aber ruhig - verstehe ich zwar nicht, aber was solls...
Die klackende Platte geht morgen zurück zum Händler. Das gibt mit Sicherheit wieder ein wahnsinniges Hickhack - das Klacken ist nicht reproduzierbar und Seagate schreibt den Händlern Test mit den SeaTools vor (sagt der Händler zumindest), und die schließen bei mir momentan alle mit "Bestanden" ab...
Zitat von ExyVerändert das die Qulität bzw die Bitrate wenn man keinen Encoder benutzt oder bleibt die Qulität nach dem schneiden gleich wie im Original?
Wenn du keinen Encoder benutzt, bleibt die Qualität gleich - du kannst dann allerdings nur an I-Frames (bei DVB-Streams normalerweise ungefähr jede halbe bis ganze Sekunde, hängt vom Stream ab) und nicht framegenau (also auf eine fünfunzwanzigstel Sekunde genau auch auf P- oder B-Frames) schneiden.
Übrigens ändert der Einsatz eines Encoders in Cuttermaran nur die Stellen ungefähr eine halbe Sekunde (je nach Schnittpunkt und Stream) vor und nach dem Schnitt - bei vernünftiger Einstellung des Encoders fällt das kaum bis überhaupt nicht auf.
Noch etwas anderes ist der "Erzeuge DVD konformes Ergebnis"-Modus - hier werden z.B. alle GOPs mit mehr als 15 Frames neu encodiert. Habe ich persönlich noch nie ausprobiert (da mittlerweile eigentlich fast alle Standalone-Player auch nicht ganz 100% konformes Material problemlos anzeigen), hier kann es allerdings potenziell zu größeren bzw. auffälligeren Qualitätsverlusten kommen - je nach Einstellungen des Encoders und Quellmaterial.
Herzlichen Glückwunsch Seagate - drei 750 GB Barracudas (gleiches Modell, gleiche Serie, gleiche Firmware) bestellt; Alle drei hören sich komplett anders an:
Platte 1 macht keine außergewöhnlichen Geräusche und läuft normal und ruhig, Platte 2 macht in ziemlich regelmäßigen Abständen zwei seltsame, tieffrequente, "schabende" Geräusche hintereinander, Platte 3 klackt nicht reproduzierbar und in offenbar zufälligen Abständen ab und zu zwei- bis dreimal nacheinander recht laut während in den SMART-Daten die Seek Error Rate ins Unermessliche steigt.
Das ganze übrigens in drei absolut identischen Systemen.
Hätt' ich mal Samsungs bestellt...
Zitat von seronil43Interessanter Weise sind beide Versionen bei Gleicher kbps-Rate gleich groß, obwohl doch die eine nur noch 1/4 der Auflösung hat ...
Für die Dateigröße ist nur die Bitrate entscheidend.
Wie du schon korrekt feststellst:
Zitat von seronil43Meine eigenen praktischen Erfahrungen zeigen mir, dass die geringere Auflösung bei gleicher Größe bessere Qualität hat
Bei einer größeren Bildfläche fallen entsprechend mehr zu komprimierende Daten an. Mit der Bitrate regelst du (einfach gesagt) wie viel Platz das Video pro Sekunde beanspruchen darf - das ist unabhängig von der Auflösung. Daraus ergibt sich dann deine Beobachtung, dass mehr Bildfläche bei gleicher Kompressionsstärke (Bitrate) schlechter aussieht.
Zitat von seronil43Allerdings wird auch dazu geraten, mit höherer Auflösung zu digitalisieren und erst später die Auflösung wieder zu verringern
Ich mache analoge Captures grundsätzlich in voller PAL-Auflösung (704 x 576 bzw. 720 x 576 je nach Equipment) mit verlustloser Kompression (z.B. MJPEG oder HuffYUV) - Resizen und Komprimieren kommt dann später, auf jeden Fall ist direktes Capturing in DivX, XviD, MPEG-2 oder ähnliches nur für "quick and dirty" geeignet, jedoch für optimale Qualität nicht empfehlenswert.
Zu diesem Thema haben wir mehr als genug Beiträge ==> Forensuche.
Und wenn ich euch jetzt sage das ihr bei 2.5m Sitzabstand nicht annährend einen Unterschied erkennen könnt ob FullHD oder HD Ready , was sagt ihr dann dazu?
Dann sage ich dazu, dass diese Aussage zumindest extrem unpräzise ist, da wesentliche Angaben fehlen.
Ich zumindest traue mir sagen das ich bei meinem Pio TV mit HD Ready ein besseres Bild bekomme als jeder LCD mit FHD bei FHD Zuspielung und nicht den geringsten Unterschied erkennen konnte bei 2.5m Sitzabstand von einem FHD TV.
Wie schon gesagt: "HD Ready" sagt abslout nichts über das tatsächliche Auflösungsvermögen des Panels aus. Vermutlich darf man das Logo auch auf einen 4" digitalen Bilderrahmen mit 320 x 240 Pixel kleben, sofern das Ding einen HDMI-Eingang hat und 1080 downscalen kann. Außerdem spielt neben dem Betrachtungsabstand selbstverständlich auch die Panelgröße eine Rolle:
Wenn du 2,5 m vor einem 37"-Panel mit 1366 x 768 sitzt, dürfte zwischen 720 und 1080 praktisch kein Unterschied bestehen. Sitzt du 2,5 m vor einem 37" 1080-Panel, dürfte 1080 im Gegensatz zu 720 durchaus noch ein ganzes Stück besser aussehen. Sitzt du 2,5 m vor einem 52" 1080-Panel, wird der Unterschied zwischen 720 und 1080 schon ziemlich deutlich erkennbar sein.
Es werden in allen Fällen keine Welten zwischen 720 und 1080 liegen, da gebe ich dir schon recht, der pauschalen Aussage "nicht annährend ein Unterschied" möchte ich allerdings widersprechen.
Aber eigentlich geht es ja nur genau darum:
mit FHD bei FHD Zuspielung
Also um auf den Thread-Titel zu antworten: Ja.
Ich denke das sehen wir gleich, oder?
Ihr schwebt genau wie beim dem Magapixelwahn bei Digicams rum. Da sieht nämlich auch keiner einen Unterschied auf einen normalen PC Monitor.
Um hier nicht ins OT abzugleiten, habe ich dazu mal hier einen neuen Thread aufgemacht.
