Beiträge von Dispatcher7007

edit:
Ich habe einen anderen weg über makemkv gefunden, der das Problem löst. Es ist also nur noch theoretisch interessant.
/edit:

Ich wollte nach längerer Zeit mal wieder Untertitel automatisch von staxrip übernehemn lassen.

Insbesondere wenn es sich um viele einzelne Videos handelt, ist das eine enorme Zeitersparnis, und das hat auch mal hervorragend funktioniert.

aber... irgendwie klappt das jetzt nicht mehr.
ich benutze die 1.1.6.9b

Unter "options" > "Subtitles" ist
"demux and include subtitles..." aktiv
"convert ..." aktiv
deutsch und englisch sollen eingefügt werden

als quelle benutze ich eine .vob die ich per PGCDemux mit der Einstellung
"create a PGC VOB" und
"one file per VID"
erstellt habe

hier der MediaInfo-Output dieser .vob

General
Complete name                    : E:\Datendrehscheibe\TNGS06D02\VTS_01_1_002.VOB
Format                           : MPEG-PS
File size                        : 1.84 GiB
Duration                         : 43mn 47s
Overall bit rate                 : 6 025 Kbps


Video
ID                               : 224 (0xE0)
Format                           : MPEG Video
Format version                   : Version 2
Format profile                   : Main@Main
Format settings, BVOP            : Yes
Format settings, Matrix          : Default
Format settings, GOP             : M=2, N=12
Duration                         : 43mn 47s
Bit rate mode                    : Variable
Bit rate                         : 4 433 Kbps
Nominal bit rate                 : 7 800 Kbps
Width                            : 720 pixels
Height                           : 576 pixels
Display aspect ratio             : 4:3
Frame rate                       : 25.000 fps
Standard                         : PAL
Color space                      : YUV
Chroma subsampling               : 4:2:0
Bit depth                        : 8 bits
Scan type                        : Interlaced
Scan order                       : Top Field First
Bits/(Pixel*Frame)               : 0.428
Stream size                      : 1.36 GiB (74%)


Audio #1
ID                               : 128 (0x80)
Format                           : AC-3
Format/Info                      : Audio Coding 3
Mode extension                   : CM (complete main)
Duration                         : 43mn 46s
Bit rate mode                    : Constant
Bit rate                         : 448 Kbps
Channel(s)                       : 6 channels
Channel positions                : Front: L C R, Side: L R, LFE
Sampling rate                    : 48.0 KHz
Bit depth                        : 16 bits
Stream size                      : 140 MiB (7%)


Audio #2
ID                               : 129 (0x81)
Format                           : AC-3
Format/Info                      : Audio Coding 3
Mode extension                   : CM (complete main)
Duration                         : 43mn 46s
Bit rate mode                    : Constant
Bit rate                         : 448 Kbps
Channel(s)                       : 6 channels
Channel positions                : Front: L C R, Side: L R, LFE
Sampling rate                    : 48.0 KHz
Bit depth                        : 16 bits
Stream size                      : 140 MiB (7%)


Audio #3
ID                               : 130 (0x82)
Format                           : AC-3
Format/Info                      : Audio Coding 3
Format profile                   : Dolby Digital
Mode extension                   : CM (complete main)
Duration                         : 43mn 47s
Bit rate mode                    : Constant
Bit rate                         : 192 Kbps
Channel(s)                       : 2 channels
Channel positions                : Front: L R
Sampling rate                    : 48.0 KHz
Bit depth                        : 16 bits
Stream size                      : 60.1 MiB (3%)


Audio #4
ID                               : 131 (0x83)
Format                           : AC-3
Format/Info                      : Audio Coding 3
Mode extension                   : CM (complete main)
Duration                         : 43mn 47s
Bit rate mode                    : Constant
Bit rate                         : 192 Kbps
Channel(s)                       : 2 channels
Channel positions                : Front: L R
Sampling rate                    : 48.0 KHz
Bit depth                        : 16 bits
Stream size                      : 60.1 MiB (3%)


Audio #5
ID                               : 132 (0x84)
Format                           : AC-3
Format/Info                      : Audio Coding 3
Format profile                   : Dolby Digital
Mode extension                   : CM (complete main)
Duration                         : 43mn 47s
Bit rate mode                    : Constant
Bit rate                         : 192 Kbps
Channel(s)                       : 2 channels
Channel positions                : Front: L R
Sampling rate                    : 48.0 KHz
Bit depth                        : 16 bits
Stream size                      : 60.1 MiB (3%)


Text #1
ID                               : 32 (0x20)
Format                           : RLE
Format/Info                      : Run-length encoding
Video delay                      : 2s 160ms


Text #2
ID                               : 33 (0x21)
Format                           : RLE
Format/Info                      : Run-length encoding
Video delay                      : 2s 160ms


Text #3
ID                               : 34 (0x22)
Format                           : RLE
Format/Info                      : Run-length encoding
Video delay                      : 2s 160ms


Text #4
ID                               : 35 (0x23)
Format                           : RLE
Format/Info                      : Run-length encoding
Video delay                      : 2s 160ms


Text #5
ID                               : 36 (0x24)
Format                           : RLE
Format/Info                      : Run-length encoding
Video delay                      : 2s 120ms


Text #6
ID                               : 37 (0x25)
Format                           : RLE
Format/Info                      : Run-length encoding
Video delay                      : 2s 120ms


Text #7
ID                               : 38 (0x26)
Format                           : RLE
Format/Info                      : Run-length encoding
Video delay                      : 2s 120ms


Text #8
ID                               : 39 (0x27)
Format                           : RLE
Format/Info                      : Run-length encoding
Video delay                      : 1s 920ms


Text #9
ID                               : 40 (0x28)
Format                           : RLE
Format/Info                      : Run-length encoding
Video delay                      : 2s 160ms


Text #10
ID                               : 41 (0x29)
Format                           : RLE
Format/Info                      : Run-length encoding
Video delay                      : 2s 160ms


Menu

Ich habe eine Vermutung. Und zwar ist in dieser Vob die Sprachinformation nicht mehr enthalten, da diese afaik in der .ifo gespeichert sind. Staxrip kann dann die gewünschten Sprachen Deutsch und Englisch nicht identifizieren, und tut deshalb nichts.

Allerdings hilft mir diese Vermutung nicht weiter, weil ich nicht weiß, wie ich dieses Problem beheben kann.

Grüße, dis

Ich verstehe davon auch einiges nicht. Voreinstellungen funktionieren aber gut^^

Gibt es denn einen Grund zum Wechsel auf eac3to? Kann das irgendetwas besser, als besweet? Ich hab Staxrip 1.1.6.9beta auf besweet zurückgestellt, weil ich damit immer zufrieden war, und halbwegs die cli-bedienung verstanden habe.

eine unbedeutende Anmerkung zur neuen Version hab ich:
Ich habe ein "seltsames" schriftbild im Programm:
[Blockierte Grafik: http://img718.imageshack.us/img718/134/lschmich.jpg]
Da das update mit einer Neuauflage des ganzen Systems einherging, kanns auch daran liegen.

Grüße

Tag,

kurze Frage:
Klappt die Bluray-Folder-Import-Funktion mittlerweile? Ich habs mal mit einer der ersten Versionen versucht, und da gabs Chaos. (War ne VC-1 Spur)
Seither hab ich Blurays manuell an Staxrip verfüttert in dem Wissen, einen suboptimalen Weg zu gehen (tsmuxer=>Videospur=>muxen in mkv=>verwursten in Staxrip=>komprimieren=>muxen mit allen anderen Teilen)

Aber das demuxen, mit anschließendem muxen, nur um es anschließend durch Staxrip wieder demuxen zu lassen, ist schon etwas stumpf... Unästhetisch^^
Eine .vc1-Datei zu laden klappt ja leider immer noch nicht. (kein Vorwurf!)

Grüße,
dis

Hab ich jetzt ausprobiert, mit gleichem Ergebnis... ich gebs jetzt auf...

Trotzdem Danke für die Mühen, die ihr euch gemacht habt!

[Blockierte Grafik: http://yfrog.com/5mtestjsj]
ich hab den Menüeintrag nicht... was ist denn da los? Das Programm mag mich nicht^^

Danke für den Link, ich hab den nicht gefunden... egal...

Die CLI-Fassung erzeugt nach LigHs anweisungen ne leere .txt-datei:

Zitat

"MediaInfo.exe --full Film.mkv > Film.txt".

Das programm mag mich wirklich nicht^^

Aber ich bin geneigt das Projekt zu beenden, da dabei zu viel Zeit drauf geht. Die Uni fängt wieder an, und diese versuche und überlegungen kosten ja stunden am Tag...

Wenn jemand noch eine Idee hat, würde ich das testen wollen, und wenn nicht, dann hats halt nicht sollen sein.

eac3to meldet folgendes zurück:

Zitat

The format of the source file could not be detected.

@mediainfo:
vielleicht bin ich dafür zu blöd, aber das Programm macht einfach nicht, was ich will^^ Ob ich jetzt den Debug-mode erhöhe, oder nicht, es bleibt alles gleich. Und wenn ich die cli version runterladen will, bekomme ich nur eine etwas ältere version der GUI... so wird das nix^^

vlc zeigt bei BEIDEN TROTZ Laufzeitdifferenz eine Framerate von 23.976215 an, was ja nun nicht dasselbe ist wie 24000/1001. Die Abweichung dazwischen ist mit 1,000007967 ziemlich exakt die der timecodes. Wenn man mal unterstellt das 23.976215 auch ein gerundeter Wert ist, ist der unterschied sogar kleiner als ein Rundungsfehler...

Jetzt glaube ich ja nicht an Zufälle, erst Recht nicht an Welche auf der 6. Nachkommastelle...

Allerdings zeigt vlc diese Framerate immer an, wenn ich mit mkvmerge bei 24000/1001 gemuxt habe. Bisher ist aber noch nie ein vergleichbares Problem aufgetreten...
Selbst wenn das der fehler wäre, müssten sich beide Videospuren doch gleich verhalten, oder? Tun sie aber nicht...

Da beide Timecodes die selbe Anzahl an Einträgen haben, unterstelle ich die identische Frameanzahl. Kann man das irgendwo direkt auslesen?

/edit:
Kann es sein, das der ursprüngliche h264-stream noch informationen über die Abspielweise beinhaltet, wogegen der neu erstellte diese Infos nicht trägt?

Ja klar...

vlc, smplayer, mpc, wmp11... alle das gleiche.

Es kann eigentlich auch kein Playerproblem sein, weil die bis dahin aufgebaute Zeitdifferenz auch in einem herausgeschnittenen Scheibchen der mkv vorhanden ist.

Da ich die große datei mit allen Spuren gestern bereits geschnitten und hochgeladen hab, kannste sie trotzdem sehen, wenn du willst.

Ich hab die Reproduzierbarkeit an einem 10min Ausschnitt getestet, aber wie erwartet kann ich mit bloßem Auge nichts erkennen. Kennst du ein Programm zum timecodeparallelen vergleichen von Videospuren?

Ich habe mal die timecodes der komprimierten fassung und der unkomprimierten in excel nebeneinandergelegt. Sie unterscheiden sich um einen Faktor 1,0000079574160700. Das ist zwar eine Auffälligkeit, aber es ist zu wenig um 1 sekunde in 3h auszumachen. Woher kommt diese Abweichung?

Irgendwie wird das ganze immer mysteriöser. Wenn ich diesen Thread hier unbedarft lesen würde, würde ich denken: "Der Typ redet doch Blödsinn..."

Ich Such mir jetzt mal ne andere Quelle... ich schätze hier ist einfach irgendwas völlig daneben...

Okay... dann halt so. Aber ich bin mal gespannt, ob wir da was finden werden, denn der effekt ist so klein, das er sich in einem kurzen Ausschnitt vielleicht nicht zeigen wird. Größenordnung 1/10000.

Bei knapp 3h hat sich die Zeitdifferenz zu etwa einer Sekunde aufgebaut.

Ich habe jetzt eine große MKV gemacht, um alles mal parallel zu haben.

ID1: Videospur komprimiert
ID2: Videospur original
ID3: Deutsch aac
ID4: Englisch aac
ID5: Deutsch dts
ID6: Englisch dts

Dann kann man nämlich sehen, welche spur mit was synchron läuft, eingestellte frameraten, etc...

Link kommt...

Ich habs mal in Excel importiert, und das geht ewig so weiter... Stichprobenartig über die ganze Datei auch keine anderen Differenzen als 41 und 42.

es war auch hier avcsource. das macht staxrip ja automatisch.

Das ganze Problem finde ich extrem seltsam...

Willst du mal einen Ausschnitt von originaldatei und anschließendem encode haben? Einen Link dazu möchte ich hier nicht veröffentlichen...
Ich schmeiß mal alles zusammen in eine .mkv und dann schneid ich mal ein paar scheibchen raus...

Ich hab Aufgeräumt und nach LigHs Wunsch die .txt-Datein angehängt. Ist die erste .txt jetzt eine "Full-Analyse"? Wenn nicht, dann funktioniert das nicht so, wie ihr beschrieben habt... oder ich hab was übersehen... auch nicht unwahrscheinlich.

Selur:
1:
(MKVInfo) | + Block (Tracknummer 1, 1 Frame(s), Zeitstempel 0.000s = 00:00:00.000) an 5786
(MKVInfo) | + Frame mit Größe 6349
(MKVInfo) | + Blockgruppe an 12142
(MKVInfo) | + Block (Tracknummer 3, 8 Frame(s), Zeitstempel 0.000s = 00:00:00.000) an 12145
(MKVInfo) | + Frame mit Größe 1006
(MKVInfo) | + Frame mit Größe 1006
(MKVInfo) | + Frame mit Größe 1006
(MKVInfo) | + Frame mit Größe 1006
(MKVInfo) | + Frame mit Größe 1006
(MKVInfo) | + Frame mit Größe 1006
(MKVInfo) | + Frame mit Größe 1006
(MKVInfo) | + Frame mit Größe 1006
(MKVInfo) | + Blockgruppe an 20201
(MKVInfo) | + Block (Tracknummer 2, 8 Frame(s), Zeitstempel 0.021s = 00:00:00.021) an 20204
=> keine Anpassung erforderlich, Zeitdifferenz baut sich ja leider erst auf.
Aber im Gegensatz zu hier lässt sich das nicht durch hin und herspringen im Video beheben. Außerdem läuft auch nur die komprimierte Videospur unsynchron zu allen anderen. Alle anderen passen zusammen.

2.in den erzeugten timecodes.txt sind jede Menge Zahlen drin... was mach ich damit, bzw. was sehe ich daran?

Das erste Beispiel oben ist die Inputdatei.

mkvinfo kommt sofort... sobald ich rausgefunden habe, wie ich das bediene^^ gib mir ein paar minuten...

Ich editiere hier dauernd rum, was vielleicht etwas chaotisch rüberkommt! Wie genau mach ich eine "Full-Analyse"?

/edit:
Hilft dir das weiter? Wenn nicht, sag mir, was du brauchst... die verbosefassung wird grade erstellt, aber... ich glaub nicht das die sinnig ist.

Kein Problem, ich kannte das Programm nicht.

Ist es das, was du brauchst?

/edit:
Nur noch die Informationen über die Inputdatei behalten zwecks Übersichtlichkeit. Enthalten in der input.txt in Anhang.

Zur Info: Die Deutsche Tonspur ist wesentlich länger, besteht aber nur aus Musik, die nach dem Abspann weiter läuft. (Klingt komisch, is aber so^^)

Hallo,

ich komm hier grade nicht mehr weiter, und bitte um Hilfe.

Beachten: Das Problem taucht NUR bei dieser Quelle auf.

Gegeben: Film FullHD, Tonspur dts
Das Bild wird durch Staxrip geschickt, avisynth und x264
Aufruf identisch wie hier, zusätzlich --crf 22

dts wird zu aac gewandelt.

Problem: 

Wenn ich die neue Bildspur und Ton zusammenmuxe, baut sich eine Zeitdifferenz auf. Selbst, wenn ich die gleiche Framerate, wie im ursprungsvideo angebe (24000/1001). Das komprimierte Bild läuft bei 3h ziemlich genau eine sekunde zu schnell (etwa 1/10000). Da die gleiche tonspur mit dem Ursprungsvideo synchron läuft (bei gleicher framerate), gehe ich davon aus, das der Ton okay ist.

Ein einfacher Muxfehler kann es daher eigentlich auch nicht sein. Wenn ich mit den gleichen einstellungen die originale, gedemuxte .h264 mit beliebiger tonspur (komprimiert oder unkomprimiert) in die .mkv packe, passts wieder.

Beide Bildspuren (bei gleicher framerate) in EINER .mkv laufen ebenso auseinander. Also muss das Problem an der neuen Bildspur liegen. Beide Bildspuren jeweils für sich alleine in eine .mkv gemuxt geben exakt die identische Laufzeit an, obwohl die kumulierte Zeitverzögerung am Ende mehr als eine Sekunde beträgt. (über 30 Frames Tonverzögerung am Ende).

Da passt ganz viel nicht zusammen, und ich weis grade nicht, was ich noch tun kann, um das problem einzugrenzen.

Leider kann ich mit mkvmerge GUI die Framerate nicht so exakt einstellen, um den Laufzeitunterschied auszugleichen. Ich komm der Sache zwar schon recht nah, aber ich kann es nicht mehr feiner auflösen. mmg nimmt die kleine Änderung zwar an, die erzeugte datei hat aber nicht die eingestellte framerate, sondern eine minimal abweichende, die auch minimale unsynchronitäten aufweist.

Alles in Allem bin ich grade ziemlich ratlos, aber gewillt der Sache auf den Grund zu gehen. Wenn ich irgendetwas mal testen soll, sagt bescheid!

Grüße, D

akapuma: ich hab das Thema noch nicht erschöpfend getestet, aber besonders zu deinem Letzten Punkt habe ich einen "hard fact".

zu 4.: Resizen ist imHo Mist. Während das Hochrechnen der Auflösung für 99.99999% der Fälle offensichtlich keinen Sinn macht, gilt mMn das gleiche fürs runterrechnen, da man mehr Bildinformationen vernichtet, als man Datenmenge einspart. Wenn man einen Beispielclip einmal mod16 croppt und komprimiert, und einen Vergleichsclip beliebig croppt und auf mod16 resized und komprimiert, dann braucht das größenveränderte Material knapp 4% mehr Daten (in bit/bild*pixel), um die gleiche Stelle zu komprimieren. Die Zahlen waren einmal 0,103b/bp und das andere mal 0,107b/bp. Seit diesem Test gibts bei mir kein Resizen mehr, warum auch?

Wer für sein handy filme komprimiert, darf auch resizen, der Rest ist mMn eher schädlich.

Ich hab einmal eine DVD auf FullHD hochgerechnet, weil meine Schwester einen alten DVD-Werbefilm während einer Messe auf einem 50" Super-duper Plasmafernseher abspielen lassen wollte. Da gabs halt die Chance, das es aufwändig hochgerechnet besser aussehen könnte, als original von DVD und nur Pixel verdoppelt.

@Lil barney

Zitat

5000er Bitrate bei 720p

Soll anscheinend ne DVD-R werden. Aber in 5Mbit kann man schon fast bequem nen FullHD-Videostream bei guter Qualität parken. Das die vfw-version dabei konkurrenzfähig ist, wundert jetzt nicht... Da kannste auch xvid nehmen, und du bist ein vielfaches schneller aus der Sache raus. Selbst mpeg2 würden die meisten Menschen nicht unterscheiden können, und das codierste mal eben in ner kaffeepause.

Wenn du nicht mehr als MPEG sagst, wirds schwer dazu was zu sagen, denn es ist näherungsweise alles MPEG was in diesem Forum läuft.

Die Encoder, die ich bisher benutzt hab, fragten nach 16er-Blöcken. Es gibt auch bei x264 dynamisch verwendete Subblöcke (bis 4x4), allerdings vermute ich, das sich 16x16 als bewährter Standard etabliert hat. Immerhin vervierfacht man mit einem generellen Wechsel auf 8x8 den Aufwand für Bewegungssuche, Frequenztransformationen und wahrscheinlich noch einiges mehr. Und der Rechenaufwand ist ohnehin schon unhandlich.

geschrieben, warum die teilbarkeit/16 gegeben sein sollte hat aber noch niemand. Also...

Bei der Kompression wird das Bild in 16x16 große Pixelblöcke unterteilt. Wenn eine glatte Teilbarkeit/16 in beide Richtungen gegeben ist, schön. Wenn nicht, muss der Encoder am Rand zusätzliche Pixel hinzuerfinden, um den Letzten Block auch noch auf 16 aufzufüllen. Diese Pixel tragen natürlcih keine Bildinformation, aber müssen halt verarbeitet und gespeichert werden. Dieser Overhead ohne Nutzen ist die gesunkene Encodereffizienz: Mehr Daten bei gleicher Quali, oder aber schlechtere Quali bei gleicher Datenmenge. Den Qualitätsverlust kann ich mit bloßem Auge nicht erkennen, aber die zusätzliche Datenmenge ist durchaus relevant. Der Effekt ist bei niedrigen Auflösungen prozentual größer, als bei Hohen. Allerdings wirst du durch verwendung der veralteten vfw-Version von x264 ähnliche Nachteile erleiden, die dir Offensichtlich nix ausmachen (sonst würde man das nicht verwenden, denn LigH hat dir einfachste Alternativen aufgezeigt.)

Jo, ich wollt jetzt nicht als ziemlicher noob anfangen, klugzuscheißen^^
Wenn du das machst, ist das was anderes...