Beiträge von may24

Hallo zusammen,

Da Avisynt mit seiner 32 Bit Architektur recht schnell an die 2GB Grenze stößt, will ich Teile meines Videos erst mal in UT-Video "zwischenspeicher" und dann die einzelnen Teile zusammensetzen.
Mein .avs gibt das Video via dither tools in 16bit aus. Das fertige Produkt soll mit x265 10-Bit encodet werden.

Soweit mir bekannt unterstützt ffmpeg UT-Video. Doch welche CLI Parameter muss ich angeben um das Ganze in 10bit yuv420 zu speichern ?
Bisher hab ich das hier gefunden:

ffmpeg -i my.avs -vcodec utvideo -pix_fmt yuv420p out.mkv

...aber afaik, das ist nur für 8-bit ... kann man yuv420p10 oder sowas angeben ?
Oder wie sähe die Kommandozeile aus ?
(Das Ganze soll hier auf meiner Win7 Kiste laufen)

Frage ist: Wie kann ich das "debuggen" ... oder anders: Wie bekooe ich raus warum's auf der einen Kiste (AMD) funktioniert und auf der neuen Intel nicht
Obwohl ich nicht so recht glaube das es an der Hardware liegt ... Ehe am Fakt das es sich um 'ne VM handelt.

Ich habe da außerdem die Grafiktriber so etwas im Verdocht .... oder nutzt L-Smash-Source da keine "Features" ?

Könnte sein ... ist 'ne Sat Aufzeichnung ...
Aber ! Auf meiner Alten Win7 64Bit Maschine läßt sich das Video File anstandslos öffnen ... Selbes L-Smash-Source ...

Gibt's da irgend ein Win Update/Patch der mir fehlt ?
Oder liegt es daran das der "neue" Win Rechner ein VM ist ?

Nachtrag: Hab's gerade mal mit ffmpeg-source versucht ... geht. Ich wollte aber schon L-Smash-Source verwenden ...

Hallo zusamme. Kennt jemand diesen Frehler und Abhilfe ?
MSVC++2015 ist installiert. Sowohl 32 als auch 64 Bit.

lsmash-error.jpg

Bin auf Win 7 64bit unterwegs

LigH. Ooops sorry. Falsches ffmpeg. Das ist ja das vom Ubuntu System.
Ich hab's hiermit auch versucht:

/opt/ffmpeg/bin/ffmpeg 
ffmpeg version N-81411-g57503fa Copyright (c) 2000-2016 the FFmpeg developers
  built with gcc 5.4.0 (Ubuntu 5.4.0-6ubuntu1~16.04.2) 20160609
  configuration: --prefix=/opt/ffmpeg --enable-gpl --enable-version3 --enable-nonfree --enable-static --disable-shared --enable-gray
  libavutil      55. 29.100 / 55. 29.100
  libavcodec     57. 54.100 / 57. 54.100
  libavformat    57. 47.101 / 57. 47.101
  libavdevice    57.  0.102 / 57.  0.102
  libavfilter     6. 52.100 /  6. 52.100
  libswscale      4.  1.100 /  4.  1.100
  libswresample   2.  1.100 /  2.  1.100
  libpostproc    54.  0.100 / 54.  0.100
Hyper fast Audio and Video encoder

Was macht man denn mit einem Analogrechner was mit einem "Normalen" (digitalen) nicht geht ?

Hi, sorry das es so lange gedauert hat...

mein ffmpeg:

ffmpeg version N-78305-gb3b0ece Copyright (c) 2000-2016 the FFmpeg developers
  built with gcc 5.2.1 (Ubuntu 5.2.1-22ubuntu2) 20151010
  configuration: --enable-nonfree --enable-gpl --enable-version3 --enable-x11grab
  libavutil      55. 17.100 / 55. 17.100
  libavcodec     57. 24.101 / 57. 24.101
  libavformat    57. 24.100 / 57. 24.100
  libavdevice    57.  0.101 / 57.  0.101
  libavfilter     6. 28.100 /  6. 28.100
  libswscale      4.  0.100 /  4.  0.100
  libswresample   2.  0.101 /  2.  0.101
  libpostproc    54.  0.100 / 54.  0.100
Hyper fast Audio and Video encoder

Hier ist ein 10mb snip. Hoffe es passt -> Link

Na ja, was für ein Resizing Algorithmus benutzt wird hängt in erster Linie mal vom "Decoder" ab.
Was dein Betriebssystem verwendet weiß ich nicht und auch nicht was Youtube beim Re-encoden verwendet.
Da die aber vor allem auf Geschwindigkeit setzen wird es warscheinlich eher ein einfacher nicht sehr komplexer Algorithmus sein.
Ich hätte da spontan auch erst mal auf Point-Resize getippt ... oder BilinearResize ...

Hmmm ... also das mit ffmpeg hab ich's par-tout nicht hinbekommen ...

Also zurück zu eac3to. Nach etlichen Experimenten hat's nun geklappt.
ABER ! Es hat nur auf diesem Weg funktioniert:

eac3to.exe track_1.ac3 track_2.ac3 -core

Erst danach kann nach AAC gecoded werden. Alle anderen Versuche schlugen mit der Meldung fehl das das "Input Format" nicht bestimmt werden konnte (?)

Hi zusammen,

ich habe hier einen Audio Stream in e-ac3 der per-tut nicht richtig konvertieren will.
Weder mit eac3to noch MeGUI oder ffmpeg.
Entweder wird er gar nicht erkannt oder falsch wieder gegeben was zur folge hat das er eine doppelt so lange Laufzeit hat als er haben sollte.

Bis jetzt scheint mit ffmpeg der vielversprechendste Weg zu sein, aber wie schon gesagt, das Ergebnis ist halt doppelt so lang.

/opt/ffmpeg/bin/ffmpeg -i track_1.ac3 -c:a aac -q:a 4 track_1.mp4

Ich hab mal ein Snip von 500kb hier angehängt
snip.zip

Gibt es eine Möglichkeit dem ffmpeg decoder zu sagen das hier ein e-ac3 vorliegt ... er erkennt das scheinbar als "normales" AC3 format ...:(

Ist MP2 (MPEG 1 Layer 2) abwärts-kompatibel zu mp3 ?

Hmmm ... LigH's letzter Eintrag ist schon 2 Jahre her ... ich denke sie haben's gelöst

ok, Problem gelöst ... erst mal.

Der "root-cause" was das Audio Sub-System des VirtualBox. Das stand auf Pulseaudio.
Habe es auf ALSA umgestellt und siehe da, das Delay ist verschwunden.

... Hm, vielleicht sollte man diesen Beitrag hier in die Linux Sektion verschieben ...

nee ...
Auf dem HTPC läuft alles Super ohne jegliches Delay.
Nur auf meinem Rechner auf dem ich codiere gibt's das Delay beim abspielen durch den MPC-HC ... nicht bei der Verwendung von VLC.

Das merkwürdige ist ja das Avisynth (mit Lsmash-works) ebenfalls das Delay-Problem hat ... aber halt auch nur auf diesem Rechner ...
Ich tippe mal da auf den Ausgabe-Filter ... Aber im Graph-Edit sah alles ok aus ...

Hm ... keiner 'ne Idee ?
Gibt es eine Möglichkeit eines "GLobalen Audio Delays" ?
Sprich - egal welcher Audio Decoder verwendet wird, es wird immer ein Audio Delay gesetzt.
(war da nicht maol sowas bei der Verwendung von HDMI ?)

Erschwerend kommt hinzu das die WIN7 Kiste 'ne VM ist (VirtualBox)

Ok, es scheint an den Wiedergabe Filtern zu liegen.

Aber ...

Ich habe das Ursprungs Video via L-SMASH-Works-r804-20151004-32bit geöffnet und das Audio Delay entsprechend korrigiert.
Das waren rund -300ms. Soweit so gut, alles Lippensyncron und auch der MPC-HC hat das Ganze richtig wiedergegeben.

Nun hab ich den Clip auf meiner NAS Storage abgelegt (Samba kein DNLA !) und von meinem HTPC abgespielt.
Der Ton ist um genau die 300ms zum Bild verschoben.

Spielt man auf meinem Encoding-Rechner das Ganze mit VLC ab, gibt's den gleichen Effekt.

D.h. es muss am ... Tja was liegen ???
Mein HTPC verwendet ebenfalls die neusten LAV-Filter. Nirgendwo ist ein Delay gesetzt ! Splitter müßten ebenfalls die selben sein ... Mir fällt nichts mehr ein :nein:

Hallo zusammen,

ich habe bei mir folgenden Effekt festgestellt:

Mediainfo zeigt mir kein Delay im Ursprungs-Container an. Weder Audio noch Video ...
Auch habe ich das AAC Audio 1:1 übernommen ... also nich reencoded.
Mit yamb/mp4box aus .mp4 extrahiert und direkt mit dem neuen HEVC Stream in Matroska gemuxed.

Wenn ich dann einen AVC Video Stream re-encode in HEVC habe ich danach ein Audio Delay von -100 bis -250 ms.
Und das obwohl die Anzahl der Frames absolut gleich ist ... Oder hat sich am Matroska Container in letzter Zeit was geändert was diesen Effekt hervorruft ?
Hat noch jemand anders auch diese Phänomen ?

John Olivers - sehr passender Kommentar zum Brexit

Ähm ... lass doch beide Platten im Server und nimm einfach nur die defekte Platte aus dem Raid raus.
Danach sollte das System ganz normal hochfahren und alle Daten direkt verfügbar sein ... es sei denn der Spiegel ist Kaput ...
RAID-1 Festplatte entfernen Wiki

Wie wär's mit ffmpeg

ffmpeg.exe -i video.ts -i infile.ass -c:v copy -c:a copy -c:s copy new-Video.mkv