Beiträge von monarc99

  • VapourSynth in praktischer Anwendung

    z.B. so: filter.vpy

    Zitat


    import vapoursynth as vs
    core = vs.get_core()

    clip = core.lsmas.LWLibavSource(source="/home/monarc/Videos/test.mkv")
    clip = core.std.Trim(clip=clip, first=7000, last=19000)

    clip.set_output()

    verarbeitet aber meines Wissens nur Video.

    Ich verwende vapoursynth nur als mpv video filter, ums trimmen und audio kümmert sich dann mpv.
    Als mpv vapoursynth Filter dann z.B. so:

    filter.vpy:

    Zitat


    import vapoursynth as vs
    core = vs.get_core()

    clip = video_in
    # sollten einige Filter crashen, weil fps nicht gesetzt ist, so einlesen
    # clip = core.std.AssumeFPS(video_in, fpsnum = int(container_fps * 1e8), fpsden = int(1e8))

    clip.set_output()

  • Frage: FFMPEG & X265 Kommandozeilen Frage

    Zitat von cneurope

    Ich versteh also nicht warum die Werte nicht so übernommen werden wie ich sie angebe ...

    Der x264 Encoder besteht aus mehreren Teilen.
    Zum einen aus einer Library (libx264) mit einer API (Programmierschnittstelle), die den eigentlichen Encoder darstellt.
    Und einem Kommandozeilen Programm (x264) welches die Schnittstelle für den Benutzer darstellt.

    Beide nehmen Parameter entgegen, die Namen der einzelnen Parameter kann sich aber leicht unterscheiden:
    Wenn du dem x264 CLI deine Parameter übergibst (z.B. --min-keyint 25), passt er die an die API Schnittstelle der Library an ( wird zu keyint_min=25)

    Und da ffmpeg die libx264 direkt anspricht und alle Parameter 1:1 weiterleitet, die du in der Kommandozeile angibst, brauchst du die Parameter in API Form. Die siehst du z.B., wenn du mit mediainfo obige x264 encoding Infos ausliest.

  • media-autobuild_suite

    Zitat von Selur

    xavs ist schon ne Weile dabei, glaub nicht, dass das neu ist :)
    opencl support rauswerfen, fixed das OpenCL.dll Problem, aber dafür ist das _vsnprintf_s Problem wieder da :/

    Steht denn dabei, was genau von ffmpeg die vsnprintf_s braucht? Vielleicht kann man das deaktivieren.
    Die _s Funktionen gibt es meines Wissens nicht unter WinXP. Nur neuere Win.

  • Star Trek Voyager NTSC bessere Qualität als die PAL Version?

    Zitat von TheGenesis


    Nu bin ich am hardern, ob ich kompatibilität (zu Hardwareplayern, die ich nicht besitze) gegen Dateigröße eintauschen will ...


    Ja, aber du kodierst 10bit ... gibt es oder wird es überhaupt jemals HW Decoder geben, die 10bit AVC decodieren können?

    10bit HEVC ja (z.B. die Nvidia Shield TV Box kann das angeblich), aber von 10bit AVC in HW kenne ich jetzt nix.
    Da wird vielleicht sowieso auf Software Decoder umgeschaltet werden müssen bzw. geht da wegen 10bit sowieso nix, die ref sind dann auch schon egal.
    Damit es mit allen Geräten geht, musst du auf 8bit runter.

  • Software für Typhoon PCI TV-Karte (bzw. FlyTV P34+)

    Zitat von LigH

    Das Thema hat sich nun erledigt. Ich habe mir einen preiswerten DVB-T/C-USB-Stick geholt. Kabel Deutschland bietet eine reichhaltige Auswahl an Sendern, wie ich nach dem ersten Scan feststellen durfte.


    Welchen Stick hast du dir denn geholt?

    Ja, die SD Sender sind bei KD nicht mehr verschlüsselt. Und da digital, kann man sie auch im Haus verteilen, wenn man will. Also auf Tablet oder Kodi (RP2 z.B.)

  • Star Trek Voyager NTSC bessere Qualität als die PAL Version?

    Zitat von TheGenesis

    Prima ... hab das PAL-Final nochmal hochgeladen ... hier
    Die 8 Ref-Frames sind für Kodi überhaupt kein Problem ... warum schafft das ein Hardwareplayer nicht?


    Meines Wissens, weil ihm der Speicher ausgeht. Der Decoder muss ja jedes Bild, von welchen eins der nächsten zu decodierenden Bilder abhängt, in seinem Speicher zwischenlagern.

    Und je höher du die Referenzen setzt, desto mehr muss er zwischenspeichern können. Und je höher die Auflösung (z.B. 1080p) desto mehr Speicher benötigt ein Bild.
    Software Decoder haben praktisch unbegrenzt Speicher, Hardware Chips nicht. Das gilt also auch für Kodi, wenn es über die GPU decodiert.

    Bei der xbox1 oder der PS3 war bei 1080p bei 3 Ref Schluss, deshalb gilt ref=3 bis heute als sicher.
    Aber bei einer PAL Auflösung könnte auch ref=8 gehen, weil ja die Auflösung niedriger ist. Ist aber schwer zu testen.

  • FFV1 sei neuerdings als langfristiges Archiv-Format vorgesehen

    Zitat von LigH

    Und dass er nicht als eigenständiger VfW-Codec (+ DS-Decoder) angeboten wird, sondern nur in ffmpeg und ffdshow/ffvfw, schreckt manche sicher auch etwas ab.


    Aber in dem Thread geht es ja um langfristige Archivierung, oder? Da dürfte es als Pluspunkt gesehen werden, dass der Codec in ffmpeg steckt, weil ffmpeg wird es in 15-20 Jahren immer noch geben. Auch über Betriebsysteme hinweg.
    Während ein eigentständiger VfW-Codec dann schon Geschichte sein kann.

    Zitat von LigH


    Version 3 wurde im August 2013 festgeschrieben. Die aktuellsten ffdshow-Versionen von clsid (wenn auch von 2014) sind älter, sollten also wohl aktuellen Code verwenden.

    Wenn ich im Sourcecode nachschaue. Die ffv1.c Datei in ffdshow wurde zuletzt am 2012-08-22 aktualisiert.

    http://sourceforge.net/p/ffdshow-tryout/code/4484/?page=3 Updated Libav Authored by: clsid2 2012-08-22

    Das dürfte eine der single-thread Versionen 0-2 sein. Was schade ist, weil in allen Lossless Performance Tests immer die ffv1 aus ffdshow getestet wird.
    Die multithreaded ffv1.3 geht so immer unter. Allerdings hat sich das Bitstream Format von ffv1 ab April 16, 2006 nicht mehr geändert. Die ffv1.3 ist also wohl nur schneller und hat leicht andere Default-Werte.
    Aber im Grunde kannst du jede Version ab Ende 2006 verwenden.

    Wird denn Virtualdub immer noch zum Capturen verwendet? Dann hat man ja eh erstmal nur AVI ... muss es also noch in MKV wandeln, wenn man das Format möchte.
    Also Capturen mit VD, AVI und x-beliebigen Codec (der schnellste). Und dann mit ffmpeg in MKV/ffv1.3 wandeln zum Archivieren.

  • FFV1 sei neuerdings als langfristiges Archiv-Format vorgesehen

    Hi,

    ich weiß nicht, ob ffdshow dafür geeignet ist - also ob die ffv1 darin nicht zu alt ist. Zum Archivieren/Capturen dürfte nur die FFV1.3 in Frage kommen, die kam so Ende 2013 in ffmpeg. Und ich weiss nicht, ob die jemals in ffdshow aufgenommen wurde.

    In deiner AVI ist die FFV1 Version 0 angegeben - das würde noch für das experimentelle ffv1.1 oder 1.2 sprechen. Oder sie schreibt es gar nicht rein.

    Wenn ich mit

    ffmpeg -i Testcapture_ffdshow.avi -acodec copy -vcodec ffv1 -level 3 -threads 8 -coder 1 -context 1 -g 1 -slices 24 -slicecrc 1 test.mkv

    umwandele, liest mediainfo ffv1 Version 3.4 aus. Die test.mkv ist 99MB groß, also etwas größer als deine Eingangsdatei mit 91MB.

    Ich hab damals die Entwicklung von ffv1.3 auf der Mailinglist mitverfolgt. Damals kam Threading dazu und ffv1.3 sollte schneller als die alten ffv1 arbeiten, dafür wurden die Dateien etwas größer. Das würde zu den beiden Dateien 99MB und 91MB passen.

  • Der x265-Encoder entwickelt sich...

    Zitat von sneaker2

    Es hat sich bisher niemand bei den freien Tools um Patente geschert, das wird sich dadurch nicht ändern.

    Die andere Frage ist eher, wie es bei Hardware Decoder/Encoder und Streams aussieht. Also die Verbreitung des Codecs allgemein.

    Divx hatte ja auch einige Patente verkauft, daraufhin wurden die ganzen DVD Player Hersteller genötigt, hohe Lizenzen für Divx zu zahlen. Die Folge war, dass per Firmware die Divx Unterstützung (FOURCC Kennung) an den Geräten unterbunden wurde.
    Sowas in der Richtung kann ja auch h265 passieren.