Hi,
schönen Dank. Das sind doch schon mal ein paar brauchbare Werte. Wenn ich in meinen Semesterferien zuviel Zeit habe werde ich mir mal eine Übersicht erstellen und diese hier posten.
Ich denke da mal so an die geläufigsten Codecs:
video: xvid; divx; x264
audio: mp3; ogg; ac3; aac
Bin für weitere Vorschläge offen, aber das muss noch nen bissel warten - Prüfungen stehen bei mir ins Haus.
--
so long
phate
Hi,
es war stets der normale Overlay eingeschaltet.
Klar ist die CPU-load bei höheren Videoauflösungen größer. Der Aufwand dürfte doch wohl quadratischer Natur sein.
Wenn die Auflösung in x und y-Richtung doppelt so groß ist, dann ist die
eigentliche Fläche des Videos ja 4-mal so groß.
Es geht mir schlicht und allein um das Verhältnis zwischen dem Dekodieraufwand für gleichaufgelöste (gibts das wort überhaupt) Videos in
verschieden komprimierten Codecs. Evt. kennt ja jemand eine Übersicht.
Der Anteil für Audio dürfte doch verschwindend gering sein oder?
--
Für Eure Mühen im voraus besten Dank
phate
Zitat von nexustheoriginalNochmal: Welcher Ausgabemodus? (Beim MPC: Optionen -> Wiedergabe -> Ausgabe -> DirectShow Video)
>> System Default
Zitat von nexustheoriginal
Ja. Aber für irgendwas müssen die 3GHz+/DualCore/etc.-Prozessoren ja zu gebrauchen sein.
>> Tja so sieht es heutzutage leider aus. Effizienz ist doch egal. Aber das soll mal nicht Gegenstand diese Threads werden.
--
phate
hi,
das ging ja fix - also ich nutze den wahlweise den bsplayer bzw. mpc (neuste versionen) in den Standardeinstellungen. ffdshow (auch in der neusten version) - wie schon erwähnt mit den Standardeinstellungen ohne postprocessing.
Der xvid decoder lag selbst bei 35-40% (oder noch mehr - ohne aktivierte Features, mal abgesehen vom Filmeffekt).
nach x264 und cpu habe ich geschaut - sieht ja zum Teil düster aus. Wenn GHz Rechner (> 2 GHz) von x264 videos in die Knie gezwungen werden.
Arbeitet jemand bei VLC an eigenen Dekodieralgorithmen??
--
soweit von mir
phate
hi,
ich habe folgenden Rechner:
AMD 1.3 GHz Duron
256 MB DDR - Ram
120 GB Samsung 7200 rpm
Win2000 SP4
Beim Abspielen einer Filmdatei
--
Kontainer mkv, Xvid Datei mit QPel und weiteren Features,
ogg - Audio
--
entsteht bei normalen Dekodern (XVid - ffdshow) in etwa eine CPU-load von
30-40%. Der VLC media player hat hingegen nur 5-10%
postprocessing in beiden Fällen abgeschaltet. Wie passt das zusammen?
Wieso kann das Dekodieren beim VLC so viel effizienter sein (es geht ja immerhin um den Faktor 4-8)?
--
Was ist für andere Komprimierungsverfahren zu erwarten?
siehe x264 - nero -
Ich frage deshalb, da ich mit dem Gedanken spiele mir einen Laptop zuzulegen. Ich würde ihn eher nicht zum rendern von Videos einsetzten - aber wohl zum abspielen. Aber ich sehe diesen als Investition in die Zukunft 4-5 Jahre. Also wäre ich noch damit in der Lage, Filme, die mit neueren Codecs umgewandelt wurden, abzuspielen.
--
Ich denke über ein Samsung nach
1.6-2.0 GHz mit 1 GB Ram 5400 rpm HD.
Für Eure Mühe im voraus besten Dank
phate
Ich weiß, dass dieser Post nicht so ganz hierein passt, und doch gehört er zum Thema.
Vor einigen Wochen habe ich gelesen, dass die Zeitschriften mit Filmen auch nachteilig für den Filmfan sein könnten. Diese Dumpingpreise führen u.U. dazu, dass die Filme nicht mehr in Videotheken verfügbar sein werden. All jene die dann diese Zeitschriftenangebote verpasst hätten, wären um eine Bereicherung ärmer.
Seht Ihr das auch so?
phate
Hi
mir ist amerikanisches Filmmaterial in die Hände gefallen.
DGIndex zeigt beim Preview, dass das Material Progressiv
ist. Video type pendelt sich nach einiger Zeit bei
90% Film und 10% NTSC ein.
So habe ich bei field operation forced film eingestellt.
Nach dem Umwandeln sind dennoch an einigen Stellen
die charakteristischen Kämme zu sehen.
So nun aber zu meiner Frage:
Den Nutzen von interlace kenne ich. Aber warum sollte
man Material im teil-interlace, sofern es diesen Begriff
überhaupt gibt, produzieren. Wie schon gesagt - die Kämme
treten nur an einigen Stellen auf.
Nun bin ich diesem per gknot tomscomp zuleibe gerückt.
Ist das eine suboptimale Variante?
Vielen Dank für Eure mühe.
phate
Hi
ich hab mal schnell nen Untertitel Korrektur Programm geschrieben.
Ich hatte meist Fehler bei der Unterscheidung vom kleinen "L" und
großen "i". Dies wäre insofern man die Standartschriftart Arial nutzt
kein Problem, aber wenn man auf andere umschwenkt, speziell jene
die Handschriften nachahmen, dann werden die Fehler ersichtlich.
Da wir gerade Haskell lernten und diese recht fix ist - für Problem-
lösungen habe ich mal eben das geschrieben. Das ist mehr vielleicht
der Interesse halber, als wirklich nützlich.
Bin für jede Verbesserung offen.
{- stubtitle changer - version 1.0
much faster then the first version - due to the fact
having less - correction tuples in changeseng and changesengfront
-}
module Subtitlechange where
type Change = ([Char],[Char])
type Changes = [Change]
{- array of mistakes and their corrections
when parsing dvd bitmap subtitle with
subrip to a srt textfile
-}
changeseng :: Changes
changeseng = [(' l', ' I'),
('<i>l', '<i>I'),
('''l', '''I')]
{- array of chars, which can deliver
after an l
-}
vowelsy :: [Char]
vowelsy = ['a','e','i','o','u','y']
{- have to distinguish the the difference
of the l and I at the beginning or in the string
-}
changesengfront :: Changes
changesengfront = [('l', 'I'),
('-l', '-I')]
main :: IO ()
main = do
putStr "Input-File: "
ifile <- getLine
putStr "Output-File: "
ofile <- getLine
x <- readFile ifile
writeFile ofile (concat [correctfront (correct str changeseng) changesengfront | str <-
(getNewLine x [])])
putStr "Done!!"
newline :: Char
newline = '\n'
{- seperate the input, which is taken as a
whole string into the lines which show up usually
at the shell or in an editor
-}
getNewLine :: String -> String -> [String]
getNewLine [] _ = []
getNewLine (x:xs) culi
| x == newline = (culi ++ [x]) : (getNewLine xs [])
| otherwise = getNewLine xs (culi ++ [x])
-- correcting mistakes in a string
correct :: String -> Changes -> String
correct [] _ = []
correct str [] = str
correct inputstr ((w,r):xs) = correct (correctone inputstr (w,r)) xs
correctone :: String -> Change -> String
correctone [] (w,r) = []
correctone inputstr (w,r)
| (length inputstr) < (wlength) = inputstr
| (take wlength inputstr) == w
&& not(elem (inputstr !! wlength) vowelsy) = r ++ correctone (drop wlength inputstr) (w,r)
| otherwise = (head inputstr):(correctone (tail inputstr) (w,r))
where
wlength = length w
-- correction of mistakes at the start of a string
correctfront :: String -> Changes -> String
correctfront [] _ = []
correctfront str [] = str
correctfront str ((w,r):xs)
| w == (take wlength str) && not(elem (str !! wlength) vowelsy) = r ++ drop wlength str
| otherwise = correctfront str xs
where
wlength = length wKompilieren mit dem GHC (glasgow haskell compiler) hat nicht funktioniert.
Der Haskell Interpreter https://localhost/www.haskell.org hat auf jeden Fall funktioniert.
cu phate
Hi
habe nur Win2k aber bei XP dürfte es ähnlich sein.
Start -> Einstellungen -> Systemsteuerung -> Benutzer und Kennwörter
dann im ersten Registerblatt - Häkchen bei Benutzer müssen ....
rausnehmen fertig..
cu phate
--
drei posts in zwei minuten ... well done
Hi
Ich habe neulich mal zum Test burn4free probiert.
http://www.chip.de/downloads/c1_downloads_13009524.html
Auf den ersten Blick nicht schlecht. Auf jeden Fall besser als die OEM Versionen
die den Brennern immer beigelegt werden. Achtung Spyware ist dabei.
Ob auch DL DVD unterstützt wird weiß ich nicht, da ich es noch nicht probiert habe bzw. im FAQ oder anderen Stellen dazu gefunden habe.
cu phate
Hi
wie im Titel geschrieben (Nur zur Info)!
Und für normal halte ich das nicht - denn bis dato habe ich noch keine
DVD gehabt bei der man sowas eingebaut hat.
Anbei ist es nur zu einfach diesen Mechanismus auszuhebeln.
so long phate
Hallo
ich habe hier eine amerikanische Serie von WB.
Diese habe ich auf den Rechner gezogen und dann ist beim
Abspielen der vob files mittels PowerDVD ist folgendes passiert:
Ich mußte feststellen, dass das Video (bestehend aus mehreren Folgen)
nicht in zeitlicher Reihenfolge war. Ich nehme an, dass man die
Chapter einer anderen Reihenfolge angegeben hat, was sich dann später
beim Abspielen der DVD direkt mit PowerDVD auch bestätigt hat. Der Film
springt an diesen Stellen und das DVD Laufwerk macht seine üblichen
anstalten einen anderen Abschnitt der DVD auszulesen.
cu phate