Posts by bond

Quote from Kopernikus

Die H.264 Implementierung in LAVC ist deutlich weniger ausgefuchst als x264, und unterstützt deutlich weniger Tools.

x264 sollte zum gegenwärtigen Zeitpunkt die bessere Wahl darstellen.

in libavcodec gibt es zwei h.264 encoder:
1) libav's eigener codec (produziert der überhaupt schon avc streams? ich glaube nicht)
2) x264

im prinzip müsste x264 via libav und x264 selbst identische ergbnisse produzieren, wenn dieselben optionen verwendet werden (ich nehme mal an, dass die defaults in ffmpeg anderst sind)

.mp4 unterstützt in der tat .mp2 (und .mp1) audio, muxen sollte man das ganze mit mp4box oder mp4creator können

die einfachste lösung wäre natürlich wenn qt endlich h264 in einem ausreichenden maße unterstützen würde

Quote from Selur

mit Vorschau -> Nö

Cu Selur

versuch mal das:

http://sourceforge.net/projects/cutassistant/

zum einfachen ablesen wie die b-frames eingesetzt wurden kann man auch mp4videoinfo von mpeg4ip verwenden

Quote from akapuma

Hallo,

ich verwende "h264_parse aka.raw", um einige Informationen über den Film zu bekommen.

Früher hatte ich aus dem Film im mkv-Container mit Haalis MP4 AVC to RAW converter via graphedit die raw-Datei aus der mkv-Datei extrahiert. h264_parse funktioniert damit.

Nun habe ich anstatt dessen mkvextract mit der gleichen Quelle probiert. h264_parse gibt aber folgendes aus:
h264_parse.exe - mpeg4ip version 1.5.5
couldn't find start code in buffer from 0

Ich habe mkvextract mit folgenden Varianten probiert:
mkvextract tracks aka.mkv --raw 1:aka.raw
mkvextract tracks aka.mkv --fullraw 1:aka.raw

Was mache ich falsch?

Gruß

akapuma

Display More

vermutlich erstellt mkvextract keinen 100% korrekten raw stream

Quote from zwiebel_sondermann

So die beiden filmchen sind jetzt aufm server.

http://rapidshare.com/files/9952531/merging_testfile2.mp4
http://rapidshare.com/files/9962004/merging_testfile3.mp4

das merging_testfile3.mp4, ist doppelt so lange wie testfile2, was mich dabei wundert, und weshalb ich auch beide upgeloadet habe ist, dass nach der gleichen abgelaufenen zeit (bspw. 3min) file3 viel asynchroner vom ton ist. Das kann ich mir nicht erklären, müsste das nicht gleich sein???

bond: Also ich würde sagen das der delay sprunghaft ansteigt.

wenn man das mp4 analysiert sieht man, dass alle 1536 samples eine reihe von sehr kleinen samples kommt.

das ist vermutlich durch eines der folgenden drei dinge verursacht:
1) durch delay nullen in avi am anfang, falls ein delay in avi gesetzt wurde
2) das audio in avi ist kürzer als das video und mp4box hängt einfach den folgenden audio stream direkt an das ende des letzten
3) beides

nimm einmal einen avi teil und sieh mal nach ob der audio stream kürzer als der video stream is in avi (ich denke das geht mit virtualdub

demux auch das audio mp3 nach .mp3, remux nach avi und schau ob audio und video immer noch in sync sind

Quote from katjarella

Ich denke das liegt am joinen ( Video/Audio Ende) oder der Player Hardware, die das einfach nicht sauber abspielen kann, weil sie den Container nicht richtig versteht.

für mp4 sollte das keinen unterschied machen. wichtig ist, dass die audio/video streams die gejoint werden mit den exakt gleichen optionen enkodiert wurden

Quote from katjarella

wenn man mit ffmpeg wieder quellen wandelt. Und wenn, selbst das Audio 10sec später beginnt würde. Beginnt im Output Film das Audio bei 0 und es ist syncron.

hm, klingt komisch, ist aber wohl so

dennoch wäre es nicht uninteressant von zwiebel_sondermann zu erfahren ob der delay sprunghaft ansteigt (jeweils bei start eines neuen teils) oder nicht sprunghaft immer stärker zunimmt

Quote from zwiebel_sondermann

Also die Asynchronität nimmt auf jeden Fall mit zunehmender Anzahl an Videos die ich aneinander merge ab.

bei zweiterem ist es eine falsche framerate

bei ersterem ist es entweder das delay problem, dass ich beschrieben habe, oder irgendwas anderes, wobei ich keine ahnung habe was das sein sollte

Quote from katjarella

also egal was ich schon mit ffmpeg & -r gewandelt habe, es war immer syncron. Und wo bitte nimmst Du das Delay her? Es ist doch garkeins angegeben.

wenn der delay sprunghaft ansteigt (!) dann ist der delay vermutlich schon in den quell avi dateien

nur weil alle videos die gleiche framerate haben bedeutet das noch nicht, dass die auch mit dem audio synchron sind

edit: wenn der delay sprundhaft ansteigt, also zb teil1 ist synchron, nachdem teil2 anfängt ist es desync, nach teil 3 noch mehr desync usw... dann liegt das wahrscheinlich daran, dass ein audio/video delay in jedem file vorhanden ist.

da avi nicht fähig ist einen audio/video delay korrekt abzubilden, hat man einen hack entwickelt (so wie man es immer macht mit avi) und einfach lauter nullen am anfang des audiostreams angehängt. natürlich sind solche nullen nicht korrekte teile von aac streams und könnten daher vermutlich den desync verursachen

also wenn der desync gleichmäßig (dh nicht sprunghaft) immer größer wird, dann kann der grund nur eine falsche framerate sein

Quote from leguangras

ist doch eh noch alles unklar.man brauch ein tool,welches den key ohne aes aus dem ram holt.und wenn jemand veröffentlicht,um welches tool es sich handelt wird das blacklisted und kommt mit auf jede scheibe.somit hat dann das tool keinen zugriff mehr auf die scheibe und wofür brauch man dann noch das eigentliche java-backup-tool?

wird also am 2.1. veröffentlicht um welches tool es sich handelt sind paar filme decodierbar,alle neuen haben aktualisierte blacklist....

g/l

wobei ich mir sicher bin, dass der player welcher den "fehler" aufweist in jedem fall von der industrie gefunden und geblacklistet werden wird

Quote from ScabbIsland

hm das heist also das wenn ich auf qualität verzichten würde das ich den genau so schnell hinbekommen würde wie den AVC?

genau

bzw. wenn du nero verwendest verzichtest du indirekt auch auf qualität bzw. kann man den nero sicher auch so einstellen, dass er sehr langsam enkodiert

jeder videostream muss mit einem keyframe anfangen. diese .ts captures fangen in der regel nicht mit einem keyframe an sondern starten einfach dort wo der capture gestartet wurde.
daher sind am anfang dieser .ts dateien immer frames, die kein keyframe mehr haben und daher fehlerhaft oder gar nicht dekodiert werden

15, 23.976, 25, 29.97 fps

dann hast du vermutlich eine falsche framerate verwendet. versuch einmal andere zu verwenden

also die ursprungsquelle auf die sich alle beziehen ist diese:
http://forum.doom9.org/showthread.php?t=119871

edit:
wichtig zu erwähnen ist jedoch, dass nicht dieses tool die hddvd crackt!
der trick ist, dass software hddvd player die nötigen keys in den arbeitspeicher schreiben wo der user diesen manuell auslesen kann/muss. den key muss man in das .cfg file des tools schreiben. backuphddvd ist ein normaler aacs decryptor. es findet nicht von selbst den key auf der hddvd, das ist der job des nutzers

Quote from LigH

Soweit ich das herauslese, ist es lediglich MPEG-4 AVC / H.264 mit einer HD-Auflösung (mehr als 720x576).

genau, in .ts

Quote from JoeB

Dafür gibt es jetzt eine gui für mp4-Menues. Player gibt es auch - den Osmo. Aber der funktioniert bei mir nicht - keine Ahnung warum

bei mir funkts

beschreib mal was du gemacht hast bzw. was das problem ist

:zunge: