Beiträge von bulsa

    1. Danke hat funktioniert, braucht von mir aus auch nicht behoben werden, trotzdem hier mein alter Ordner: hybrid.zip
    zu 2. Ist framecounter eigentlich auch von dir geschrieben, wenn nein wo kommt es her? (Der Link zu stashbox auf selur.de ist down...)
    zu 3. Verwendet wurde Hybrid 2011.11.7.1 in der Linux 32bit (Edit: und auch Win64) Version, einen Ausschnitt von der DVD kann ich wohl schlecht schicken (da ja nicht nur der Kopf benötigt wird, oder?)
    HybridDebugOutput.zip

    Danke für den wie immer schnellen Support ;)

    Hallo, ich habe drei Probleme:
    1. Die 64bit Windows Version startet bei mir auch nicht sondern bricht sofort mit SEGV ab.
    2. Das 32bit Linux Paket enthält eine 64bit FrameCounter Datei, die sich logischerweise nicht ausführen lässt auf meinem 32bit System...
    3. Wenn ich unter Linux eine DVD einlesen will, dann analysiert er schön, gibt auch auf der Konsole aus was er tut, findet einen "dummy track" und schmiert nach der Meldung "-> probably a dummy track, with no audio&video data, which is ignored now" mit SEGV ab.
    Das ist Valgrind beim DVD einlesen:

    Code
    ==5013== Process terminating with default action of signal 11 (SIGSEGV)
    ==5013==  Access not within mapped region at address 0x24
    ==5013==    at 0x4E4B27D: QObjectPrivate::setParent_helper(QObject*) (in /usr/lib/libQtCore.so.4.7.4)
    ==5013==  If you believe this happened as a result of a stack
    ==5013==  overflow in your program's main thread (unlikely but
    ==5013==  possible), you can try to increase the size of the
    ==5013==  main thread stack using the --main-stacksize= flag.
    ==5013==  The main thread stack size used in this run was 8388608.

    Bulsa

    Mit Speicher meinte ich wieviele stored Frames möglich sind, wobei die Zahl auch nur eine Vermutung ist, die darauf beruht dass ich mit höheren Profiles als 1.3 mit gleichen vbv Limits wie 1.3 und mehr ref Frames Bildfehler bekomme auf dem MP3-Player.
    Nachdem ich mich anscheinend recht missverständlich ausgedrückt habe hier noch mal in übersichtlich:

    Im Handbuch steht:
    Baseline Level 1.3 640x480 -> Was natürlich Käse ist, da bei Level 1.3 die Macroblocks/Frame Beschränkung bei 396 liegt: 640*480/16/16=1200>396
    Nun habe ich per Versuch festgestellt dass Videos trotzdem funktionieren wenn:
    In den Metadaten Level 2.1 steht.
    Die Auflösung der nativen Auflösung von 480x272 entspricht, was 510 Mb/Frame>396 entspricht
    Die Anzahl der Referenz-Frames nicht zu groß ist (sonst Bildfehler) was mich zu der Vermutung führt dass das Limit für stored Macroblocks entsprechend Level 1.3 bei 2376 liegt, sonst würde die Level Angabe im Handbuch ja absolut keinen Sinn machen.

    Was ich jetzt also brauche ist eine Referenz-Frames Begrenzung in Abhängigkeit von der Auflösung, was eben nicht durch ein gespeichertes Profil möglich ist (zumindest meines Wissens bisher), die Level Beschränkungen müssten aber einen analog funktionierenden Mechanismus bereits implementiert haben, deshalb mein Vorschlag von benutzerdefinierten Levels.
    Wie ich schon sagte - alles bisschen komisch an dem Gerät, dafür ist Bildqualität erstklassig :P

    Die Fehlermeldung bei veryslow hab ich jetzt bei dem Testbuild immer noch, PAR funzt so wies soll (muss).

    Dafür ist mir eine weitere Eigenart meines Players begegnet... (Wer auch immer diese Spezifikationen produziert hat hatte ziemlich wenig Ahnung scheint mir :()
    Er unterstützt Baseline H.264 bis zu 640x480/30fps, hat allerdings nur einen Speicher für 2376 Macroblocks (Level 1.3 laut Handbuch, was natürlich in der Auflösung/Framerate Blödsinn ist -> 1200Mb/Frame 36000Mb/s)
    Edit: Die vbv Limits für 1.3 gelten natürlich auch aber die kann man ja bereits einstellen und speichern.
    Ich bin für Vorschläge offen wie man solches Verhalten berücksichtigen kann. Meine Spontanidee (weiß nicht wie einfach das umzusetzen ist) wäre benutzerdefinierte Level zu ermöglichen.

    Bulsa

    Zitat


    => wüsste nicht wo das Problem ist. Wenn Du ein Szenario nennen kannst bei dem es Sinn macht PAR 1:1 nicht zu Signalisieren obwohl das Material 1:1 ist werde ich eine entsprechende Option einbauen.


    Mein Szenario das ich hier vor einer Weile schon mal gepostet hatte ist dass mein Mp3-Player (Samsung YP-P3) mp4 abspielt, aber nur wenn der PAR nicht explizit drinsteht... Dass das nicht toll ist weiß ich auch, aber am MP3-Player kann mans nun mal nicht ändern.

    Über ein win64 Testbuild würde ich mich freuen :)

    Bulsa

    Hab grad noch nen Bug gefunden: 2-pass crf produziert im zweiten Durchlauf einen Parameter "--bitrate XY" (also wirklich XY, KEINE Zahl)...
    Zum anderen wüsste ich gerne was ich mit der Fehlermeldung anfangen soll die kommt wenn ich bei baseline als preset veryslow auswähle, ich kann damit nicht wirklich was anfangen. Heißt das dass das Resultat nicht baseline kompatibel ist!?
    Und falls noch nicht geschehen bitte ich darum bei PAR 1:1 bei MP4Box dies nicht explizit anzugeben oder eine Option zu haben dies zu tun.

    Vielen Dank für die Mühe mit diesem Tool!

    sollte kein Problem sein, kann ich ändern, da ffmpeg auch lame support hat :)

    Eine Einbindung wie NeroAacEnc wäre vermutlich besser, zumindest war das letzte Mal als ich ffmpeg mit lame verwendet habe die integrierte Unterstützung leicht verbuggt und extrem veraltet (keine Unterstützung von VBR nur ABR)...



    No-Go, da ffmpeg zu oft kaputte mp4 files erzeugt. Wenn Du allerdings heraus findest wo das Problem genau liegt kann man es eventuell den Muxingaufruf von MP4Box anpassen.

    Google hatte keine Ahnung, was wahrscheinlich daran liegt dass ein ganz normaler MP4Box Aufruf funktioniert. Ich hab dann mal bisschen rumgespielt - Ergebnis:
    Mein Gerät (Samsung YP-P3) stört sich dämlicherweiße an dem explizit angegeben PAR, könnte man da eine Option haben den nicht einzubetten? (Perfekt wäre dann natürlich noch ein Warnhinweis wenn Ausgabe-PAR != 1:1 ... aber das ist das Zuckerli^^)


    komisch sollte nicht sein

    Hab ich grad keine Lust zu testen, ist m.E. auch mehr Spielerei als notwendig...

    Hallo, wie ich sehe ist der 1-Mann Support hier immer noch besser als so manche IT-Firma ;D Kompliment! Ich hoffe nur dass falls sich das mal ändern sollte wir Quellen kriegen, es wäre zu schade um dieses Programm.

    Ich habe eine kleine Bitte: Wäre es möglich den Muxer auswählbar zu machen, mein mp3-Player schluckt nämlich komischerweise keine mp4s von hybrid (egal ob flat storage und hinting aktiv sind), wenn ich die dann aber nochmal "nachverarbeite":

    ffmpeg -i in.mp4 -acodec copy -vcodec copy -f mp4 out.mp4

    dann gehts prima... ka wieso, ist den Aufwand das rauszufinden wohl auch nicht wert, wenn man einfach mit ffmpeg muxen kann.

    Auf Dauer wäre es auch mal schön wenn man mp3 encoding mit lame machen könnte, ich bin da auch gerne behilflich falls es damit irgendwelche Probleme geben sollte (mp3 Qualität von ffmpeg ist ja wohl mal unterirdisch).

    Rein aus Neugierde hab ich neulich auch mal "Auto Gain" verwendet, da geht wohl auch noch irgendwas schief, ich hatte nämlich im Ergebnis hörbares Clipping...

    Nochmal danke für die anhaltende Unterstützung hier :)

    Automatisch durchreichbare Untertitel fänd ich v.a. zur DVD-Archivierung auf der Festplatte sehr praktisch, denn da hab ich gern den gesamten Inhalt und die paar Kilobyte Untertitel machen die Datei nun echt nicht fett (vobsub zlib komprimiert versteht sich).
    Ich würde ein win64 testbuild gerne mal ausprobieren (auch wenn sich meine Zeit momentan etwas in Grenzen hält).

    Danke für die prompte Antwort.

    Mit mkvtoolnix 4.3.0 funktioniert es in der Tat, es lag also an der Version.
    Hier wäre IMHO eine Fehlermeldung gut, denn 2.7.0 ist die neuste Version die in Debian testing standardmäßig enthalten ist und führt dazu das erst einmal alles ok aussieht, der Output aber schließlich fehlt (Und die tmp-Dateien gelöscht sind...).

    Hallo Selur,

    auf meinem debian-testing scheint Hybrid zwar erfolgreich eine mkv-Datei zu erstellen (Es meldet Erfolg), allerdings ist diese nicht auffindbar.
    Meiner (kurzen) Analyse nach liegen hier 2 Probleme vor:
    1.Meine Version (debian amd64 2.7.0-1) von mkvmerge verwendet statt
    --no-audio --no-video --no-subtitles
    --noaudio --novideo --nosubs
    2.Der Status mit dem mkvmerge terminiert wird nicht überprüft.

    Bis auf dieses (wohl hauptsächlich kosmetische) Problem ist Hybrid genau wonach ich seit einer Weile auf der Suche bin :) Vielen Dank hierfür (auch wenn GPL natürlich noch besser wäre ;)).


    Der verwendete mkvmerge Befehl sieht so aus:

    Code
    "/usr/bin/mkvmerge" --ui-language en_US -o "/media/Daten_WD1/Videos/Sintel.2010.2K.x264-VODO/Sintel_1080p.mkv" --global-tags "/tmp/Sintel_1080p_21_51_50_471_04.tag.xml.tag.xml" --attachment-mime-type image/jpeg --attachment-name Cover --attach-file "/media/Daten_WD1/Videos/Sintel.2010.2K.x264-VODO/sintel_poster.jpg" -d 0 --default-track 0:yes --track-name 0:"Sintel" --language 0:en --default-duration 0:24fps --aspect-ratio-factor 0:1/1 --fourcc 0:MP4V --no-chapters --forced-track 0:no --no-audio --no-subtitles "/tmp/Sintel_1080p_21_51_50_471_02.264" --language 0:en --default-track 0:yes --forced-track 0:no -a 0 --no-video --no-subtitles --no-chapters "/tmp/Sintel_1080p_eng_aid_0__21_51_50_471_01.aac" --forced-track 0:no --default-track 0:no --no-video --no-audio --no-chapters --track-name 0:"Sintel" --language 0:de --sub-charset 0:UTF-8 "/home/tobias/sintel_de.srt" --forced-track 0:no --default-track 0:yes --no-video --no-audio --no-chapters --track-name 0:"Sintel" --language 0:en --sub-charset 0:UTF-8 "/home/tobias/sintel_en.srt" --forced-track 0:no --default-track 0:no --no-video --no-audio --no-chapters --track-name 0:"Sintel" --language 0:es --sub-charset 0:UTF-8 "/home/tobias/sintel_es.srt" --forced-track 0:no --default-track 0:no --no-video --no-audio --no-chapters --track-name 0:"Sintel" --language 0:fr --sub-charset 0:UTF-8 "/home/tobias/sintel_fr.srt" --forced-track 0:no --default-track 0:no --no-video --no-audio --no-chapters --track-name 0:"Sintel" --language 0:it --sub-charset 0:UTF-8 "/home/tobias/sintel_it.srt" --forced-track 0:no --default-track 0:no --no-video --no-audio --no-chapters --track-name 0:"Sintel" --language 0:nl --sub-charset 0:UTF-8 "/home/tobias/sintel_nl.srt" --forced-track 0:no --default-track 0:no --no-video --no-audio --no-chapters --track-name 0:"Sintel" --language 0:pl --sub-charset 0:UTF-8 "/home/tobias/sintel_pl.srt" --forced-track 0:no --default-track 0:no --no-video --no-audio --no-chapters --track-name 0:"Sintel" --language 0:pt --sub-charset 0:UTF-8 "/home/tobias/sintel_pt.srt" --forced-track 0:no --default-track 0:no --no-video --no-audio --no-chapters --track-name 0:"Sintel" --language 0:ru --sub-charset 0:UTF-8 "/home/tobias/sintel_ru.srt"