• Hallo Allerseits,
    ich bräuchte eine Möglichkeit mp4s zu splitten, ohne diese neu zu komprimieren. Es muss nicht Frame- genau sein, also +- 50 Frames sind kein Problem (GOP Size ist 25). ffmpeg habe ich jetzt mit allen möglichen Einstellungen versucht, das neue mp4 File lässt sich auch grundsätzlich abspielen, ist aber in irgendwelchen Parametern nicht mehr korrekt. Problem ist, dass ich viele Clips mit ffmpeg per concat zusammen fügen möchte - solange kein Clip beschnitten wurde geht das auch wunderbar, sobald allerdings ein Clip beschnitten wurde gibt es Probleme. Sagen wir der erste Clip in meiner Liste wurde gesplittet, hierbei läuft ffmpeg mit concat am Anfang noch richtig, sobald aber der zweite Clip anfängt gibt es dts und andere Fehler.

    Habe versucht Audio und Video getrennt raus zu schreiben und mit mp4box zusammen zu fügen, aber mp4box liest die h264 Spur nicht mehr ein. Mit mp4box splitten habe ich auch versucht, war zuerst vielversprechend, ist aber nicht zuverlässig. Mal geht es, mal geht es nicht.
    mencoder habe ich auch versucht, würde von der Videospur her gehen, allerdings müsste hier die Audiospur neu komprimiert werden, was nicht geht.

    Das ganze soll unter Linux und Windows auf Kommandozeilen- Basis laufen und möglich schnell sein.

    Habt ihr Ideen was ich noch versuchen könnte?

    Danke schon mal für Eure Antworten!

    Grüße

  • Nun, du mußt an den I/IDR Frames schneiden damit der "zweite Teil" auch sauber anläuft.
    Schon mal AviDemux probiert ?

    Es gibt natürlich noch diverse andere Tools ...
    Mal anders gefragt: Was befindet sich denn im .mp4 Container ?

  • Dank für die Antwort may24. Im Container befindet sind eine Videospur, eine Audiospur und die dazugehörigen hint Tracks. Funktioniert aviDemux auch ohne GUI? Das ganze soll später auf einem Linux VServer laufen. Ich habe auch schon versucht mit ffprobe die I Frames zu ermitteln, aber das hat noch nicht so geklappt wie gewünscht. Das Anspielen ist auch nicht das Problem, sondern das anschließende concat mit anderen mp4 Clips.

  • Wenn jemand fragt, was sich in einem Kontainer befindet, dann wollen wir "Fakten, Fakten, Fakten". Wenn jemand fragt, was dein Auto "unter der Haube hat", dann reicht ihm "ein Motor und ein Getriebe" auch nicht aus, dann will er was von Ps und Nm hören, möglichst noch die Zylinderanordnung. Entsprechend gibt es für die Detailanalyse von Mediendatei-Inhalten auch MediaInfo, um technische Fakten zu sammeln. Beispielsweise ist es ein ganz erheblicher Unterschied, ob die Videospur im Format MPEG-4 ASP (DivX, Xvid u.a.) oder MPEG-4 AVC (H.264) oder HEVC (H.265) enthalten ist.

    Ab AVC (H.264) gibt es dann auch unterschiedliche Arten von Intra-Frames: IDR-Frames, bei denen sicher ist, dass ab hier kein folgendes Frame noch irgendwie abhängig vom Inhalt vor diesem ist, aber auch normale I-Frames, die nur so für sich von anderen Inhalten unabhängig sind (z.B. eingeschoben für blitzartige Änderungen im Bildinhalt). Nur an den IDR-Frames kann man AVC-Videostreams sicher schneiden. Egal in welchem Kontainer sie sich befinden (MP4, MKV, oder ganz ohne).

    Beim Zusammenfügen von Clips kann es dann eventuell auch zu Problemen kommen, wenn beide Teile vorher unabhängig fortlaufende Timecodes hatten, und diese Timecodes nach dem Zusammenfügen nicht wieder neu fortlaufend umgeschrieben werden: Dann kommt es an der Anfügestelle zu einem Timecodesprung, den der Decoder bemängelt, weil es für das beliebige Springen in das Video störend ist. Darüber hinaus gibt es dabei aber eigentlich keine Probleme, wenn der Decoder nur einfach alles von vorn bis hinten spielt, wie es ihm zugetragen wird.

  • Sorry, soweit hatte ich nicht gedacht :). Hier wäre der mediainfo Output:

    Code
    Format                                   : MPEG-4Format profile                           : Base Media / Version 2Codec ID                                 : mp42File size                                : 943 KiBDuration                                 : 18s 27msOverall bit rate mode                    : VariableOverall bit rate                         : 429 KbpsEncoded date                             : UTC 2015-07-14 14:52:20Tagged date                              : UTC 2015-07-14 14:52:20VideoID                                       : 1Format                                   : AVCFormat/Info                              : Advanced Video CodecFormat profile                           : Main@L3.2Format settings, CABAC                   : YesFormat settings, ReFrames                : 4 framesCodec ID                                 : avc1Codec ID/Info                            : Advanced Video CodingDuration                                 : 18s 0msBit rate                                 : 301 KbpsMaximum bit rate                         : 620 KbpsWidth                                    : 640 pixelsHeight                                   : 360 pixelsDisplay aspect ratio                     : 16:9Frame rate mode                          : ConstantFrame rate                               : 25.000 fpsColor space                              : YUVChroma subsampling                       : 4:2:0Bit depth                                : 8 bitsScan type                                : ProgressiveBits/(Pixel*Frame)                       : 0.052Stream size                              : 661 KiB (70%)Title                                    : h264@GPAC0.5.2-DEV-rev426-gc5ad4e4-masterWriting library                          : x264 core 146 r2538 121396cEncoding settings                        : cabac=1 / ref=4 / deblock=1:0:0 / analyse=0x1:0x131 / me=umh / subme=9 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=2 / 8x8dct=0 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=10 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=25 / keyint_min=2 / scenecut=40 / intra_refresh=0 / rc_lookahead=25 / rc=crf / mbtree=1 / crf=22.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / vbv_maxrate=1000 / vbv_bufsize=1000 / crf_max=0.0 / nal_hrd=none / filler=0 / ip_ratio=1.40 / aq=1:1.00Encoded date                             : UTC 2015-07-14 14:52:20Tagged date                              : UTC 2015-07-14 14:52:20AudioID                                       : 2Format                                   : AACFormat/Info                              : Advanced Audio CodecFormat profile                           : LCCodec ID                                 : 40Duration                                 : 18s 27msBit rate mode                            : VariableBit rate                                 : 93.6 KbpsMaximum bit rate                         : 102 KbpsChannel(s)                               : 2 channelsChannel positions                        : Front: L RSampling rate                            : 48.0 KHzCompression mode                         : LossyStream size                              : 206 KiB (22%)Title                                    : aac@GPAC0.5.2-DEV-rev426-gc5ad4e4-masterEncoded date                             : UTC 2015-07-14 14:52:20Tagged date                              : UTC 2015-07-14 14:52:20Other #1ID                                       : 65536Type                                     : HintFormat                                   : RTPCodec ID                                 : rtp Duration                                 : 18s 0msEncoded date                             : UTC 2015-07-14 14:52:20Tagged date                              : UTC 2015-07-14 14:52:20Other #2ID                                       : 65537Type                                     : HintFormat                                   : RTPCodec ID                                 : rtp Duration                                 : 18s 27msEncoded date                             : UTC 2015-07-14 14:52:20Tagged date                              : UTC 2015-07-14 14:52:20Bit rate mode                            : VBR

    Und so schaut der ffprobe Output eines Frames aus:

    Wegen dem Timecode, wird dieser nicht mit ffmpeg zurückgesetzt? Also auf die neue Länge? Das wäre ja ok.

    Ich verstehe auch nicht warum das nicht geht mit ffmpeg, denn hier am Ende wird ausdrücklich gesagt, dass nur am Key Frame geschnitten wird:
    https://trac.ffmpeg.org/wiki/Seeking

  • Je nach Container- oder Video-Format kann zumindest jede GOP, wenn nicht gar jedes Frame, einen eigenen Timestamp haben, sprich, zu jedem Frame kann man direkt oder in kleiner Umgebung bestimmen: Dies soll h:m:s.x nach dem Timestamp des ersten Frames dargestellt werden. Wenn du nun eine Szene herausschneidest, müssten alle Timestamps im gesamten Rest nach dem Zusammenfügen neu berechnet und umgeschrieben werden. So etwas tut leider nicht jede Software, die Videoteile zusammenfügt, weil nicht jeder Player sich für die Timestamps im Videostream interessiert. Die meisten werden sich nur für einen Keyframe-Index interessieren, der im Container zusätzlich abgelegt wurde, wenn das Containerformat so etwas bietet (was bei MP4 der Fall sein sollte).

    Ich weiß daher auch nicht, wie relevant solche Meldungen für das Abspielen überhaupt sind: Stört es nur, diese Meldungen auf der Konsole zu sehen, oder wird das Abspielen (oder weitere Verarbeiten) dadurch wirklich beeinträchtigt? Bessere Hilfe könnte man also wohl nur bieten, wenn du mal Beispiele hättest, anhand derer man demonstrieren kann, in welcher Größenordnung die daraus resultierenden Probleme liegen (von "vernachlässigbar" wie eine Warnung an der Konsole bis zu "tödlich" mit Absturz eines Players).

    Sowohl ffmpeg/mencoder als auch MP4Box sollten wissen, dass man AVC nur an IDR-Frames sicher schneiden kann. Und wenn das Video mit x264 erzeugt wurde, sollte jede GOP mit einem IDR beginnen (was aber nicht ausschließt, dass noch andere "Insel"-I-Frames existieren können).

  • Es ist möglich dass ich es jetzt hin bekommen habe, muss aber noch weiter testen. Dachte schon paar mal es würde klappen :). Habe jetzt mal die Zeit hergenommen, die ich von ffprobe bei einem Key Frame angezeigt bekommen habe, habe ein Frame zurück gerechnet und mit diesem Wert in ffmpeg geschnitten. -ss habe ich dabei nach den Input gesetzt, da das wohl genauer sein soll. Das Anschließende concat gab nur Warnungen aus, dass die Trackanzahl unterschiedlich sein soll, liegt wohl daran dass in dem geschnittenen Clip keine hint Informationen mehr drin sind.

    Mit dem Ganzen bezwecke ich eine Fallbacklösung für unseren Lifestream. Eigentlich wird der lokal auf einen Wowza Server im Internet gestream, allerdings brauchen wir eine Ausfalllösung und diese möchten ich auf einen VServerm packen.

    Die Warnungen die entstehen führen dazu, dass der Stream nicht mehr in Echtzeit läuft, trotz -re, daher brauch ich eine Lösung welche keine fortlaufenden Warnungen in ffmpeg produziert.

    Hier sind mal zwei Clips zum testen:

    ADtv.Gesundheit.2012 (V01).mp4.zip
    ADtv.Prophetie.Zeitgeschehen.2012 (V01).mp4.zip

    Der Inhalt für die Playlist.txt würde in etwa so ausschauen:

    Code
    file 'ADtv.Gesundheit.2012 (V01)_cutTmp.mp4'file 'ADtv.Prophetie.Zeitgeschehen.2012 (V01).mp4'

    Der ffmpeg concat Befehl schaut so aus:

    Code
    ffmpeg -f concat -re -i "$newPList" -c copy -flags global_header -bsf:a aac_adtstoasc -f flv -threads 1 rtmp://streaming/address

    Zum testen geht auch, statt Adresse, -f sdl "test"

    Falls es interessiert, mit ffprobe bekomme ich die Keyframes und die dazugehören Zeiten so raus:

    Code
    ffprobe -i input -show_frames -select_streams v -show_entries frame=key_frame -show_entries frame=pkt_dts_time -v quiet -of csv="p=0"
  • Sorry, soweit hatte ich nicht gedacht :). Hier wäre der mediainfo Output:

    Writing library : x264 core 146 r2538 121396c
    Encoding settings : cabac=1 / ref=4 / deblock=1:0:0 / analyse=0x1:0x131 / me=umh / subme=9 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=2 / 8x8dct=0 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=10 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=25 / keyint_min=2 / scenecut=40 / intra_refresh=0 / rc_lookahead=25 / rc=crf / mbtree=1 / crf=22.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / vbv_maxrate=1000 / vbv_bufsize=1000 / crf_max=0.0 / nal_hrd=none / filler=0 / ip_ratio=1.40 / aq=1:1.00

    Ist denn stitchable bei den x264 Parametern aktiviert?

    Code
    --stitchable            Don't optimize headers based on video content
                                  Ensures ability to recombine a segmented encode
  • Ah, das ist gut zu wissen!

    Habe jetzt folgenden Workaround:
    Die hint Tracks von mp4box alle entfernt. Mit ffmpeg zu allen Clips faststart hinzugefügt, mit ffprobe das Frame vor dem Keyframe ermittelt:

    Code
    ffprobe -i "$input" -show_frames -select_streams v -show_entries frame=key_frame -show_entries frame=pkt_dts_time -v quiet -of csv="p=0"

    und die Zeit davon verwende ich dann in ffmpeg zum Scheiden:

    Code
    ffmpeg -v "info" -i "$input" -ss $frameTime -c copy -flags global_header -avoid_negative_ts 1 -x264opts stitchable -movflags faststart -threads 2 -nostdin -y "$cutName"

    Und im letzten Schritt kommt dann der concat:

    Code
    ffmpeg -v "info" -f concat -re -i "$newPList" -c copy -flags global_header -bsf:a aac_adtstoasc -f flv -threads 1 "$rtmpURL"

    Scheint soweit zu funktionieren - einmal sind zwar auch dts Wanrungen gekommen, aber nicht mehr fortlaufend wie zuvor, daher haben sie den Stream auch nicht beeinträchtigt. Werd noch ein paar Testdurchläufe machen, aber bist jetzt schaut es sehr gut aus.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!