Beiträge von incredible

Hallo zusammen und nachträglich frohe Festtage!

Ich frage mich, warum der mjpeg codec in FFdshow so sehr stört, dass er ausgemistet werden muss. Sicher, mein letztes Capturing ist Jahre her, aber es gibt bestimmt vieles andere, was wahrsch. eher Sinn macht, als etwas gut funktionierendes zu eliminieren.

Was ist der Grund? Speicherplatz? Code-Entrümpelung? Wenn letzteres der Fall ist, dann würde eher eine Code-Restrukturierung Sinn machen ... wenn das eh nicht schon in der Vergangenheit geschehen ist.

Grüße!
Inc.

Spiele die aktuelle FW auf jeden Fall auf, die aufgespielte ist meist noch eine recht alte.

Behebt einige Bugs.

Habe noch weiter getestet:

- bei mkv's mit 5.1-AC3 wird erwartungsgemäß der AC3 Stream direkt nativ an den Receiver via optischem DigitalAudioOut übertragen. Es erfolgt jedoch keine dekodierte Ausgabe via HDMI, da muss ebenso ein Receiver her oder man stellt den WDTV von Digital- auf StereoOut.

- bei 6ch-AAC ist dies genauso der Fall, bedeutet, wenn der WDTV auf DigitalOutput gestellt ist, wird der AAC Bitstream nativ an den Receiver geleitet und in meinem Fall, da meiner kein AAC dekodieren kann, hört man nix, erst wenn der WDTV in diesem Falle von Digital auf Stereo Out gestellt wird, sodann gibt es einen Downmix des AAC Streams, eben wie bei 5.1-AC3 auch.
Kennt jemand einen Receiver der 6ch-AAC wiedergeben kann?

Bzgl. Kapitel in mkv's, diese kann man direkt ansteuern.
Unten im Screenshot ist noch die alte Firmware zu sehen, in der neuen habe ich im Menue nun rechts neben dem "i" einen Button um in die Kapitelliste zu gelangen.

So wie es aussieht wird h.264 bis hin zu HP@L4.1 unterstützt. Habe die volle Bitrate noch nicht testen können, aber via Handbrake am MAC HighProfile Optionen genutzt.

Die paar mp4s die ich mir mal kodiert hatte, habe ich fix via mkvtoolnix hin zu mkv remuxt und alles wird unterstützt. Voller mp4-Container Support kommt wohl mit einer der kommenden Firmwares.
Wenn man also einen AppleTV hat ist diese Box hier als Zweit-Player fürs Schlafzimmer eher nix, da man ansonst alles als mp4 UND mkv auf Platte haben muss ;-). Aber da ich meine mich zu erinnern, dass ein AppleTV eh nur BaseProfile bei h264 unterstützt, ist das sodann eher ein "Upgrade" an Möglichkeiten.

Falls also jemand was zum Testen hat, ... nur hoch damit. Würde mich interessieren. Es reicht ja z.B. ein Kapitel mit individuellen Video-Einstellungen, entspr. Subs und und entspr. Ton.

Also wenn ich Vorlauf-Modus ">>" sodann ">>|" drücke, kann ich im Film hin und her, also vor und zurück springen. Ob es genau die Titelmarken des Streams sind, weiss ich jetzt nicht. Vor allem bin ich froh, dass er alle meinen individuellen SAR/PAR unterstützt.
Meine mkvs besitzen alle H264-Content und haben wenn dann idx/sub Untertitel und die klappen problemlos. Kannst mir ja ein Stück eines Streams inkl. .srt zum Testen zur Verfügung stellen, ich prüfe das sodann.
Es kommen zudem immer wieder FW Updates heraus, und die Wünsche der Community werden oft berücksichtigt.
Eben nur doof, dass kein Multi-Audiotrack Support beim mp4 Containerformat vorhanden ist.

Abgespielt wird bei mir alles von externen USB HDs, daher habe ich noch keinen Stick probiert. USB 2.0 wird unterstützt. Liegt also dann am Stick, ob er dies auch kann und die erforderliche Datenrate wiedergeben kann.

Habe mir den Western Digital WD TV HD Mediaplayer geholt und bin von dem was er kann begeistert.
Da meine meisten x264 Encodes eh mkv's via Handbrake sind, ist es genau der richtige Player für mich. Es werden sogar anamorphe x264 Encodings mit individuellen SAR/PAR Werten unterstützt - klasse.
Subitles als VobSubs machen kein Problem. AC3, DTS usw laufen bei mir eh über den optischen digitalen Audio-Ausgang und werden im Receiver decodiert, daher kein Problem.
Das Einzige was einem auffällt ist, dass er keine multiplen Audiospuren im mp4 Container unterstützt. Hier muss man via mkvToolnix hin zu mkv remuxen und alles ist bene. FastForward und -Rewind werden unterstützt, und springen kann man auch.
Und Frontcover geben der Bibliothek auf der Platte am Plasma im Menue einen klasse Überblick. Ein Player mit interner HD war für mich kein Muss, weil ich diese eh gerne mobil habe und fix austauschen kann. Ok Netzwerk und Co. gibts keins, aber dafür kostet der auch nur knapp unter 100 Euro.

Er ist jeden Cent wert.

Also, wat isch ja nett so janz verschtehe is ja warum da mit da mit der C-API von Avisynth das ganze angegangen wird, wenn er eh in c++ programmiert. Da kann er doch direkt mit dem Interface des ScriptEnvironments arbeiten.

Schaue mal den Avisynthwrapper der MeGUI an. Den habe ich mal als simplen Wrapper angepasst und um Audiofunktionen erweitert, wo er sodann von Dizmon noch was verändert wurde. (Nur hat der sodann seinen Namen vor die Funktionen gesetzt ... doll nech?).

Hier das Original des Avisynthwrappers:
http://forum.doom9.org/showthr…=106125&highlight=wrapper

Entweder du nutzt diesen um direkt an den Frame zu kommen, den du sodann bearbeiten kannst, so z.B. via GDI anzeigen o.ä..
Oder du guckst in die Source und siehst wie einfach es ist direkt in c++ avisynth auch nativ anzusteuern.

Grüße
Inc.

Besitzt denn das G45 Board die option das h.264 Decoding hardwaretechnisch zu unterstützen? Denn das macht das 780G Board ja erst sinnvoll, da sich die CPU sodann nur noch um die Entschlüsselung kümmern muss.

Ich habe einen HTPC und werde ebenso auf einen 780G mit 4850e CPU umsteigen. Brauche also nur Mobo, CPU und RAM.

Nur ... für mich macht das alles nur Sinn, wenn das mit dem HDMI des 780G-Gigabyte Mobos und meinem neuen 42" Plasma funktioniert (http://www.panasonic.de/html/de_DE/1080640/index.html). Ich habe gehört, dass einige Sony und Toshiba Modelle via HDMI Probleme bereiten, da sie mit dem HDMI Signal des 780G/Gigabytes nicht "klar kommen" -> siehe HTPC News Forum.

Von anderen (viell. sogar von hier) habe ich gelesen, dass die HDMI Ausgabe generell großer Mist jener Mobos sein soll.

Der 42" ist durchweg Phantastisch für das Geld (740€), jedoch hat er keinen VGA Eingang, daher mein HDMI Interesse und aufrüsten wollte ich den HTPC eh.
Momentan gehe ich noch via GF2MX400 und TVtool via S-Video rein. Das Bild alleine ist schon klasse (ja, ich habe gesunde Augen und einen Anspruch an die Schärfe), aber via HDMI erwarte ich natürlich mehr.

Aber ... allen 1080 HDMI und 1024x768 VGA Qualitäten in Ehren .... da meine ganzen x264 Backups im HTPC eh von Std. DVDs mit 720px Anamorph enkodiert sind, würde ein PAL RGB Signal via ATI-VGA-Scart Selbstbaukabel und Powerstrip defakto reichen.

Die ganzen BlueRay Disks sind mir einfach noch zu teuer und ich habe eh alles schon auf DVD zuause. Wenn ich daran denke mir das alles in BlueRay nachzukaufen ... oh weia ... da wäre die HTPC Hardware wohl noch die kleinste Ausgabe

Ganz vielen Dank für alle eure Glückwünsche! Bin die Tage unterwegs gewesen, daher erst jetzt das "Dankeschön".

Zitat

Ich bin eher ein Fan von "purem" Code möglichst auf unterster Ebene - zumindest erstmal so lange, bis ich die absoluten Grundlagen 100% verstanden habe.

Also wenn dir als C++'ler Frameworks á la Qt oder wxWidgeds nicht zusagen und du klar Win32 Apps low level programmieren willst, dann gehts wie oben bereits gesagt nur direkt über die Win32API und deren Konzept ist prozedural und nicht objetorientiert, somit nicht C++.
Die indirekte C++ variante von Microsoft der WinAPI programmierung (wenn man das so überhaupt nennen darf) ist die MFC (Microsoft Foundation Classes) und somit Klassenbasiert, also C++.
Nur, die MFC ist quasi überall aktuell als nicht mehr empfehlenswert bezeichnet, da man bei solchen High Level APIs a) eher Platformübergreifend sein soll und b) es bessere und aktueller gehaltene gibt (z.B. Qt, wxWidgets, Ultimate++, etc.). Zumal Microsoft wohl in Zukunft die MFC wegen des präferierten .net Konzeptes aussterben lässt, bzw. nicht weiter supporten wird (was ja quasi das Gleiche ist).

Wenn du also direkt in Win32API programmieren willst, dann geht das eigentlich bei C/C++ nur via Prozeduralem C, bzw. in prozedural misbrauchtem C++ (bzw. auch mit anderen Sprachen, die ein direktes Aufrufen der Win32 zulassen möglich ist).

Warum willst du so etwas komplexes wie die Win32API mühevoll verstehen? Die Win32API ist (IMHO zu) vielfältig (genauso wie das .net Framework), man kann mit ihr nicht so schnell Dinge erreichen, wie z.B. mit anderen Sprachen oder anderen Frameworks.
Überlege es dir gut, zumal ein richtig objektorientiertes Arbeiten mit der Win32 API damit nicht möglich ist.

Und da du von C++ Programmierung redest, denke ich mal wilslt du auch objektorientiert programmieren?

Alles Gute dem Kapitänleutnant!

Nur mal so am Rande ... für ca. 100€ mehr bekommt man Notebooks mit klasse VideoOut Qualitäten die in Punkto System- & Abspielsoftware alles an vorhandenen HW-Playern an Flexibilität überbieten. Mal ganz zu schweigen von einem Laufwerk, bzw. Brenner usw. usw. der mit dabei ist.

Linux oder Windows ... ist einem selbst überlassen.

Da kann man entscheiden, welcher SW-Player genutzt wird, welcher Codec, welche Einstellungen (ich sage nur FFDshow Filter) usw usw.

- Keine Probleme mit Format-Containern, da alles Dshow basiert (oder Videolan) ist
- Keine Probleme mit 6Ch solange der Codec im System 6CH Out unterstützt.

Ich gucke nur noch mit dem Notebook (ausser TV), und das nebenher mit mximalen 30-40W an der Steckdose (weniger als ein kompletter HTPC auf Desktopbasis).
Der Moment mit "wird nicht abgespielt" gibts bei mir nicht mehr.

Einziger Nachteil .... : Warten bis das NB hochgefahren ist

@phxql
Wenn du BeSweet nutzt, dann kannst du auch gleich ffmpeg nutzen, denn die Binary unterstützt Datenaustausch via stdin/stdout.
Zudem futtert ffmpeg auch avisynth dateien via der M$ Avifil32.lib, das bedeutet, dass auch hier ein 4GB Limit (32bit) existiert. ffmpeg unterstützt auch keine Wavs > 4GB.

Schau mal, was BeHappy für Binaries nutzt zur Audiokonvertierung, denn der machts ebenso via stdin.

Ansonsten ist Aften wie bereits gesagt besser als der ffmpeg eigene ac3 encoder.

Der Pointer zum PVideoFrame ist ein SmartPointer. Dieser ist IMHO nicht Heap allocated, daher sollte dieser vor dem exportieren aus der Funktion oder dll o.ä. zuerst mit Avisynth BitBlt() Funktion auf einen HeapAllocated Speicherbereich gesetzt werden, bzw. kannst du ihn direkt bei RGB32 damit vert. spiegeln und in die in Delphi o.ä. erstellte bitmap kopieren. Denn um einen Blocktransfer kommste eh nicht herum

Hola

Ich bräuchte mal janz dringend ne URL wo man leckere Testvideos (720x576 reicht) runter laden kann. Ich erinnere mich noch an dieses Achterbahnvideo oder die Lady mit dem Telefon. Müssen nicht unbedingt diese sein, aber ich habe hier mein Notebook, bin nicht zuhause, will nen eigenen Filter testen und habe momentan keine 720x576 Streams drauf :-(((

Und wer weiss wovon er redet ist noch eindeutiger im Vorteil

Zitat

wenn die CPU mehr Daten als 50 MB pro sekunde

Wird sie aber niemals, zumindest nicht was "unsere" Encodings- und das daraus resultierende Speichern auf die HD angeht.
Für Encodings ist ein Raid System "Perlen vor die Säue". Beim Kopieren/Muxen und anderem Transfer machts Sinn. Und die 512 MB reichen ebenso vollkommen aus, wenn nix anderes nebenbei läuft. Kein Encoder "cached" soviel Daten im Workout, dass man damit nicht hinkommt.

Ich habe gestern erstmal den Avisynth_C Header für Purebasic fertig gestellt - hatte ich eh auch wegen anderer Dinge vor. Bedeutet, dass ich nun unter PureBasic Avisynth Plugins schreiben kann. Der PARanoiacode könnte sodann in die dll gesetzt werden. Voraussetzung ist aber ein Vorabladen der dll im Script via "LoadCPlugin...".

Nur mal so unter uns .... was wollt ihr mit einer Dll die alles "unsichtbar" im Hintergrund erledigt? Das ist doch der Sinn von PARanoia, dass man sieht, WIE und WAS da gecroppt/resized wird. Bei einer dll kann man das kaum kontrollieren, ok, viell. eine txt Ausgabe zusätzlich, aber ... naja.

Nachher ist was in der Kalkulation Suboptimal und dann heissts "die dll ist nix" Selbst in der appl. PARanoia muss man noch manuell verstellen, damits optimal wird, so z.b. nur croppen oder padden ohne interpolation etc.

Beide Tools haben Ihre Berechntigung ist doch klar

Bei PARanoia kann man aber neben dem Autocrop auch via Vorschau manuell croppen.

In der nächsten Version wird man die Schnittlinien via Mauszeiger bewegen können.

Zitat

Eher nicht...
..Studium ist fertig und nun muß er Geld verdienen und eine Familie ernähren. Gelohnt hat sich das eh nicht!

Wäre schade, denn SHH war und ist ein klasse Programmierer. Ich sage nur "Restream" und TitleSetBlanker.

Ich habe lediglich meine Stellung zu OC im allgemeinen gegeben und das es Sinn macht, wenn man weiss was man da tut, aber das war nun keine Freikarte dass INC jetzt der OC Moderator wird

Ich war jetzt einige Monate weg vom Videoencoding und Development, ich hatte sowieso mal vor PARanoia auf full HDTV Support und einigen zusätzlichen Extras aufzustocken.

Was die Comandline Unterstptzung generell angeht, ja, das wird dann ebenso berücksichtigt.
Bin aber gerade dabei den Avisynth_c.h Header für PureBasic zu portieren um zudem aus dem Code eine Paranoia.dll für Avisynth zu erstellen.

?

Also ich übertakte grundsätzlich
Abstürze hatte ich noch nie, Kühlungsbedarf? ok, wenn man nicht gerade die Vcore richtig in die Höhe zieht und somit eine Kompressorkühlung fällig wird, hält sich der Kühlungsbedarf auch in Grenzen.

Die neuen C2D' haben original schon solch einen geringen Stromverbrauch, dass selbst beim Übertakten kein Board mit 12Phasen Stromversorgung von Nöten ist, was beim Pentium D eine Voraussetzung fürs OC war.

In den heutigen Rankings der OC Gemeinden ist der Kult der, wie hoch man mit Std. Vcore und Luftkühlung kommt. Un da haben die C2D's enorme reserven, sodass 2.6Ghz bei einem z.B. 1.8 Ghz Modell ohne Probleme möglich sind.

Wenn du also einen 4300er oder 4400er C2D nimmst, dir ein Asrock 4CoreDual-VSTA Board holst, 800er Speicher draufpackst, dann sind dort auch 2.6Ghz drin - trotz nicht möglicher Vcore Erhöhung am Board.