DVB-S2-Aufnahmen nach Wandlung länger als Original...

Zitat von Lapje

Ich wandle aus Platzgründen seit ein paar Tagen meine HD-Sat-Aufnahmen um und musste zu meinem Erstaunen feststellen, das einige Files länger sind als das Original

Kann von euch jemand evt. einen Fehler entdecken, der dafür verantwortlich sei könnte? Oder eine andere Idee?

Das liegt wohl an der Kodiereinstellung --crf 19, der Wert sollte dann höher liegen, so zwischen 21 und 23. Ob die Qualität dann ausreicht, ist eine andere Frage. Bei den derzeit geringen Speicherkosten halte ich eine Neukodierung nur dann für sinnvoll, wenn man durch Filtereinsatz eine visuelle Verbesserung erreichen will. Oder aktiviere mal bei Staxrip den Fluxsmooth-Filter

@ hdst
Ähm... ich glaube du hast das falsch verstanden. "Lapje" meinte, dass das encodierte Ergebnis von der Laufzeit her länger als die Quelle ist. Und auf die Laufzeit hat der CRF keinen Einfluss .

@ Lapje
Das Problem mit vereinzelten grünen Frames kenne ich auch - üblicherweise ist das meines Wissens ein Zeichen von "dropped frames". Ich würde mal vermuten, dass das LSMASHSource-Plugin die Datei als länger ansieht, als sie in Wirklichkeit ist und daher versucht etwas zu decodieren, was einfach nicht da ist.

Ein kurzes Sample wäre nicht schlecht, um das Problem halbwegs nachvollziehen zu können. Ansonsten hilft es eventuell die Datei neu indexieren zu lassen... oder möglicherweise das Rumspielen mit den erweiterten Optionen von LWLibavVideoSource... oder halt die Benutzung eines alternativen Source-Plugins (z.B. FFMS2).

Zitat von Lapje

Oder hast Du mein Problem falsch verstanden und dachtest, dass die Datei am Ende größer ist? Dem ist nicht so, die Einsparungen liegen so bei rund 40% und mehr.

Ja, eine klare Ausdrucksweise vermeidet Mißverständnisse.

Anscheinend ein Missverständnis. Die Spieldauer wird durch den einen oder anderen CRF-Wert sicher nicht beeinflusst.

Die Konvertierung von AC3 in MP3 würde ich dir wahrlich nicht empfehlen. Die ganze schöne Dynamik, die da verlorengeht, bei so wenig Platzersparnis im Vergleich zum Video...

ConvertToYV12() sollte erstens nicht notwendig sein, weil der Decoder sicherlich sowieso schon YV12 liefert; zweitens aber ist es ohne Angabe des interlaced-Parameters eigentlich falsch, weil damit praktisch bewiesen ist, dass sich da jemand keine Gedanken gemacht hat.

Alles aber noch nichts zur Dauer...

Zitat von Lapje

Entweder wurde einfach die Hälfte des Videos noch mal ohne Ton kodiert, oder es kommt einfach ein grünes Bild.

Ein Hinweis darauf, dass der Decoder schon nicht sicher ist, womit er es zu tun hat. Es muss einen Grund geben, dass AviSynth mit mehr Frames rechnet, als der Decoder am Ende liefert.

Vielleicht gibt es dann leichte Probleme mit der Indexerstellung, dass die sofortige Verarbeitung nach dem Indizieren schiefgeht, eine erneute mit Laden des Indexes von Platte dagegen klappt...

Wenn dabei die temporäre MKV neu erstellt wurde, wurde sicher auch der Index neu erstellt, da die Datei nun einen neueren Zeitstempel hat. Hoffe ich. Albern wäre, wenn das nicht bemerkt wird, und die temporäre MKV immer gleich heißt, aber doch jedes Mal einen anderen Inhalt hat, und dadurch jede Konvertierung immer einen uralten Index von einem längst vergessenen Video benutzt...

Bei ConvertToYV12() geht es auch nicht um Deinterlacing. Wenn der Decoder YV12 liefert, sei froh, dann kann nichts mehr schiefgehen. Solltest du aber YUV-4:2:2-Video haben (kann ich mir kaum vorstellen, aber auch nie ausschließen), dann spielt es schon eine bedeutende Rolle, ob die jeweils nächsten oder die jeweils übernächsten Zeilen sich die Farbigkeiten teilen: Ein Roter ball fliegt vor blauem Himmel vorbei

> LWLibavVideoSource("Quellvideo.mkv_temp")
allein wegen der Dateiendung sollte ich den Thread eigentlich ignorieren, da ich aber gerade ein paar Bier Intus habe und mir die Sonne auf den Schädel scheint:
ändere LWLibavVideoSource("Quellvideo.mkv_temp") mal nach LWLibavVideoSource("Quellvideo.mkv_temp", repeat=true)

Aus der README von L-SMASH Source:

+ repeat (default : false)
                    Reconstruct frames by the flags specified in video stream and then treat all frames as interlaced if set to true and usable.
                    If set to false, video frames consisting of two separated field coded pictures are displayed twice consecutively.

Hat Einfluss auf die Verarbeitung von halbbildcodierten Interlaced-Videos.

Lapje schreibt von 50p (1280x720 also?), die sind eigentlich recht sicher progressiv, oder?

poste doch ein kleines Sample mit dem sich das nachstellen lässt

Probleme, die ab und zu auftreten, sind meist entweder durch Speicherprobleme oder Virenscanner&Co zu erklären,...

Zitat

.ich hab jetzt mal LSMASH aktualisiert.

Hui, ganz übersehen das Update.

Na ja, ein GB kostet 0.035€, ein kWh aber 0.25€.
Hoffentlich wandelst du diese HDTV Sendungen im Winter um, um Heizungskosten zu sparen.

Ghitulescu:
Wenn Du schon solche Rechnungen andeuten willst, sei doch etwas genauer und sag auch:
a. wie viel Platzersparnis man hat
b. wie viel Strom man beim Reencoden verbraucht
c. wie viel physischer Platz dadurch eingespart wird und was dieser Wert ist
d. was die Arbeitszeit wert ist

Persönlich wandele ich Material für private Zwecke i.d.R. um, um:
a. ein Backup in einem bestimmten (eventuell vorher gefiltertem) Format zu haben
b. ein File in einem bestimmten Format zu haben damit ich es mit bestimmten Geräten (und/oder Betriebssystemen) einfacher/bequemer abspielen kann
c. kleinere Files zu haben, die sich schneller kopieren lassen und auch auf Geräte passen, die a. offline und b. vom Speicher beschränkt sind.

An sich war der Hinweis darauf aber schon uninteressant, weil schon in Post #2 und #3 darauf eingegangen wurde.