"copy" reduziert Dateigröße um fast die Hälfte

[Markus]

Hallo,

Situation:

• Videodatei von TV Aufzeichnung (DVB-S, MPEG Datei vom TV).
• Mit Option "Copy" für Audio und Video als MP4 gespeichert
• Die Datei schrumpft von 9,3GB auf 5,6GB

Das ist zwar gut, daß die Datei wesentlich kleiner wird, aber ich wollte das Video zunächst unverändert speichern (genauer Anfang und Ende trimmen, Werbung herausschneiden) und dann weiter komprimieren. Mache ich etwas falsch oder wird auch bei "copy" bereits das Video modifiziert? Ist etwa in der Originaldatei soviel "Luft" drin und wenn ja, was genau belegt da unnötig Platz?

Im Anhang die Ausgabe von MediaInfo zur Originaldatei und der "Kopie" von Avidemux.


Grüße
Markus

[eumagga0x2a]

Wegen

Code Select Expand

Modus der Bildwiederholungsrate          : variabel
Bildwiederholungsrate                    : 50,000 FPS
minimale Bildwiederholungsrate          : 7,143 FPS
maximale Bildwiederholungsrate          : 50,000 FPS
in der Ausgabe von MediaInfo zur MP4-Datei: Ist es mit einem der letzten Nightly Builds so? Wir verwerfen zwar bei Open-GOP-Streams die dem ersten Keyframe zeitlich vorangehenden B-Frames (die im Datenstrom jedoch nach dem Keyframe auftreten), wenn keine späteren Bilder sie zur Dekodierung benötigen, aber so eine starke Schwankung durch weggelassene Frames ist schon bemerkenswert.

Auf jeden Fall bitte einen der frischesten verfügbaren 64-bit Nightly Builds einsetzen, nicht den veralteten 2.7.6 Release. Das ist für Copy Mode wegen zahlreicher Bugfixes besonders relevant, aber selbstverständlich auch darüber hinaus:

https://avidemux.org/nightly/

Ist etwa in der Originaldatei soviel "Luft" drin und wenn ja, was genau belegt da unnötig Platz?

Das ist durchaus möglich, wir kopieren in ADM_convertFromAnnexBToMP4 NAL units vom Typ NAL_FILLER (also die "Luft" von der die Rede ist) beim Umwandeln des Videostroms vom AnnexB-Format zu ISO nicht mit. Die "Luft" wird in Übertragungen benötigt, um Schwankungen der Bitrate auszugleichen und enthält keinerlei Bildinformationen.

[Markus]

Hallo,

ich habe die Originaldatei mit dem letzten Nightly Build vom 17.12. (v2.7.7 4.2.4) noch einmal "kopiert". Sie ist wieder so groß wie bei Nutzung der letzten offiziellen avidemux Version 2.7.6. MediaInfo hängt an.

Von den Erklärungen habe ich leider nur einen Teil verstanden; was bedeutet z.B. "Open-GOP-Streams"? Soweit ich es verstanden haben kommen im Datenstrom bei der DVB-S Ausstrahlung Frames vor, die gar nicht zur Anzeige verwendet werden. Klingt seltsam, selbst wenn man die Framrate fest setzt sind unnötige doch etwas seltsam.

Mir geht es hauptsächlich darum, daß im ersten Arbeitsschritt möglichst keine Daten verändert werden, wenn das gewährleistet ist bin ich ja zufrieden, aber dazu will ich verstehen, warum die Datei so viel kleiner wird.


Grüße
Markus

[eumagga0x2a]

Mit dem Nightly besteht das Problem der variablen FPS wo eigentlich konstante sein soll nicht:

Code Select Expand

Modus der Bildwiederholungsrate          : konstant
Bildwiederholungsrate                    : 50,000 FPS
Das wollte ich eben geklärt wissen.

was bedeutet z.B. "Open-GOP-Streams"?

GOP = group of picture, Bildgruppe. Alles im Stream von einem Keyframe bis zum nächsten. Bei "Closed GOP", geschlossener Bildergruppe, beginnt der Dekoder den Stream an jedem Keyframe vollkommen frisch und neu zu dekomprimieren, braucht nichts von vorangegangenen Frames zu behalten. So ein Keyframe heißt IDR, instant decoder refresh frame.

Die meisten wenn nicht alle Videostreams, die über ein Medium mit beschränkter Bandbreite gesendet werden wie beim digitalen Fernsehen, benutzen hingegen "Open GOP" beim Video (H.264 oder HEVC), offene Bildergruppe. Dabei dienen Keyframes nur zur Navigation im Stream (der Dekoder kann von einem Keyframe beginnend einsteigen, nach ein paar Frames hat er ein komplettes Bild zusammen und kann mit der Wiedergabe anfangen), die ganze interne Logik und die Abhängigkeiten zwischen Frames setzen sich über Keyframes hinweg fort.

Die Folge ist, dass es grundsätzlich nicht möglich ist, in so einem Videostream sauber an Keyframes zu schneiden, und wenn man es doch tut, man muss aufpassen, bestimmte unverträgliche Dinge wie einen an Schnittpunkten zurückspringenden Bilderzähler (POC, picture order count), der die Reihenfolge bestimmt, in der Frames angezeigt werden, tunlichst zu unterlassen.

Soweit ich es verstanden haben kommen im Datenstrom bei der DVB-S Ausstrahlung Frames vor, die gar nicht zur Anzeige verwendet werden.

"Early B-frames" sind B-Frames, die im Stream auf ein Keyframe folgen, aber in der Anzeigereihenfolge vor ihm gezeigt werden sollen (sinnvoll möglich nur in Open-GOP-Videostreams). An Schnittpunkten (und nur dort) wie zum Beispiel am Anfang eines Streams verwerfen wir solche B-frames, wenn sie nicht von späteren Frames im Stream zur Dekodierung benötigt werden.

"Early B-frames" brauchen ihrerseits Bilder aus der vorhergehenden Bildergruppe, um vollständig dekodiert zu werden. Das heißt, sie sind nie komplett, sauber nach einem Schnittpunkt dekodierbar und sehen dementsprechend gar nicht gut aus.

Die Verkleinerung der Datei nach dem Remuxen hat mit ein paar verworfenen B-frames aber nichts zu tun.

Mir geht es hauptsächlich darum, daß im ersten Arbeitsschritt möglichst keine Daten verändert werden, wenn das gewährleistet ist bin ich ja zufrieden, aber dazu will ich verstehen, warum die Datei so viel kleiner wird.

Keine NALUs, die Bildinformationen enthalten, gehen verloren. Wir schmeißen nur den Füller weg, der lediglich die Bitrate hochtreibt, damit die für den Übertragungskanal reservierte Bandbreite ausgeschöpft wird, wenn gerade nichts zu übertragen gibt.

[Markus]

Mit dem Nightly besteht das Problem der variablen FPS wo eigentlich konstante sein soll nicht:

Code Select Expand

Modus der Bildwiederholungsrate          : konstant
Bildwiederholungsrate                    : 50,000 FPS
Das wollte ich eben geklärt wissen.

[..]

Mir geht es hauptsächlich darum, daß im ersten Arbeitsschritt möglichst keine Daten verändert werden, wenn das gewährleistet ist bin ich ja zufrieden, aber dazu will ich verstehen, warum die Datei so viel kleiner wird.

Keine NALUs, die Bildinformationen enthalten, gehen verloren. Wir schmeißen nur den Füller weg, der lediglich die Bitrate hochtreibt, damit die für den Übertragungskanal reservierte Bandbreite ausgeschöpft wird, wenn gerade nichts zu übertragen gibt.

Das war die Antwort, die ich gesucht habe (mir fehlten nur die Fachbegriffe dazu): Der Stream enthält "Fülldaten" und diese werden beim "Copy" weggeworfen. Super, damit bin ich zuversichtlich, daß nichts wichtiges wegfällt bei der Copy Operation.

Vielen Dank für die ausführliche Erklärung, die hat mir sehr geholfen und ich habe einiges dazugelernt.


Grüße
Markus

P.S.: Sorry, für die späte Antwort, aber ich wollte auf jeden Fall noch ein positives Feedback geben.