Muxen von M4V und M4A (7,4 GB): YAMB versagt

    ich habe es mal hier mit reingesetzt... ist war kein coding... aber man muß es ja auch mal zusammenbringen ;)

    1. M4V=Video Datei: XVid 1920x800;23.xFPS; ABR6500kbits, abspielbar mit VLC, der MPC meckert..."can not render..."
    2. M4A=Audiodatei: Nero AAC CQ40 5.1 48Khz, wird vom MPc korrekt abgespielt

    Yamb akzeptiert beide, nur beim muxen zu einer MP4 stellt Jamb sich quer! Nach zwei Stunden habe ich den Vorgang abgebrochen. Yamb hatte eine Datei mit ca. 80GB angelegt... die beiden Streams sind zusemmen 7.4GB!
    Yamb fügt alle ca. 7 Minuten eine M4V hinzu... die will ich aber nur einmal im MP4 haben :) Ich arbeite schon von einer zur anderen Notebookplatte... das sollte dann mit 2x 90MB/s im zeitlichen Rahmen gehen.

    Jemand eien Idee woran das liegen könnte?

    So, mal händisch getippt...

    Fängt auch an die Videodatei zu importieren... sollte dann doch bei 100% anhalten oder bzw. fertig werden. War gerade bei 133% und fängt jetzt wieder von vorne an... und wieder geht es über die 100%... bei 145% import fängt er wieder bei 0% an... so, mal was gefaxt und einen Kaffee getrunken... was haben wir denn da: also wieder mal ein neuer Durchlauf...

    Im Ordner baut sich eine t3qo Datei auf... die hat inzwischen: 12GB... ich breche das jetzt mal ab...

    Woran könnte das liegen? Gibt es eine andere Möglichkeit... z.B. für MKV umschreiben?

    Mit GSDMux hatte ich schon probiert... meldet einen fehlenden Zwischenfilter. MKVMerge sagt: unbekannter Typ!

    Ich denke irgendetwas fehlt in dem m4v. Normalerweise müsste auch der MPC diese Datei ohne Probleme abspielen, was er ja nicht macht... nur der VLC akzeptiert diese.

    Wenn ich mich jetzt nicht irre, wird beim coden im TMP Verzeichniss eine 264 Datei erzeugt. Ich vermute diese wurde falsch mit ? Mp4Box ? vom Mediacoder gemuxt.

    Ich habe jetzt die Quelldatei nochmal durch den neuen TSDoctor gejagt, lasse ihn bereinigen und schneiden...
    Dann lasse ich die Kiste heute Nacht mal wieder arbeiten:mad:

    Habe gerade nochmal einen Test gemacht... mal 5 Minuten Video gecodet (Mediacoder, XVid, ABR6500) und dann ver sucht mit dem 5.1AAC zu muxen. Hat Yamp ohne Probleme gemacht.:motz:

    Mal 'ne andere Idee: Wie alt ist die MP4Box? Gab es nicht mal eine Korrektur bezüglich Umgang mit Dateien > 4 GB?

    Und - wer betreut das Tool eventuell im englischen doom9-Forum?

    Ich würde mal das Xvid in einen AVI-Container schreiben, und dann mit mkvmerge mit der Tonspur zusammenmuxen. Dann sollte mkvmerge eigentlich ASP auch verarbeiten.

    Du meinst bestimmt den Videostream (M4V). Wenn der Audio-Stream (M4A) 7,2 GB groß wäre, und beide zusammen 7,4 GB, dann würde ich mich nicht wundern, warum das Video loopt. ;)

    Ein GUI-Tool zum Multiplexen von ASP-Rohdaten in AVI kenne ich nicht mit Sicherheit - vielleicht ffmpeg-basierte Programme wie MediaCoder oder SUPER. Ich würde ansonsten vorschlagen, an der Kommandozeile ffmpeg auszuprobieren, wenn du damit einigermaßen Erfahrung haben solltest (ffmpeg liegt z.B. auch MeGUI bei).

    Und wie zum verrecken bekomme ich ein MP4 mit Xvid&aac > 4GB zum rennen?

    Mediacoder akzeptiert bei XVid MKV als Container nicht! Und mit x264 habe ich in Staxripp, MeGUI und Mediacoder die Erfahrung gemacht das zwar die Schärfe besser ist, aber bei gleiche Bitrate die Farbverläufe in dunklen Szenen übler sind. Auch ruhige Texturen weisen solche Fehler auf. Finde ich persöhnlich nicht so prickelnd! Als Einstellung habe ich auch die HQ Presets der Programme durchprobiert... "Fast P Skip" aus, hat zwar ein bischen was gebracht... aber es nervt mich trotzdem.

    Also wäre meine Frage: XVid & AAC in MP4, aber dann halt größer 4GB!

    Und wie jede Woche aufs neue, wiederholen wir auch heute wieder:

    Blöcke in dunklen Bereichen können bei x264 an der MBTree-Technik liegen.
    __

    Wenn sonst nichts hilft, dann müsstest du wohl das Video noch mal neu zu XviD encodieren, diesmal aber nicht raw ausgeben lassen, sondern gleich in eine AVI, MP4 oder MKV (sollte bei der MeGUI via xvid_encraw hoffentlich möglich sein).

    Wie ist denn das rohe XviD entstanden?

    jaja, jedem Depp muß man das Erklären ;) Aber dann schreibt halt eine Anleitung für Deppen :)

    OK, MBTree... wenn ich in der x264Wiki nachschaue und nach MBtree suche stoße ich fürs erste mal auf:
    1) qcomp... standardmäßig auf 0.6, bedeutet das also, wenn ich 0.7 wähle, das die Kompression schwächer ausfällt, und sich ABR/xPass mehr wie Konstante Bitrate verhält?
    2) qpmin und qpmax gehören nicht dazu!?

    Für einen Vorschlag wäre ich dankbar! Ich peile für 1920x1080 eine Bitrate von ca. 6500kbit/s an. Bei konstanter Bitrate legen xvid und x264 saubere Ergebnisse hin. Ich persöhnlich würde x264 lieber so einstellen das ruhige und dunkle Szenen sauber aussehen und wo richtig was passiert kann es ruhig ein paar Artefakte geben. Derzeit ist es aber genau andersherum! Alles was hell, schnell und wuselig ist sieht bei ABR, CQ, CRF richtig gut aus... aber wehe es gibt stehende Texturen oder dunkle Farbverläufe... das kann xvid in der Standardeinstellung sehr deutlich besser.

    Alternativ nehme ich auch gerne eine x264 Befehlszeite... mit einer kurzen Erklärung. Die Wiki ist ja ganz nett... aber für mich jetzt erstmal teilweise zu hoch. Die muß ich mir Häpchenweise einverleiben!

    Bin für sehr Tipps dankbar!

    Edit: Habe gerade mal geschaut was StaxRip unter MPTree versteht:
    1. Lookahead, ich denke je mehr desto besser... 40-80?
    2. QP min, ich denke je höher desto niedriger fällt die Kompression in "schwachen" bereichen aus?
    3. QPcomp, 0.6 Standard.. bei 0.7 wäre in in schwachen Bereichen besser?
    4. IPRatio: 1.4 ? wohl besser nicht verändern?
    5. PBratio: 1.3, laut wiki wird das bei MPTree gar nicht benutzt!?

    Einmal editiert, zuletzt von textleiche (26. Januar 2010 um 21:20)

    Es ging eigentlich bloß darum, dass mit der Option "--no-mbtree" wieder die Bitratenverteilung wie bei älteren Versionen berechnet wird, und dass man diese "Kompatibilitäts-Option" mal ausprobieren sollte, wenn Verblockungen in neueren x264-Versionen auftreten.

    Alle Standard-Presets, die schneller als "fast" sind, verwenden sie implizit auch.
    __

    MBTree (Macroblock Tree) = weiches "B"

    Oh, man... wie soll man den darauf kommen :hm:...

    Also mal ausschalten... na dann probier ich das doch direkt mal aus... auch wenn ich das jetzt nicht verstehe. Mir fehlt einfach folgendes:
    - Bitrate min
    - Bitrate max
    - AVG Bitrate

    Dann wäre ich glücklich :) So konnte/kann man TMPGenc oder CCE dazu bringen super Mpeg2 abzuliefern.

    Im 2-pass-Modus kann man zumindest die Quantisierung begrenzen (Standard: 10 - 51). Also vielleicht "--qpmax 40" o.ä. Werte (je kleiner, umso feiner). Ob das aber wirklich "sinnvoll" ist, oder auch überhaupt hilfreich, muss ein Versuch zeigen (ein Maximum nahe an der 30 wäre schon Verschwendung).

    In der Zwischenzeit werden die Entwickler sicher daran arbeiten, die Ursache für diese Nebeneffekte zu finden und eine Korrekturmöglichkeit zu finden. Man will ja schließlich "Millionen zufriedene Anwender", auch wenn man bloß in der unbezahlten Freizeit daran sitzt... ;)

    Wenn ich könnte, würde ich helfen... aber leider habe ich höchstens ein paar VB6.0 Kentnisse um Industriesteuerungen zu Visualisieren und Bedienen zu erstellen :ani_lol:ist ein wenig fern von einem Videocodec.

    Leider hat dein Vorschlag nix gebracht!

    ich habe mir jetzt mal die Mühe gemacht und aus einer meiner BR eine kurze Sequenz zu coden... es sind jeweil 3 Bilder (aus dem Mediaplayerclassic) die die Problematik saugut wiederspiegeln.
    1. Dunkle Szene mit Farbverlauf, pro XVid
    2. Himmel als Farbverlauf, pro XVid
    3. Sehr schnelle Szene, wo der x264 durch Schärfe & Details punktet
    Beide Videos wurden mit ABR 6500kbits erstellt, ohne irgendwelche Filter.
    - Xvid mit DXN HDTV Profil + 2B-Frames+ Quarter Pixel (Rest auf Standard gelassen)
    - x264 mit Profile High, Preset Fast, Tune Normal, Level auto... sagt erstmal nicht viel aus... aber ich kann sagen das das mitgelieferte x264 HQ Profil in Staxrip die gleichen Probleme hat. Die x264.exe ist aktuell von der Webseite x264.nl
    Hier der Link zu den Bildern (ist ein 7z Archiv von meiner Homepage, seit gestern abend habe ich eine neue NAS mit integriertem Webserver..)
    http://akhome.dnsdojo.net/Videovergleich.7z

    Habe mir auch schon mal gedacht, das das Problem der Wiedergabefilter auf dem PC ist?!

    Zitat

    Habe mir auch schon mal gedacht, das das Problem der Wiedergabefilter auf dem PC ist?!


    Davon ausgegangen, die ffdshow Version einigermaßen aktuell ist: Unwahrscheinlich,..

    Zitat

    Beide Videos wurden mit ABR 6500kbits erstellt, ohne irgendwelche Filter.


    1pass ? Falls ja, poste doch mal den x264 call,..

    Ja, ein 1Pass ABR... aber 2pass bringt das ganze genauso (nicht so schlimm), aber dadurch das der Laptop recht hell im Gamma ist, sieht man das in den duknlen Bereichen sofort. Und bei den 2.7m über den Beamer meist auch, zumindest wenn die Autoiris meint jetzt wird es heller :) Dunkel ist halt dunkel...

    2Pass ist halt problematisch! Das dauert mit auf dem Core2Duo 2x2.54 zu lange! Und als Papa von 3 Kindern kann ich mir nicht mal ebend ein Quadcoresystem aufbauen... und CUDA liefert nur Mist. Außer ich wähle vieleicht CB 15000kbits.

    http://img717.imageshack.us/img717/2843/zwischenablage01.jpg

    Ach ja, Yamb (MP4Box) hate mit 3.6GB Video und 0.3GB Ton keine Probleme. Vieleicht doch ein 4GB Grenzproblem...

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden