Frage von Peter Frank:Hallo,
Ich möchte ein paar digitalisierte TV-Videoaufnahmen von der Werbung
befreien. Bisher habe ich die AVI-Dateien dazu mit VirtualDub
geschnitten. Aber ich finde, das geht recht lange, allein deshalb, weil
die Datenmengen eben bei AVIs so riesig sind.
Wenn es mir also nicht so sehr auf präzisen Schnitt ankommt, wäre es
dann nicht vielleicht besser, die MPEGs zu schneiden (;natürlich ohne
neues "Encoden"). Das Speichern der geschnittenen Version würde dann
schneller vonstatten gehen.
Oder spricht da was dagegen?
Gruß,
Peter
Antwort von Heiko Nocon:
Peter Frank wrote:
>Oder spricht da was dagegen?
Es spricht eigentlich nichts dagegen, außer daß man die Aufgabe auch
intelligent angehen und damit framegenauen Schnitt ganz ohne
zusätzlichen Zeitaufwand erreichen kann.
D.h.:
Einfach statt des zu erhaltenden Materials das rauszuschneidende
markieren und die Entf-Taste drücken. Operation wiederholen, bis alles
störende Zeug weg ist.
Dann Frameserver starten und so das geschnittene Material ohne sinnloses
Umkopieren für den MPEG-Encoder bereitstellen.
Antwort von Andre Storch:
> Peter Frank schrieb
> [...]Aber ich finde, das geht recht lange, allein deshalb, weil
> die Datenmengen eben bei AVIs so riesig sind.
... was nicht am AVI liegt, sondern am verwendeten Kompressor.
> die MPEGs zu schneiden (;natürlich ohne
> neues "Encoden"). Das Speichern der geschnittenen Version würde dann
> schneller vonstatten gehen.
Wenn du dich dazu entschließt,
nimm 'VideoReDo' zum Schnippeln.
Das kann zum einen auch Mpegs framegenau
schneiden (;und komprimiert dann nur
die Schnittstelle neu) und zum
anderen funktioniert es auch wirklich
(;im Gegensatz zu einer MpegCraft-Version,
die ich mal getestet hatte).
Grüße
André
Antwort von Ralf Fontana:
Peter Frank schrieb:
> Ich möchte ein paar digitalisierte TV-Videoaufnahmen von der Werbung
> befreien. Bisher habe ich die AVI-Dateien dazu mit VirtualDub
> geschnitten. Aber ich finde, das geht recht lange, allein deshalb, weil
> die Datenmengen eben bei AVIs so riesig sind.
Da gibts bei Dir ein Missverständnis. AVI ist nur eine Art Container, in
Deinem Fall für Videodaten. Welcher Art die Daten in dem Container sind
bestimmt der Codec und der ist auch wesentlich dafür verantwortlich ob die
Datenmenge höher oder geringer ausfällt.
Extrembeispiele:
a) DV-AVI mit Huffmann-Codec gibt bei Fullsize-PAL-Auflösung um die 11
MByte/s.
b) DV-AVI mit DivX kann bei gleicher Auflösung (;unter optimalen Bedingunen)
auch schonmal mit 500 KByte/s auskommen.
> Wenn es mir also nicht so sehr auf präzisen Schnitt ankommt, wäre es
> dann nicht vielleicht besser, die MPEGs zu schneiden (;natürlich ohne
> neues "Encoden").
Soll das ein Fragesatz sein? Dann solltest Du den mit einem Fragezeichen
abschließen.
> Oder spricht da was dagegen?
Ob etwas dagegen spricht hängt davon ab, in welchem Format Du die Daten vor
dem Schneiden überhaupt vorliegen hast.
Antwort von Peter Frank:
On Mon, 27 Jun 2005 17:47:08 0200, Ralf Fontana
wrote:
>Peter Frank schrieb:
>
>> Ich möchte ein paar digitalisierte TV-Videoaufnahmen von der Werbung
>> befreien. Bisher habe ich die AVI-Dateien dazu mit VirtualDub
>> geschnitten. Aber ich finde, das geht recht lange, allein deshalb, weil
>> die Datenmengen eben bei AVIs so riesig sind.
>
>Da gibts bei Dir ein Missverständnis. AVI ist nur eine Art Container, in
>Deinem Fall für Videodaten. Welcher Art die Daten in dem Container sind
>bestimmt der Codec und der ist auch wesentlich dafür verantwortlich ob die
>Datenmenge höher oder geringer ausfällt.
>
>Extrembeispiele:
>a) DV-AVI mit Huffmann-Codec gibt bei Fullsize-PAL-Auflösung um die 11
>MByte/s.
>b) DV-AVI mit DivX kann bei gleicher Auflösung (;unter optimalen Bedingunen)
> auch schonmal mit 500 KByte/s auskommen.
Klar, ich nutze schon einen entsprechenden Codec für die AVI-Aufnahme,
damit das digitalisierte Videomaterial nicht zu groß wird (;PICVideo
Lossless JPEG Video Codec von Pegasus Imaging). Aber bei einem über 2
Stunden langen Spielfilm werden die AVIs eben trotzdem recht groß. Und
DivX möchte ich nicht unbedingt verwenden, da ich später ohnehin ins
MPEG-2-Format konnvertiere. Ich habe gelesen, für das Capturing soll
es auch nicht so gut geeignet sein.
>> Wenn es mir also nicht so sehr auf präzisen Schnitt ankommt, wäre es
>> dann nicht vielleicht besser, die MPEGs zu schneiden (;natürlich ohne
>> neues "Encoden").
>
>Soll das ein Fragesatz sein? Dann solltest Du den mit einem Fragezeichen
>abschließen.
Ja, das sollte eine Frage sein. War ein Tippfehler (;das fehlende
Fragezeichen).
Gruß,
Peter
Antwort von Peter Frank:
Andre Storch schrieb:
>
>> Peter Frank schrieb
>> [...]Aber ich finde, das geht recht lange, allein deshalb, weil
>> die Datenmengen eben bei AVIs so riesig sind.
>
>... was nicht am AVI liegt, sondern am verwendeten Kompressor.
Abgesehen von DivX kenne ich keinen AVI-Kompressor, der wirklich
kleine Dateien liefert (;im Vergleich zu MPEG-2 Half-D1, dem Format, in
welches ich konvertiere).
>> die MPEGs zu schneiden (;natürlich ohne
>> neues "Encoden"). Das Speichern der geschnittenen Version würde dann
>> schneller vonstatten gehen.
>
>Wenn du dich dazu entschließt,
>nimm 'VideoReDo' zum Schnippeln.
>Das kann zum einen auch Mpegs framegenau
>schneiden (;und komprimiert dann nur
>die Schnittstelle neu) und zum
>anderen funktioniert es auch wirklich
>(;im Gegensatz zu einer MpegCraft-Version,
>die ich mal getestet hatte).
Das Programm sieht wirklich nicht schlecht aus, werde ich mir
definitiv mal näher ansehen. Zudem soll ja demnächst eine neue Version
davon rauskommen mit noch mehr Funktionen. Danke für den Tip!
Gruß,
Peter
Antwort von Ralf Fontana:
Peter Frank schrieb:
> Klar, ich nutze schon einen entsprechenden Codec für die AVI-Aufnahme,
> [...](;PICVideo Lossless JPEG Video Codec von Pegasus Imaging).
> Aber bei einem über 2 Stunden langen Spielfilm werden die AVIs eben
> trotzdem recht groß.
Dann kann ich mir schwerlich vorstellen das Du durch schneiden im MPEG-File
Zeit gewinnst. Beim schneiden mit VD mit direct stream copy läuft es auf
reines umkopieren hinaus während der MPEG-Schnitt doch etwas
anspruchsvoller ist. Letztlich läuft es auf die Frage hinaus CPU und RAM
bei MPEG oder eher die Festplatte bei JPEG die größere Bremse sind.
> Und DivX möchte ich nicht unbedingt verwenden, da ich später ohnehin ins
> MPEG-2-Format konnvertiere.
Dieser Gedanke ist zielführend.
> Ich habe gelesen, für das Capturing soll es auch nicht so gut geeignet sein.
Jein. Du kannst auch in DivX mit geringster Kompression aufnehmen. Aber
dann hast Du einen prozessorlastigen Codec mit mäßiger Kompression und da
ist besagter PicVideo eine starke Konkurrenz. Natürlich spielt das kaum
noch eine Rolle wenn Du einen PIV in der Heizplattenedition mit 3,8 GHz
darauf ansetzt.
Antwort von Andre Beck:
Ralf Fontana writes:
>
> Extrembeispiele:
> a) DV-AVI mit Huffmann-Codec gibt bei Fullsize-PAL-Auflösung um die 11
> MByte/s.
> b) DV-AVI mit DivX kann bei gleicher Auflösung (;unter optimalen Bedingunen)
> auch schonmal mit 500 KByte/s auskommen.
s/DV-AVI/AVI/
DV-AVI, also AVI mit DV drin, passt mit seinen 25Mbps ansonsten gut
dazwischen.
BTW: Der Codec heißt HuffYUV. Der verwendet zwar (;wahrscheinlich, ich
habe nur kurz in den Code geguckt und da nicht sofort die typischen
Strukturen gefunden) Entropy Coding nach Huffman, aber das verwendet
sowieso jeder (;u.a. auch MPEG), also qualifiziert das nicht wirklich.
--
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 <-
Antwort von Ralf Fontana:
Andre Beck schrieb:
> s/DV-AVI/AVI/
Grmpf - was habe ich denn da schon wieder für einen Müll verzapft. Danke
für die Korrektur.
> BTW: Der Codec heißt HuffYUV.
Jo. Ich könnte mir den Namen ja mal aufschreiben oder jedesmal raussuchen.
Ihn einfach als Huffmann abzukürzen ist aber bequemer.
>Der verwendet zwar (;[...]) Entropy Coding nach Huffman, aber das verwendet
> sowieso jeder (;u.a. auch MPEG), also qualifiziert das nicht wirklich.
Er trägt mit dem "Huff" aber seine Hauptfunktion schon im Namen. Die
Verballhornung ist zwar nicht schön, aber m.E. auch nicht zu weit
hergeholt.
