Frage von Sven Bötcher:Hallo!
Ich möchte mit einer analogen TV-Karte (;Miro/Pinnacle PCTV Pro, BT848)
Videos aufnehmen, die später als DVD gebrannt werden sollen. Hardware
MPEG2 hat die alte Karte natürlich noch nicht. Im Augenblick probiere
ich herum, was ich an Rechnerleistung brauche. Auf einem PIII-1000 mit
256 MB werden bei der Encodierung scheinbar Bilder verschluckt. Auf
einem Athlon XP mit 512 MB siehts recht gut aus. Liegt das an der
Rechenleistung oder am Speicher? Welche Hardware-Voraussetzungen sollte
man haben, um analoge Quellen ins DVD-Format zu encodieren?
Bye
Sven
Antwort von Thomas Beyer:
Sven Bötcher schrieb:
> > Ich möchte mit einer analogen TV-Karte (;Miro/Pinnacle PCTV Pro, BT848)
> Videos aufnehmen, die später als DVD gebrannt werden sollen. Hardware
> MPEG2 hat die alte Karte natürlich noch nicht. Im Augenblick probiere
> ich herum, was ich an Rechnerleistung brauche. Auf einem PIII-1000 mit
> 256 MB werden bei der Encodierung scheinbar Bilder verschluckt. Auf
> einem Athlon XP mit 512 MB siehts recht gut aus. Liegt das an der
> Rechenleistung oder am Speicher? Welche Hardware-Voraussetzungen sollte
> man haben, um analoge Quellen ins DVD-Format zu encodieren?
Versuche es mal mit meiner alten Step by Step Anleitung, zumindest was
das Capturing angeht: http://www.silent-dreams.de/video.html.
Du hast Dich zwar über die Hardware ausgelassen, aber ich vermute, dass
die monierten dropped frames bei Dir durch den Einsatz untauglicher
Audio/Videocodecs zustandekommen.
PAL analog capturing (;768x576 MJPEG, PCM 48KHz Stereo) hab ich übrigens
bereits mit einem K6-II 350 MHz auf sauber hingekriegt (;<10 lost frames
pro Stunde). Außer einer großen Festplatte braucht man nicht viel an
anspruchsvoller Hardware. Was Du oben aufzählst, ist schon überreichlich
dimensioniert, sieht man mal von eventuellen Problemen mit Chipsets aus
dieser Zeit ab, die bei isochronen Transfers unperformant waren (;VIA,
ALi) und deswegen schon bei Busbelastung mit ~28MB/s Störstreifen im
Bild, Knackser im Ton etc. verursachten.
BTW, analoges Capturing ist old school. Heutzutage ist es ja hipp,
gleich mit hoch komprimierenden Formaten (;MPEG2, MPEG4-AVC, DivX) in
Echtzeit enkodieren zu wollen. Alle diese Formate haben nur eines zur
Folge: Die anschließende Nachbearbeitung (;Cuts, finale Enkodierung als
DVD ...) wird unnötig erschwert, weil diese Formate Endformate sind.
Sprich: Zur weiteren Nachbearbeitung eher ungeeignet.
MfG,
Thomas
Antwort von Sven Bötcher:
Thomas Beyer schrieb:
> Sven Bötcher schrieb:
>
>>> Ich möchte mit einer analogen TV-Karte (;Miro/Pinnacle PCTV Pro, BT848)
>> Videos aufnehmen, die später als DVD gebrannt werden sollen. Hardware
>> MPEG2 hat die alte Karte natürlich noch nicht. Im Augenblick probiere
>> ich herum, was ich an Rechnerleistung brauche. Auf einem PIII-1000 mit
>> 256 MB werden bei der Encodierung scheinbar Bilder verschluckt. Auf
>> einem Athlon XP mit 512 MB siehts recht gut aus. Liegt das an der
>> Rechenleistung oder am Speicher? Welche Hardware-Voraussetzungen sollte
>> man haben, um analoge Quellen ins DVD-Format zu encodieren?
>
> Versuche es mal mit meiner alten Step by Step Anleitung, zumindest was
> das Capturing angeht: http://www.silent-dreams.de/video.html.
Muss ich mir unbedingt durchlesen.
> Du hast Dich zwar über die Hardware ausgelassen, aber ich vermute, dass
> die monierten dropped frames bei Dir durch den Einsatz untauglicher
> Audio/Videocodecs zustandekommen.
Eigentlich nur das, was beim UleadVideoStudio dabei war.
> PAL analog capturing (;768x576 MJPEG, PCM 48KHz Stereo) hab ich übrigens
> bereits mit einem K6-II 350 MHz auf sauber hingekriegt (;<10 lost frames
> pro Stunde).
Bitte? Jetzt bricht mein Weltbild zusammen. Seit 8 Jahren, als DVD noch
gar nicht so verbreitet war, versuche ich mit einer einfachen TV-Karte
grossformatig zu capturen. Ging nix, Maximum war CIF-Format in
Briefmarkengrösse. Von so geringen Hardwareanforderungen habe ich noch
nie gehört. Es hiess immer nur: "Brauchst nen stärkeren PC".
> Außer einer großen Festplatte braucht man nicht viel an
> anspruchsvoller Hardware. Was Du oben aufzählst, ist schon überreichlich
> dimensioniert, sieht man mal von eventuellen Problemen mit Chipsets aus
> dieser Zeit ab, die bei isochronen Transfers unperformant waren (;VIA,
> ALi) und deswegen schon bei Busbelastung mit ~28MB/s Störstreifen im
> Bild, Knackser im Ton etc. verursachten.
Hier werkelt jetzt ein auch vollkommen veraltetet VIA KT266A, vorher war
es ein Intel BX440.
> BTW, analoges Capturing ist old school. Heutzutage ist es ja hipp,
> gleich mit hoch komprimierenden Formaten (;MPEG2, MPEG4-AVC, DivX) in
> Echtzeit enkodieren zu wollen. Alle diese Formate haben nur eines zur
> Folge: Die anschließende Nachbearbeitung (;Cuts, finale Enkodierung als
> DVD ...) wird unnötig erschwert, weil diese Formate Endformate sind.
> Sprich: Zur weiteren Nachbearbeitung eher ungeeignet.
Okay, ich bin lernwillig obwohl ich mit der Einstellung "DVD" (;MPEG2 ?)
bisher gute Erfahrungen gemacht habe": Was soll ich einstellen; DV, AVI,
MPEG, VCD, SVC, DVD, WMV?
Entschuldigung, dass ich mit analogen Capturing komme aber in diesem
Haus liegt nur analoges Kabel, ansonsten habe ich auch DVB-T, DVB-S,
Firwire für den digitalen Camcorder.
Bye
Sven
Antwort von W. Wacker:
Sven Bötcher meinte:
> Ich möchte mit einer analogen TV-Karte (;Miro/Pinnacle PCTV
> Pro, BT848) Videos aufnehmen, die später als DVD gebrannt
> werden sollen.
Ich habe am Anfang mit vielen verschiedenen Programmen
hantiert. Ging zwar, war mir zu aufwändig. Aus heutiger Sicht
kann ich nur jedem empfehlen, sich ein Komplettprogramm
wie bspw. Magix zu kaufen. Kostet nicht viel (;um die 30 Euro)
und man kann wirklich von der Aufnahme bis zum Encodieren
und Brennen alles unter einer Oberfläche erledigen.
Sollte auch auf einem schwächeren PC laufen. Wichtig bei
der Analogaufnahme ist es, die Priorität im Taskmanager
auf hoch zu setzen, dann gibts auch keine droped Frames.
Gruß Winfried
Antwort von W. Wacker:
W. Wacker meinte:
> Wichtig bei der Analogaufnahme ist es, die Priorität im
> Taskmanager auf hoch zu setzen, dann gibts auch keine
> droped Frames.
Und die Resourcenfressende "Vorschau" während der
Aufnahme deaktivieren!
Gruß Winfried
Antwort von Thomas Beyer:
Sven Bötcher schrieb:
> > Du hast Dich zwar über die Hardware ausgelassen, aber ich vermute, dass
> > die monierten dropped frames bei Dir durch den Einsatz untauglicher
> > Audio/Videocodecs zustandekommen.
>
> Eigentlich nur das, was beim UleadVideoStudio dabei war.
Ich kenne nur Ulead Media Studio. Dort kann man fürs Capturing entweder
die MPEG2 Engine oder die Directshow Engine nehmen. Ersteres würde ich
niemals benutzen, bei Letzterem kommt es auf die Wahl des Codecs an
(;AVI), inwieweit das Ergebnis brauchbar ist.
Versuch aber besser VirtualDub zu verwenden. Mehr
Optimierungsmöglichkeiten, besseres Programm zum Capturen.
> > PAL analog capturing (;768x576 MJPEG, PCM 48KHz Stereo) hab ich übrigens
> > bereits mit einem K6-II 350 MHz auf sauber hingekriegt (;<10 lost frames
> > pro Stunde).
>
> Bitte? Jetzt bricht mein Weltbild zusammen. Seit 8 Jahren, als DVD noch
> gar nicht so verbreitet war, versuche ich mit einer einfachen TV-Karte
> grossformatig zu capturen. Ging nix, Maximum war CIF-Format in
> Briefmarkengrösse.
Viele bt8x8 Treiber für TV-Karten sind mies programmiert. Man kann
durchaus mit den Einschränkungen (;Overlay nur bis 352x288, eine
Hardwarebeschränkung älterer BT-Chips) leben und trotzdem full D1
capturen. Halt ohne Overlay Preview, aber mittels VMR kann man trotzdem
schon während der Aufnahme mitschauen.
Sollte Dein TV-Kartentreiber NICHT in VirtualDub auf 768x576 oder
704x576 zu schalten sein, mußt Du es halt mit einem generischen Treiber
wie btwincap versuchen.
> Von so geringen Hardwareanforderungen habe ich noch
> nie gehört. Es hiess immer nur: "Brauchst nen stärkeren PC".
btwincap virtualdub Picvideo Mjpeg PCM Audio == 768x576 full D1
gecaptured, bis die 20GB-Platte in meinem ASUS P5A voll war ;-). Damals
gab es noch kein DVB, ich habe so meinen VHS-Recorder in Rente
geschickt. 1999 sah das typische Procedere so aus:
- Capturen (;wie, beschreibt mein geposteter Link genau)
- MJPEG-AVI durch den MPEG2-Encodierer geschickt (;war damals eine
nächtefüllende Aufgabe pro 2h-Fim)
- Als SVCD verwurstet (;heute würde ich natürlich als DVD enkodieren)
- Wegbrennen
Auf Dein Szenario zugeschnitten:
- Capturen (;wie, beschreibt mein geposteter Link genau)
- MJPEG-AVI durch den MPEG2-Encodierer geschickt (;Procoder, Mainconcept,
TMPGEnc, CCE - in dieser gweichteten Reihenfolge favorisiere ich)
- MPEG2 als DVD authoren (;wenns umsonst sein soll: dvdauthor, ifoedit,
ich favorisiere DVDLabPro)
- Wegbrennen (;Nero, Prassi ONES, dvdrecord)
Audioenkodierung machen alle genannten Encoder nur MPEG1 Layer II. Das
sollt reichen. Wenn Du AC3 willst, müsstest Du aus der AVI in einem
separaten Durchgang den PCM-Ton als WAV extrahieren (;VirtualDub) und
dann durch einen AC3-Encoder der Wahl laufen lassen (;TMPGEnc AC3 Encoder
ist wahnsinnig schnell, auch aus DVDLab heraus modular einbindbar.
Umsonst: BeSweet).
> > Außer einer großen Festplatte braucht man nicht viel an
> > anspruchsvoller Hardware. Was Du oben aufzählst, ist schon überreichlich
> > dimensioniert, sieht man mal von eventuellen Problemen mit Chipsets aus
> > dieser Zeit ab, die bei isochronen Transfers unperformant waren (;VIA,
> > ALi) und deswegen schon bei Busbelastung mit ~28MB/s Störstreifen im
> > Bild, Knackser im Ton etc. verursachten.
>
> Hier werkelt jetzt ein auch vollkommen veraltetet VIA KT266A, vorher war
> es ein Intel BX440.
Der KT266A ist etwas weniger anfällig als sein Vorgänger, der KT133. Der
war definitiv für analoges Capturing in full D1 nicht geeignet, da die
PCI-Performance unter aller Sau war. Beim KT266 kommt es auf den versuch
an. Schau beim Capturing mal nach Anzeichen für Störungen im Bild. Sieht
bei VIA aus, als ob man das Bild durch eine Wellglasscheibe betrachtet
wird, in schweren Fällen kommen weiße Peaks dazu.
> > BTW, analoges Capturing ist old school. Heutzutage ist es ja hipp,
> > gleich mit hoch komprimierenden Formaten (;MPEG2, MPEG4-AVC, DivX) in
> > Echtzeit enkodieren zu wollen. Alle diese Formate haben nur eines zur
> > Folge: Die anschließende Nachbearbeitung (;Cuts, finale Enkodierung als
> > DVD ...) wird unnötig erschwert, weil diese Formate Endformate sind.
> > Sprich: Zur weiteren Nachbearbeitung eher ungeeignet.
>
> Okay, ich bin lernwillig obwohl ich mit der Einstellung "DVD" (;MPEG2 ?)
> bisher gute Erfahrungen gemacht habe": Was soll ich einstellen; DV, AVI,
> MPEG, VCD, SVC, DVD, WMV?
IMHO wirst Du mit dem Software-Echtzeitencoder von Ulead nicht glücklich
werden. Dropped Frames wirst Du nie so niedrig halten können wie als
MJPEG-AVI und VirtualDub, und die Qualität ist auch mieser.
> Entschuldigung, dass ich mit analogen Capturing komme aber in diesem
> Haus liegt nur analoges Kabel, ansonsten habe ich auch DVB-T, DVB-S,
> Firwire für den digitalen Camcorder.
Kein Thema. Die Frage ist hier 101% on topic, und nach all dem DVB-Hype
der letzten Monate macht sowas wieder mal richtig Spass. Schade, das
Ottfried abgewandert ist. Das war sein Metier ;-)
Gruss,
Thomas
Antwort von Christian Potzinger:
Thomas Beyer hat geschreibselt:
> TMPGEnc AC3 Encoder ist wahnsinnig schnell
Weisst du vielleicht auch wie schnell (;ungefähr)? Danke.
--
ryl: GKar
Antwort von Sven Bötcher:
Thomas Beyer schrieb:
> IMHO wirst Du mit dem Software-Echtzeitencoder von Ulead nicht glücklich
> werden. Dropped Frames wirst Du nie so niedrig halten können wie als
> MJPEG-AVI und VirtualDub, und die Qualität ist auch mieser.
Ich lese übrigens immer noch an deinem Link rum (;sehr interessant aber
auch umfangreich) und downloade mir die entsprechende Software aber eine
Frage kann ich mir einfach nicht verkneifen: Warum ist es so böse,
direkt in MPEG-2 zu capturen (;sagt eigentlich jeder) wenn nachher eine
DVD draus werden soll? Ist dann doch sowieso MPEG-2 oder nicht? Und
Dropped Frames kann ich zumindest nicht entdecken.
Bye
Sven
Antwort von Thomas Beyer:
Christian Potzinger schrieb:
> > TMPGEnc AC3 Encoder ist wahnsinnig schnell
>
> Weisst du vielleicht auch wie schnell (;ungefähr)? Danke.
Quicky: Testfile (;WAV PCM 48KHz Stereo, 5:29 min => AC3 2.0 448kb/s
-------------------------------------------------------------------
TMPGEnc AC3 Sound Plugin == 15 sec
BeSweet == 17 sec
Sonic Foundry Soft Encode == 107 sec
BeSweet ist auch schön fix im Vergleich zu Sonics Encoder, der in leicht
aktualisierter Form, aber genauso behäbig in aktuellen Sony Produkten
wie Vegas zu finden ist. Allerdings gefällt mir der Output von BeSweet
aus verschiedenen Gründen nicht (;low volume bug, kein 100% konformes
AC3).
Der große Haken am TMPGEnc AC3 Plugin: maximal Stereo. Kein 5.1.
MfG,
Thomas
Antwort von Christian Potzinger:
Thomas Beyer hat geschreibselt:
> TMPGEnc AC3 Sound Plugin == 15 sec
> BeSweet == 17 sec
> Sonic Foundry Soft Encode == 107 sec
>
> BeSweet ist auch schön fix im Vergleich zu Sonics Encoder
60 Minuten benötigen 17 Minuten (;AC3 2.0) und 56 Minuten (;AC3 5.1)
also Faktor 3.3 con AC3 2.0 zu 5.1 Getestet auf einem AMD Athlon
MP 1.2 GHz (;Dual, tut hier aber nichts zur Sache). Alles in allem
kein Vergleich zum TMPGEnc PlugIn.
> Der große Haken am TMPGEnc AC3 Plugin: maximal Stereo. Kein 5.1.
Dürfte zumindest für Privat ausreichen.
Danke.
--
ryl: GKar
Antwort von Thomas Beyer:
Sven Bötcher schrieb:
> Ich lese übrigens immer noch an deinem Link rum (;sehr interessant aber
> auch umfangreich) und downloade mir die entsprechende Software aber eine
> Frage kann ich mir einfach nicht verkneifen: Warum ist es so böse,
> direkt in MPEG-2 zu capturen (;sagt eigentlich jeder) wenn nachher eine
> DVD draus werden soll? Ist dann doch sowieso MPEG-2 oder nicht?
MPEG2 läßt sich nicht framegenau schneiden. Für den In-Cut muß man bis
zum nächsten I-Frame neu enkodieren, bei Out-Cuts darf es zusätzlich der
nächste P-Frame sein. Nur wenige Programme unterstützten *zuverlässig*
dieses sogenannte Smart Encoding, also das nur die paar Frames neu
enkodiert werden, die notwendig sind. Die Mehrzahl der üblichen
Verdächtigen beschränken sich entweder aufs ungenaue Schneiden, oder sie
enkodieren beim geringsten Konsistenzzweifel lieber alles noch mal
zeitaufwendig/qualitätsmindernd neu.
Zweiter Aspekt: Echtzeitencoder enkodieren immer im 1-Pass verfahren,
während Offlineencoder den besseren 2-Pass/N-Pass benutzen dürfen.
Einfach erklärt: beim ersten Durchlauf wird das Video analysiert, wo man
ohne sichtbaren Verlust mit der Bitrate runtergehen kann, welche man
dann in schnellen Szenen (;fast motion) wiederum hochfahren kann, um dort
die Qualität zu steigen.
Du kannst natürlich einen Echtzeitencoder auch ständig am
Bitratenmaximum der DVD fahren und so theoretisch dieselbe Qualität
erreichen wie Offlinedecoder. Neben der Tatsache, das Du so nur maximal
60min auf eine Single Layer DVD bekommst, solltest Du auch bedenken, das
bessere Offlineencoder hochwertige Filter bei der Analyse einsetzen, um
weitere Qualitätssteigerungen zu erreichen.
Um es nicht unnötig kompliziert zu machen:
Pro für MPEG2 Capturing: weniger Platzbedarf
Kontra: komplizierteres Cutten, schlechtere Qualität
MfG,
Thomas
Antwort von Thomas Beyer:
Christian Potzinger schrieb:
> > TMPGEnc AC3 Sound Plugin == 15 sec
> > BeSweet == 17 sec
> > Sonic Foundry Soft Encode == 107 sec
> >
> > BeSweet ist auch schön fix im Vergleich zu Sonics Encoder
>
> 60 Minuten benötigen 17 Minuten (;AC3 2.0) und 56 Minuten (;AC3 5.1)
> also Faktor 3.3 con AC3 2.0 zu 5.1 Getestet auf einem AMD Athlon
> MP 1.2 GHz (;Dual, tut hier aber nichts zur Sache). Alles in allem
> kein Vergleich zum TMPGEnc PlugIn.
Ok, hab hier eine 61min-WAV rumliegen, sollte also passen.
TMPEG AC3 Plugin 448kbs == 2:23 min
... direkt aus DVDLabPro heraus mit einem PIV 2.8GHz (;Northwood)
enkodiert. Scheint ziemlich heftig auf Intel optimiert zu sein.
> > Der große Haken am TMPGEnc AC3 Plugin: maximal Stereo. Kein 5.1.
>
> Dürfte zumindest für Privat ausreichen.
Sehe ich auch so. Ich habe noch nie das Bedürfnis gehabt, 5 Mikrofone
aufzubauen und Subwoovergrummeln abzumischen ;-).
Gruss,
Thomas
Antwort von Christian Potzinger:
Thomas Beyer hat geschreibselt:
>> 60 Minuten benötigen 17 Minuten (;AC3 2.0) und 56 Minuten (;AC3 5.1)
> Ok, hab hier eine 61min-WAV rumliegen, sollte also passen.
>
> TMPEG AC3 Plugin 448kbs == 2:23 min
>
> ... direkt aus DVDLabPro heraus mit einem PIV 2.8GHz (;Northwood)
> enkodiert. Scheint ziemlich heftig auf Intel optimiert zu sein.
Ups, mein Fehler. Meine Zeitangaben beziehen sich auf Sonics
SoftEncode! Deine 5:29 Datei in AC3 2.0 (;448k) = 107 sec.
benötigen auf meinem Rechner 94 sec. Und das auf einem
1.2 GHz Rechner im Vergleich zu deinem P4. Da scheint
itgendwas nicht zu stimmen. Ich werde morgen mal ein
5 minütiges Testfile encoden.
btw: Bei einem 60min. File macht der Unterschied ob mit 224k
od. mit 640k encoded nicht mal eine Minute beim berechnen aus.
>> Dürfte zumindest für Privat ausreichen.
>
> Sehe ich auch so. Ich habe noch nie das Bedürfnis gehabt, 5 Mikrofone
> aufzubauen und Subwoovergrummeln abzumischen ;-).
Wieso nicht? ;) Gaaanz selten wird 5.1 benötigt. Z.b. meine
Abmischung der Musik aus dem Spiel "Unreal" ist ein Hochgenuß :)
--
ryl: GKar
Antwort von Thomas Beyer:
Christian Potzinger schrieb:
> Ups, mein Fehler. Meine Zeitangaben beziehen sich auf Sonics
> SoftEncode! Deine 5:29 Datei in AC3 2.0 (;448k) = 107 sec.
> benötigen auf meinem Rechner 94 sec. Und das auf einem
> 1.2 GHz Rechner im Vergleich zu deinem P4. Da scheint
> itgendwas nicht zu stimmen. Ich werde morgen mal ein
> 5 minütiges Testfile encoden.
Der Encoder muss erst mal richtig in Fahrt kommen, bei lediglich ein
paar Sekunden ist er unterfordert ;-).
> btw: Bei einem 60min. File macht der Unterschied ob mit 224k
> od. mit 640k encoded nicht mal eine Minute beim berechnen aus.
Dito.
> > Sehe ich auch so. Ich habe noch nie das Bedürfnis gehabt, 5 Mikrofone
> > aufzubauen und Subwoovergrummeln abzumischen ;-).
>
> Wieso nicht? ;) Gaaanz selten wird 5.1 benötigt. Z.b. meine
> Abmischung der Musik aus dem Spiel "Unreal" ist ein Hochgenuß :)
Was sagt Michiel van den Bos dazu?
Grüsse,
Thomas
Antwort von Christian Potzinger:
Thomas Beyer hat geschreibselt:
> Der Encoder muss erst mal richtig in Fahrt kommen, bei
> lediglich ein paar Sekunden ist er unterfordert ;-).
Du willst bloß nicht zugeben, dass meiner grö^W^Wschneller ist ;)
Here are the final Results: 5:00min 48kHz WAV
AC3 2.0 448k (;Stereo, nicht DPL encoded): 100sec.
AC3 5.1 448k 248 sec.
>> Wieso nicht? ;) Gaaanz selten wird 5.1 benötigt. Z.b. meine
>> Abmischung der Musik aus dem Spiel "Unreal" ist ein Hochgenuß :)
>
> Was sagt Michiel van den Bos dazu?
Warum sollte ich wissen was der dazu sagt?
So, für heute heisst es "Nacht ist".
--
ryl: GKar
Antwort von Benjamin Grund:
Am 16.März 2006, 20:12 schrieb Thomas Beyer:
> BTW, analoges Capturing ist old school. Heutzutage ist es ja hipp,
> gleich mit hoch komprimierenden Formaten (;MPEG2, MPEG4-AVC, DivX) in
> Echtzeit enkodieren zu wollen. Alle diese Formate haben nur eines zur
> Folge: Die anschließende Nachbearbeitung (;Cuts, finale Enkodierung als
> DVD ...) wird unnötig erschwert, weil diese Formate Endformate sind.
Für was noch eine finale Enkodierung, wenn bereits in MPEG2 aufgenommen
wird? Da ist höchstens noch eine Neukodierung an den Schnittpunkten
nötig, mehr nicht.
> Sprich: Zur weiteren Nachbearbeitung eher ungeeignet.
Ich nehme mit meiner Hauppauge WinTV PVR150 direkt in DVD-tauglichem
MPEG2 auf und bearbeite das ganze dann mit VideoRedo nach. Einfacher
geht es nun wirklich nicht. Da ist der Umweg über z.B. MJPEG deutlich
umständlicher und komplizierter.
Gruß,
Benjamin
Antwort von Martin Hillebrand:
Benjamin Grund schrieb:
> Am 16.März 2006, 20:12 schrieb Thomas Beyer:
>
>> BTW, analoges Capturing ist old school. Heutzutage ist es ja hipp,
>> gleich mit hoch komprimierenden Formaten (;MPEG2, MPEG4-AVC, DivX) in
>> Echtzeit enkodieren zu wollen. Alle diese Formate haben nur eines zur
>> Folge: Die anschließende Nachbearbeitung (;Cuts, finale Enkodierung als
>> DVD ...) wird unnötig erschwert, weil diese Formate Endformate sind.
>
> Für was noch eine finale Enkodierung, wenn bereits in MPEG2 aufgenommen
> wird? Da ist höchstens noch eine Neukodierung an den Schnittpunkten
> nötig, mehr nicht.
Im Idealfall ja. Manch dummes Programm meint aber, nach dem Schnitt den
ganzen Streifen neu codieren zu müssen, weil es das sog. "Smart
Rendering" nicht beherrscht.
Dann nochmal: Jegliche Art von Re-Codierung von sog. "Endformaten" bring
Qualitätsverluste. Zwangsläufig.
Wenn man DV AVI nimmt, dann ist das im Prinzip nix anderes als MJPEG,
d.h. lauter I-Frames. Da ergibt sich durch schneiden kein Qualitätsverlust.
Offline Codierung hat dazu die bereits angesprochenen Vorteile.
>> Sprich: Zur weiteren Nachbearbeitung eher ungeeignet.
>
> Ich nehme mit meiner Hauppauge WinTV PVR150 direkt in DVD-tauglichem
> MPEG2 auf und bearbeite das ganze dann mit VideoRedo nach. Einfacher
> geht es nun wirklich nicht.
Aber unter Umständen qualitativ besser, wenn man den "langen" Weg nimmt.
> Da ist der Umweg über z.B. MJPEG deutlich
> umständlicher und komplizierter.
Aber unter Umständen qualitativ um Klassen besser. Je nachdem, was man
für Ausgangsmaterial und für Ansprüche an das Endformat hat.
Gruß
Martin.
Antwort von Sven Bötcher:
Thomas Beyer schrieb:
> Sven Bötcher schrieb:
>
>> Ich lese übrigens immer noch an deinem Link rum (;sehr interessant aber
>> auch umfangreich) und downloade mir die entsprechende Software aber eine
>> Frage kann ich mir einfach nicht verkneifen: Warum ist es so böse,
>> direkt in MPEG-2 zu capturen (;sagt eigentlich jeder) wenn nachher eine
>> DVD draus werden soll? Ist dann doch sowieso MPEG-2 oder nicht?
> Pro für MPEG2 Capturing: weniger Platzbedarf
> Kontra: komplizierteres Cutten, schlechtere Qualität
Das war mal ne tolle ausführliche Erklärung mit einem verständlichen Fazit.
Bye
Sven
Antwort von Sven Bötcher:
Martin Hillebrand schrieb:
> Wenn man DV AVI nimmt, dann ist das im Prinzip nix anderes als MJPEG,
> d.h. lauter I-Frames. Da ergibt sich durch schneiden kein Qualitätsverlust.
Wenn ich im UVS 9 "DV" als Format anwähle, kommt ein realtiv grosses AVI
bei raus. Ist es das, was du hier grade beschreibst? Dann könnte ich in
diesem Format aufnehmen.
Bye
Sven
Antwort von Benjamin Grund:
Am 17.März 2006, 11:31 schrieb Martin Hillebrand:
> Im Idealfall ja. Manch dummes Programm meint aber, nach dem Schnitt den
> ganzen Streifen neu codieren zu müssen, weil es das sog. "Smart
> Rendering" nicht beherrscht.
Das ist dann aber ein Problem des gewählten Programmes und nicht des
gewählten Formates. Mit einem schlechten Programm lässt sich so ziemlich
jedes Format verhunzen.
> Dann nochmal: Jegliche Art von Re-Codierung von sog. "Endformaten" bring
> Qualitätsverluste. Zwangsläufig.
Klar, aber eine komplette Rekodierung ist ja bei MPEG2 normalerweise
nicht erforderlich und die bei bildgenauem Schnitt fällige Neukodierung
an den Schnittstellen fällt bei VideoRedo absolut nicht auf. Da merkt
man beim späteren Anschauen nichtmal mehr, dass da was rausgeschnitten
wurde.
> Wenn man DV AVI nimmt, dann ist das im Prinzip nix anderes als MJPEG,
> d.h. lauter I-Frames. Da ergibt sich durch schneiden kein Qualitätsverlust.
Wenn man bei MPEG2 nur an den I-Frames schneidet, hat man auch da keinen
Qualitätsverlust.
> Aber unter Umständen qualitativ besser, wenn man den "langen" Weg nimmt.
Ich glaube kaum, dass Du beim "langen" Weg bessere Ergebnisse als mit
einer TV-Karte mit MPEG2-Hardware-Encoder erzielen kannst.
> Aber unter Umständen qualitativ um Klassen besser. Je nachdem, was man
> für Ausgangsmaterial und für Ansprüche an das Endformat hat.
Wir reden hier ja von der Aufnahme von analogem Fernsehen und da wirst
Du mit MJPEG oder anderen Codecs keine besseren Ergebnisse als mit einer
TV-Karte mit Hardware-MPEG2-Encoder erzielen können, denn dazu ist das
Ausgangsmaterial bereits zu schlecht. Warum sollte man also den langen
und mühseligen Weg wählen, wenn es auch einfach und bequem geht?
Gruß,
Benjamin
Antwort von Martin Hillebrand:
Hallo
Benjamin Grund schrieb:
> Am 17.März 2006, 11:31 schrieb Martin Hillebrand:
>
>> Im Idealfall ja. Manch dummes Programm meint aber, nach dem Schnitt den
>> ganzen Streifen neu codieren zu müssen, weil es das sog. "Smart
>> Rendering" nicht beherrscht.
>
> Das ist dann aber ein Problem des gewählten Programmes und nicht des
> gewählten Formates. Mit einem schlechten Programm lässt sich so ziemlich
> jedes Format verhunzen.
Da stimme ich dir zu. Nur ist die Anzahl der Programme, die Smart
Rendering beherrschen gegenüber denen, die es nicht beherrschen in der
Unterzahl. Schlicht, weil es komplexer zu implementieren ist.
> [...]
>> Wenn man DV AVI nimmt, dann ist das im Prinzip nix anderes als MJPEG,
>> d.h. lauter I-Frames. Da ergibt sich durch schneiden kein Qualitätsverlust.
>
> Wenn man bei MPEG2 nur an den I-Frames schneidet, hat man auch da keinen
> Qualitätsverlust.
Das will man aber meistens eben nicht. Man muss meist ja irgendwo in der
GOP schneiden. Und dann ist das neue zusammenrendern der zwei
angeschnittenen GOPs unumgänlich.
>> Aber unter Umständen qualitativ besser, wenn man den "langen" Weg nimmt.
>
> Ich glaube kaum, dass Du beim "langen" Weg bessere Ergebnisse als mit
> einer TV-Karte mit MPEG2-Hardware-Encoder erzielen kannst.
Wenn Du natürlich nur schrottiges analoges Kabel aufzeichnest, kann das
gut sein. Allerdings will der OP von einer Digicam was übertragen. Da
ist hoffentlich das Material etwas besser.
>> Aber unter Umständen qualitativ um Klassen besser. Je nachdem, was man
>> für Ausgangsmaterial und für Ansprüche an das Endformat hat.
>
> Wir reden hier ja von der Aufnahme von analogem Fernsehen
Nein. Der OP will von seiner digitalen Videokamera etwas übertragen. Bei
analogem Kabel magst Du recht haben - wie ich letztens wieder bei einem
Freund mit eben diesem System erfahren musste.
> und da wirst
> Du mit MJPEG oder anderen Codecs keine besseren Ergebnisse als mit einer
> TV-Karte mit Hardware-MPEG2-Encoder erzielen können,
Mir fehlt der Vergleich mit einer Hardwarecapturekarte. Aber eben so
eine kann beispielsweise prinzipbedingt kein N-Pass Verfahren zum
rendern verwenden, was einen enormen Qualitätsschub gegenüber 1Pass
verfahren bedeutet.
> denn dazu ist das
> Ausgangsmaterial bereits zu schlecht.
ACK.
> Warum sollte man also den langen
> und mühseligen Weg wählen, wenn es auch einfach und bequem geht?
Weil er gutes Ausgangsmaterial hat.
Gruß
Martin.
Antwort von Martin Hillebrand:
Hallo Sven.
Sven Bötcher schrieb:
> Wenn ich im UVS 9 "DV" als Format anwähle, kommt ein realtiv grosses AVI
> bei raus.
Jepp. Das ist so.
> Ist es das, was du hier grade beschreibst? Dann könnte ich in
> diesem Format aufnehmen.
Genau. Versuch es doch einfach mal.
Gruß
Martin.
Antwort von Thomas Beyer:
Benjamin Grund schrieb:
> Ich nehme mit meiner Hauppauge WinTV PVR150 direkt in DVD-tauglichem
> MPEG2 auf und bearbeite das ganze dann mit VideoRedo nach. Einfacher
> geht es nun wirklich nicht. Da ist der Umweg über z.B. MJPEG deutlich
> umständlicher und komplizierter.
tv video ist voll von Leuten, die Probleme mit der Weiterverarbeitung
von angeknacksten MPEG2 Streams haben ;-)
Der OP wollte MPEG2 mit einer Software-Engine (;Ulead) aufnehmen, nicht
mit einem Hardwareencoder. Da potenzieren sich die Probleme nochmals.
Und das man bei der Hauppauge das MPEG2 als DVD-konform betrachtet liegt
nur daran, das heutige Standalones ziemlich tolerant sind. Stopf eine so
erzeugte DVD mal in eine Zicke wie den Pioneer 343. Da enkodiere ich
doch lieber gleich mit guter Software offline, da kann ich wenigstens
parametrisieren und closed GOPS erzeugen.
Weiterer Vorteil beim "Umweg" über DV/MJpeg AVI: Ich kann gemütlich
skalieren. Fallbeispiel: 16:9 letterboxed Material. Bei meiner
Arbeitsweise schnippelt man die schwarzen Ränder halt weg und enkodiert
anamorph.
Gruß,
Thomas
Antwort von Benjamin Grund:
Am 17.März 2006, 12:58 schrieb Martin Hillebrand:
> Nein. Der OP will von seiner digitalen Videokamera etwas übertragen.
Sicher? Im Posting des OP steht nur, dass er mit einer TV-Karte Videos
aufnehmen möchte. Von daher bin ich mal davon ausgegangen, dass er damit
die Aufnahme von analogem Fernsehen meint.
Und bei einer digitalen Videokamera würde der Umweg über eine TV-Karte
ja sowieso nur wenigSinn machen, denn da lässt sich das Material ja in
der Regel auf digitalem Weg übertragen.
> Weil er gutes Ausgangsmaterial hat.
Da wäre ich mir nicht so sicher.
Gruß,
Benjamin
Antwort von Martin Hillebrand:
Benjamin Grund schrieb:
> Am 17.März 2006, 12:58 schrieb Martin Hillebrand:
>
>> Nein. Der OP will von seiner digitalen Videokamera etwas übertragen.
>
> Sicher? [...]
Urgs! Nein :-(;
Ich nehme alles zurück... Da bin ich wohl im Posting verrutscht....
Danke für den Hinweis.
Gruß
Martin.
Antwort von Sven Bötcher:
Martin Hillebrand schrieb:
> Hallo Sven.
>
> Sven Bötcher schrieb:
>> Wenn ich im UVS 9 "DV" als Format anwähle, kommt ein realtiv grosses AVI
>> bei raus.
>
> Jepp. Das ist so.
>
>> Ist es das, was du hier grade beschreibst? Dann könnte ich in
>> diesem Format aufnehmen.
>
> Genau. Versuch es doch einfach mal.
Die Bildqualität wird besonders an den Rändern von dargestellten
Objekten weniger klotzig, also deutlich besser. Allerdings werden die
Dateien wirklich sehr gross und ich habe ab und an dünne, weisse,
waagerechte Streifen im Bild. :-(; Echt schwierig zur perfekten Aufnahme
einer analogen Quelle zu kommen.
Bye
Sven
Antwort von Sven Bötcher:
Benjamin Grund schrieb:
> Am 17.März 2006, 12:58 schrieb Martin Hillebrand:
>
>> Nein. Der OP will von seiner digitalen Videokamera etwas übertragen.
>
> Sicher? Im Posting des OP steht nur, dass er mit einer TV-Karte Videos
> aufnehmen möchte. Von daher bin ich mal davon ausgegangen, dass er damit
> die Aufnahme von analogem Fernsehen meint.
So ist es. Und nehme ich direkt in MPEG-2 auf, ist die Bildqualität doch
schlechter als im DV/AVI-Format. Auf einem einfachen Fernseher und mit
dem dort üblichen Sitzabstand sieht man es gar nicht so sehr aber auf
dem Computer-Monitor doch recht deutlich. Schade. :-(;
Bye
Sven
Antwort von Sven Bötcher:
Thomas Beyer schrieb:
> Sven Bötcher schrieb:
>
>>> Du hast Dich zwar über die Hardware ausgelassen, aber ich vermute, dass
>>> die monierten dropped frames bei Dir durch den Einsatz untauglicher
>>> Audio/Videocodecs zustandekommen.
>> Eigentlich nur das, was beim UleadVideoStudio dabei war.
>
> Ich kenne nur Ulead Media Studio. Dort kann man fürs Capturing entweder
> die MPEG2 Engine oder die Directshow Engine nehmen. Ersteres würde ich
> niemals benutzen, bei Letzterem kommt es auf die Wahl des Codecs an
> (;AVI), inwieweit das Ergebnis brauchbar ist.
>
> Versuch aber besser VirtualDub zu verwenden. Mehr
> Optimierungsmöglichkeiten, besseres Programm zum Capturen.
Kann es sein, dass die aktuelle Version ganz anders aussieht? Ich finde
viele der von dir beschriebenen Funktionen, Einstellungen und Formate
gar nicht.
Bye
Sven
Antwort von Heiko Nocon:
Sven Bötcher wrote:
>und ich habe ab und an dünne, weisse,
>waagerechte Streifen im Bild.
Sicher ein VIA-Chipsatz auf dem Motherboard.
Ich habe einen VirtualDub-Filter geschrieben, der diese Produkte der
permanenten VIA-Inkompetenz in Sachen PCI recht gut reparieren kann.
Allerdings kann er das nur bei progressivem Material, bei interlaced muß
er leider passen (;weil ich bisher keine Lust hatte, die Unterstützung
dafür einzubauen, weil mich eigentlich nur progressives Material
interessiert).
Jedenfalls würde er derzeit interlaced Material massiv kaputtreparieren
und das Ergebnis sähe echt grausig aus.
Antwort von Thomas Beyer:
Heiko Nocon schrieb:
> Sven Bötcher wrote:
>
> >und ich habe ab und an dünne, weisse,
> >waagerechte Streifen im Bild.
>
> Sicher ein VIA-Chipsatz auf dem Motherboard.
Ganz sicher. Für die Aussage "VIA taugt für analoges Videocapturing
nichts" habe ich vor drei Jahren hier noch Prügel ohne Ende eingesteckt
;-).
> Ich habe einen VirtualDub-Filter geschrieben, der diese Produkte der
> permanenten VIA-Inkompetenz in Sachen PCI recht gut reparieren kann.
Ich würde als erste Preventivmaßnaheme erst mal die PCI Latency im BIOS
des Motherboards erhöhen. Beim Asus A7V ging mein Masochismus so weit,
dass ich eigene BIOS Routinen geschrieben habe (;dynamic priority), dann
gings reibungslos.
Aus heutiger Sicht ist es besser, ein solches Board gleich zu
verschrotten oder einem Einsatzzweck zuzuführen, welches weit entfernt
ist von allem, was PCI Performance benötigt (;RAID, SCSI, Video ...)
Grüsse,
Thomas
Antwort von Thomas Beyer:
Sven Bötcher schrieb:
> > Sicher? Im Posting des OP steht nur, dass er mit einer TV-Karte Videos
> > aufnehmen möchte. Von daher bin ich mal davon ausgegangen, dass er damit
> > die Aufnahme von analogem Fernsehen meint.
>
> So ist es. Und nehme ich direkt in MPEG-2 auf, ist die Bildqualität doch
> schlechter als im DV/AVI-Format. Auf einem einfachen Fernseher und mit
> dem dort üblichen Sitzabstand sieht man es gar nicht so sehr aber auf
> dem Computer-Monitor doch recht deutlich. Schade. :-(;
Alles andere hätte mich auch sehr gewundert ;-). Erschwerend kommt bei
Deinem VIA Chipset dazu, dass die visuellen Störungen (;Peaks) vermehrt
auftreten, wenn die CPU gut zu tun hat. Und das hat sie bei MPEG
Encoding zweifelsohne mehr als bei MJPEG.
MfG,
Thomas
Antwort von Heiko Nocon:
Thomas Beyer wrote:
>Ich würde als erste Preventivmaßnaheme erst mal die PCI Latency im BIOS
>des Motherboards erhöhen.
Das senkt leider nur die Wahrscheinlichkeit für das Auftauchen des
Streifeneffektes, verhindert ihn aber nicht gänzlich. Trotzdem ist es
natürlich eine überaus sinnvolle Maßnahme. Je weniger Fehler zu
reparieren sind, desto besser.
Allerdings können zu hohe Latenzen wiederum die Arbeit anderer Geräte
negativ beeinflussen. Bei mir (;K7VTA4pro) produziert z.B. der
onboard-Sound bei einer für den BT878 ziemlich schicken Latenz von 224
Takten mit einer recht hohen Häufigkeit lästige Knackser.
Diese Scheiße nervt. Ich hatte echt geglaubt, daß VIA das endlich in den
Griff bekommen hätte, denn beim KT600-basierten Board eines Bekannten
gab es diesbezüglich (;scheinbar) keinerlei Probleme. Als einige Wochen
später bei mir eine Umrüstung anstand, war genau das Board beim lokalen
Dealer leider aus und ich habe ersatzweise diesen KT400B-Kram gekauft.
Das war eine Scheiß-Entscheidung.
Die Frustration milderte sich dann aber insofern, als das bei besagtem
Bekannten nach einiger Zeit auch die bekannten Effekte auftraten.
Wahrscheinlich hatte ich anfangs einfach nur nicht genau genug geguckt.
Ich hätte wohl einfach konsequent die zu KT133A-Zeiten erworbenen
Erkenntnisse anwenden sollen: VIA%Vollrotz. Nicht kaufen.
Mittlerweile sehne ich mich nach dem im Zuge der Umrüstung abgelösten
K7S5A zurück. Schade, daß das mit Barton-CPUs nicht umgehen kann, sonst
würde ich es glatt wieder aus dem Rechner extrahieren, den ich meiner
Schwester geschenkt habe...
Antwort von Sven Bötcher:
Heiko Nocon schrieb:
> Sven Bötcher wrote:
>
>> und ich habe ab und an dünne, weisse,
>> waagerechte Streifen im Bild.
>
> Sicher ein VIA-Chipsatz auf dem Motherboard.
Bitte nicht schimpfen, ist unwürdiger KT266A. :-(;
Sonst läuft doch alles hier, was hat denn der Chipsatz mit Bildfehlern
zu tun? Und wieso macht er es nicht bei MPEG-2? Wieviele Hindernisse auf
dem Weg zur Videoaufnahme gibt es denn sonst noch?
Bye
Sven
Antwort von Sven Bötcher:
Thomas Beyer schrieb:
> Sven Bötcher schrieb:
>
>>> Sicher? Im Posting des OP steht nur, dass er mit einer TV-Karte Videos
>>> aufnehmen möchte. Von daher bin ich mal davon ausgegangen, dass er damit
>>> die Aufnahme von analogem Fernsehen meint.
>> So ist es. Und nehme ich direkt in MPEG-2 auf, ist die Bildqualität doch
>> schlechter als im DV/AVI-Format. Auf einem einfachen Fernseher und mit
>> dem dort üblichen Sitzabstand sieht man es gar nicht so sehr aber auf
>> dem Computer-Monitor doch recht deutlich. Schade. :-(;
>
> Alles andere hätte mich auch sehr gewundert ;-). Erschwerend kommt bei
> Deinem VIA Chipset dazu, dass die visuellen Störungen (;Peaks) vermehrt
> auftreten, wenn die CPU gut zu tun hat. Und das hat sie bei MPEG
> Encoding zweifelsohne mehr als bei MJPEG.
Das geht mir mittlerweile alles tierisch auf den Sack. Ich will doch nur
ne Videoaufnahme haben und nicht den Weltraum bereisen. Mein
Aldi-Notebook macht das mit seiner TV-Karte und einer bereits
installierten Multimediasoftware (;Cyberlink Home Cinema) problemlos ohne
dass ich irgendetwas einstellen muss in einer tollen Qualität.
Bye
Sven
Antwort von Lars Mueller:
Benjamin Grund wrote:
>
> Am 17.März 2006, 12:58 schrieb Martin Hillebrand:
>
> > Nein. Der OP will von seiner digitalen Videokamera etwas übertragen.
>
> Sicher? Im Posting des OP steht nur, dass er mit einer TV-Karte Videos
> aufnehmen möchte. Von daher bin ich mal davon ausgegangen, dass er damit
> die Aufnahme von analogem Fernsehen meint.
Genau so stand es im Text und in der Überschrift auch! ;-)
|Ich möchte mit einer analogen TV-Karte (;Miro/Pinnacle PCTV Pro,BT848)
|Videos aufnehmen, die später als DVD gebrannt werden sollen."
Gruß Lars
(;Ein Leerzeichen habe ich geklaut)
Antwort von Heiko Nocon:
Sven Bötcher wrote:
>Sonst läuft doch alles hier, was hat denn der Chipsatz mit Bildfehlern
>zu tun?
Das Problem ist eine extrem "kostenoptimierte" Implementierung des
PCI-Bus bei offensichtlich allen VIA-Chipsätzen. Die Arschlöcher haben
einfach ein paar dutzend Byte schnellen Pufferspeichers und die
Ansteuerlogik dafür eingespart. Gesparte Kosten pro Chipsatzexemplar
vielleicht maximal ein paar lausige stinkende Scheiß-Eurocent.
Dadurch wird es aber praktisch unmöglich, einen Kompromiß zwischen
Geräten mit hoher Buslast, aber nur mäßigen Echtzeitforderungen
(;HD-Controller) und Geräten mit mittlerer bis geringer Buslast, aber
sehr strengen Echtzeitforderungen (;Video- und Audiocapture) zu finden.
Entweder reduziert man die Bandbreite der HD-Controller auf Werte, die
die allgemeine Performance des Systems sehr negativ beeinflussen oder
man lebt mit Aussetzern bei den Echtzeitgeräten.
Die Boardhersteller neigen dazu, die HD-Controller zu bevorzugen, denn
die HD-Perfomance ist, was bei Testberichten als erstes negativ
hervorsticht. Der Erfolg ist, daß es Aussetzer bei Geräten mit strenger
Echtzeitbindung gibt. Bei analogem Videocapture sind es halt Streifen in
Falschfarben, bei Audio eklige Knackser. Bei DV-Capture ist es noch
schlimmer, denn da gibt's gleich ganze kaputte Frames, die der Treiber
im günstigsten Fall dropped, im ungünstigsten Fall aber, mit ein paar
Quasi-Zufallszahlen ergänzt, weiterreicht.
Es ist von diesem Problem also keinesfalls ausschließlich das anloge
Videocapturing betroffen. Da bemerkt man es nur am ehesten.
Antwort von Sven Bötcher:
Heiko Nocon schrieb:
> Sven Bötcher wrote:
>
>> Sonst läuft doch alles hier, was hat denn der Chipsatz mit Bildfehlern
>> zu tun?
>
> Das Problem ist eine extrem "kostenoptimierte" Implementierung des
> PCI-Bus bei offensichtlich allen VIA-Chipsätzen. Die Arschlöcher haben
> einfach ein paar dutzend Byte schnellen Pufferspeichers und die
> Ansteuerlogik dafür eingespart. Gesparte Kosten pro Chipsatzexemplar
> vielleicht maximal ein paar lausige stinkende Scheiß-Eurocent.
Mann, du klingst ja dermassen angepisst, als hättest du selber einen
VIA-Chipsatz!
Kann man mit nem Nforce2-Chipsatz was werden beim Capturing oder sieht
es da ähnlich aus?
Bye
Sven
Antwort von Georg Lutz:
Benjamin Grund schrieb:
>
> Wenn man bei MPEG2 nur an den I-Frames schneidet, hat man auch da keinen
> Qualitätsverlust.
>
Ich würde sogar behaupten, daß man - egal wo man in einer GOP den
Schnitt ansetzt - mit einem intelligenten Schnittprogramm überhaupt
keinen Qualitätsverlust haben muß.
Bei einem P- oder B-Frame werden ja nur die Differenzinformationen
gespeichert. Und die Kodierung der Differenzinformation selbst erfolgt
verlustlos, d.h. es müsste möglich sein, aus einem B/P-Frame verlustlos
wieder ein I-Frame zu machen. Bitte korrigiert mich, falls ich da
falschliege!
--
Georg
Antwort von Günter Thaler:
Benjamin Grund schrieb:
> Ich nehme mit meiner Hauppauge WinTV PVR150 direkt in DVD-tauglichem
> MPEG2 auf und bearbeite das ganze dann mit VideoRedo nach.
Du demuxt nicht vor dem Schnitt? Hast du keine Asynchronität (;Bild/Ton)?
lg Günter
Antwort von Benjamin Grund:
Am 21.März 2006, 11:53 schrieb Günter Thaler:
> Du demuxt nicht vor dem Schnitt?
Nein, bei VideoRedo ist das nicht nötig. Gerade das hebt VideoRedo ja
von kostenlosen Schnittprogrammen wie MPEG2Schnitt oder Cuttermaran ab.
> Hast du keine Asynchronität (;Bild/Ton)?
Nein, da hatte ich bis jetzt keinerlei Probleme.
Gruß,
Benjamin
Antwort von Lars Mueller:
Benjamin Grund wrote:
>
> Am 21.März 2006, 11:53 schrieb Günter Thaler:
>
> > Du demuxt nicht vor dem Schnitt?
>
> Nein, bei VideoRedo ist das nicht nötig. Gerade das hebt VideoRedo ja
> von kostenlosen Schnittprogrammen wie MPEG2Schnitt oder Cuttermaran ab.
Und ich verstehe immer noch nicht, warum das angeblich unbedingt
notwendig sein sollte. Der Versatz zwischen Bild und Ton kann doch
allenfalls ein paar MB betragen, die man loccker im Speicher vorhalten
könnte.
> > Hast du keine Asynchronität (;Bild/Ton)?
>
> Nein, da hatte ich bis jetzt keinerlei Probleme.
Siehe oben. :-)
Gruß Lars
Antwort von Günter Thaler:
Benjamin Grund schrieb:
>>Du demuxt nicht vor dem Schnitt?
> Nein, bei VideoRedo ist das nicht nötig. Gerade das hebt VideoRedo ja
> von kostenlosen Schnittprogrammen wie MPEG2Schnitt oder Cuttermaran ab.
Mich frisst der Neid. VideRedo ist wirklich oraktisch, nur habe ich dann
-- und zwar je mehr ich schneide (;nicht nur vor und nach dem Film,
sondern auch Werbung aus dem Film heraus) -- direse störende
Asynchronität. Sonst wärs so praktisch: schneiden mit Videredo, dann
Authoring mit Filmbrennerei.
(;Auch letzteres geht nicht, oft stürzt das Programm beim Compilieren ab,
oder die gebrannte DVD wird von meinem Standalone nicht erkannt.
(;Vielleicht liegt mein Problem hauptsächlich daran, dass mein Standalone
kritischer ist).
lg Günter
Antwort von Detlef Wirsing:
Günter Thaler schrieb am 21. März:
> Benjamin Grund schrieb:
>
> >>Du demuxt nicht vor dem Schnitt?
> > Nein, bei VideoRedo ist das nicht nötig. Gerade das hebt VideoRedo ja
> > von kostenlosen Schnittprogrammen wie MPEG2Schnitt oder Cuttermaran ab.
>
> Mich frisst der Neid. VideRedo ist wirklich oraktisch, nur habe ich dann
> -- und zwar je mehr ich schneide (;nicht nur vor und nach dem Film,
> sondern auch Werbung aus dem Film heraus) -- direse störende
> Asynchronität.
[...]
Probier es mal ersatzweise mit Wombles MPEG2VCR oder dem Nachfolger
Video Wizard. Vielleicht klappt das bei Dir besser. Jedenfalls
schneide ich mit dem ersten seit Jahren ohne Asynchronitäten meine
eigenen DVB-Aufnahmen. Den Video Wizard habe ich inzwischen ebenfalls
erfolgreich getestet. Allerdings kosten beide Programme Geld.
Testversionen: www.womble.com
Mit freundlichen Grüßen
Detlef
Antwort von Andre Beck:
Georg Lutz
writes:
> Benjamin Grund schrieb:
>> Wenn man bei MPEG2 nur an den I-Frames schneidet, hat man auch da
>> keinen
>> Qualitätsverlust.
>>
>
> Ich würde sogar behaupten, daß man - egal wo man in einer GOP den
> Schnitt ansetzt - mit einem intelligenten Schnittprogramm überhaupt
> keinen Qualitätsverlust haben muß.
Leider hält sich die Realität nicht notwendigerweise an unsere
Erwartungen ;)
> Bei einem P- oder B-Frame werden ja nur die Differenzinformationen
> gespeichert.
Nein. Bei einem P/B werden *auch* Differenzinformationen gespeichert.
Meistens sind relativ viele der Makroblöcke in einem P-Frame auch
wirklich P-MBs und in einem B-Frame tummeln sich vermehrt auch B-MBs,
es gibt aber auch meist eine ganze Anzahl I-MBs darin.
> Und die Kodierung der Differenzinformation selbst erfolgt
> verlustlos,
Nein, auch diese Differenz-Koeffizienten werden (;AFAIK) quantisiert.
> d.h. es müsste möglich sein, aus einem B/P-Frame
> verlustlos wieder ein I-Frame zu machen. Bitte korrigiert mich, falls
> ich da falschliege!
Verlustlos ist hier eine komplizierte Frage. Einfach ist es auf jeden
Fall nicht, weil man B/P-MBs nicht in ein I-Frame übernehmen darf. Man
müsste sie in I-MBs überführen. Ich will jetzt aber nicht ausschließen,
dass das verlustfrei möglich sein kann, auch wenn es Probleme mit Run-
dungsartefakten¹ geben wird². Der Haken an der Sache (;und an jedem wie
auch immer gearteten Versuch, MPEG2 InPlace zu schneiden) ist, dass das
neue I-Frame, wenn es denn verlustfrei die ehemaligen Daten aus einer
P/B-Kette übermitteln soll, verflucht viel größer wird als die Frames
die vorher an dieser Stelle saßen. In der Folge verletzt der so erzeugte
Stream mit ziemlicher Sicherheit die Bandbreiten- und vor allem VBV-
Limits, die er eigentlich zusagt, und ist damit schlicht auf kompli-
zierte Weise defekt. Was sich dann auf Decodern, die sich wirklich auf
diese Zusagen und die Standards und Profiles/Levels verlassen, in mehr
oder weniger heftigen Störungen niederschlägt. Deswegen gibt es halt
die defensive Position, die einfach sagt "man kann MPEG2 nicht schneiden,
weil das nicht verlustlos an jedem Frame geht, und genau das wäre die
Bedeutung von *Schneiden*, PUNKT" - und die Gegenposition von Software-
herstellern, die keinen Aufwand scheuen, eine partielle Recodierung (;die
sich wegen des oben erwähnten Dilemmas aber über mehrere Frames, ja GOPs
und manchmal ziemlich lange Abschnitte erstrecken wird und dort dann auch
zu Neuquantisierung führt) zu implementieren und zu tunen und das Resultat
dann "Schneiden" zu nennen, obwohl es die Wortbedeutung konterkariert.
¹) Naja, was ist Quantisierung anderes als ein Rundungsartefakt.
²) Wenn ich das richtig überblicke, muss man die Referenz des Motion
Vector ermitteln (;was im Sinne der bereits vorliegenden Daten verlust-
frei ist) und dann den Differenz-Koeffizientensatz dazu addieren. Das
Resultat gerät dabei mit ziemlicher Wahrscheinlichkeit außerhalb des
Quantisierungsrasters des ursprünglichen Differenz-Koeffizientensatzes
und erfährt daher bei der Umverpackung in einen I-MB eine erneute
Quantisierung. Dabei geht gegenüber dem vom Decoder aus dem Urmaterial
darstellbaren Bild etwas verloren, also ist der Vorgang nicht verlust-
los. Die Referenz des MV kann dabei eine sehr komplizierte Geschichte
haben, z.B. kann sie vier P-Frames hinter dem letzten I-Frame liegen
*und* noch dazu vier MB in diesem Frame überdecken, die alle eine unter-
schiedliche Quantisierungshistorie aufweisen. Der Idealfall wäre eine
Referenz auf ein I-Frame mit gleicher Quantisierung für alle refe-
renzierten MB, dann käme die Summe tatsächlich weitgehend verlustfrei
in den I-MB, denn sie träfe genau die Quantisierungsstufen. Aber das
vorauszusetzen ist wohl eher unrealistisch.
--
The S anta C laus O peration
or "how to turn a complete illusion into a neverending money source"
-> Andre "ABPSoft" Beck ABP-RIPE Dresden, Germany, Spacetime <-
