Avatar

Please consider registering
guest

sp_LogInOut Log In sp_Registration Register

Register | Lost password?
Advanced Search

— Forum Scope —




— Match —





— Forum Options —





Minimum search word length is 3 characters - maximum search word length is 84 characters

No permission to create posts
sp_Feed Topic RSS sp_TopicIcon
Nach Schnitt sind Bild und Ton nicht mehr synchron
8. Juni 2012
18:24
Avatar
sir_dikay
Guest
Guests

Hi,

zunächst einmal ein großes Lob an den/die Verantwortlichen von Super OTR! Ich nutze das Programm schon eine halbe Ewigkeit und bin sehr zufrieden!

Leider habe ich seit einiger Zeit (ca. ab Q4/2011) das Problem, dass Aufnahmen nach dem Schnitt nicht mehr synchron sind, d.h. das Bild hängt häufig um einige Sekunden nach.

So wie ich das beobachten konnte, ist das Problem meist wie folgt:
Der "Eingangsschnitt" ab dem der eigentliche Film, z.B. zu Beginn oder nach einer Werbung, los geht, scheint nicht richtig synchron zu sein. Häufig - nicht immer - sieht man sogar noch einige Sekunden die Bilder der Werbung oder der Altersempfehlung des Senders obwohl der Ton des Films bereits korrekt weiterläuft. Ab dieser Stelle ist dann die Verzögerung vorhanden, da Bild und Ton jeweils mit normaler Geschwindigkeit weiterlaufen. Durch weitere Schnitte/Werbungen verstärkt sich diese Verzögerung dann jeweils.
Die Verzögerungen sowie das sporadisch auftretende Problem bei dem geschnittene Bilder sichtbar werden, sind sowohl mit heruntergeladenen Cutlisten als auch mit manuell in Super OTR geschnittenen Aufnahmen vorhanden - bei denen sehr genau auf den korrekten Frame geachtet wurde.

Bitte bei weiteren Fragen oder Empfehlungen bitte melden. Ich werde regelmäßig in das Forum schauen.

Thx and Bye
dikay

14. Juni 2012
23:28
Avatar
mepaso
Member
Members
Forum Posts: 62
Member Since:
20. Mai 2012
sp_UserOfflineSmall Offline

hi

in der letzten Zeit hat sich bei SuperOTR einiges getan, insbesondere in Bezug auf AppleTV/MP4/iTunes Kompatibilität und Tonsynchronität

Ich empfehle Versionen >= b74

Workflow (siehe auch andere Posts):

HQ-otrkey herunterladen, dekodieren und als MP4 konvertieren (kann SuperOTR automatisch :)
Schneiden
die entstandene .mov Datei (ist quasi MP4 mit richtigem Tonformat) sollte synchron und
auf AppleTV / iTunes benutzbar sein

Sollte es Probleme gebe, diese bitte hier detailiert (Versionen, Workflow) angeben

sl mepaso

sl mepaso

15. Juni 2012
02:22
Avatar
wobie
Guest
Guests

moin,

also ich hab auch, wie schon an anderer Stelle geschrieben, die Probleme mit asynchronem Ton zum Ende des Filmes. OTR mit Safari geladen, mit SOTR in .mov Datei umgewandelt und geschnitten. Dabei ist die .avi Datei noch synchron, aber die.mp4 Datei vor dem Schnitt ist am Ende schon asynchron. Mit b74 und unter 10.7.4. Hab extra noch mal die Unglaublichen vom 17.05.12 in HQ geladen und es probiert. Bei Inglourious Basterds wars auch so.

Gruß
Wolfgang

16. Juni 2012
12:53
Avatar
matze
Member
Members
Forum Posts: 11
Member Since:
28. Mai 2012
sp_UserOfflineSmall Offline

Ich habe auch ein Problem mit Bild Ton Asynchronität.
Aber bei mit ist es Playerabhängig d.h. bei MplayerX ist der Ton schneller als das Bild.
Wenn ich aber die gleiche Aufnahme mit Quicktime abspiele funktioniert alles super.
Komisch, komisch...

21. Juni 2012
10:00
Avatar
BBsan
Guest
Guests

Habe das Problem auch. Ich glaube das liegt an der MP4Box Version.
Habe das ganze bei mir mal mit MP4Box 0.4.6 DEV gemacht und bei mir ist es jetzt in beiden Playern synchron.

Die Asynchronität kann aber auch mit einem Bug in MplayerX bzgl mp4 Dateien zutun haben: in einem MKV Container ist das ganze wieder synchron.
Der Bug lässt sich auf einen Bug in ffmpeg zurückführen.
Entsprechend haben einige Programme Probleme mit dem Abspielen von MP4 Dateien (Plex,XBMC,VLC in älteren Versionen, MplayerX, WDLXTV in älteren Versionen, ...).

Ich empfehle für die Archivierung deshalb immer nach dem Schneiden in einen MKV Container zu packen.
BTW: @Stefan kannst du das evtl in SuperOTR implementieren? Man braucht dafür nur MKVToolNix. Der Command dafür ist
[CODE] mkvmerge -o neuerName.mkv -v alterName.mov/mp4 [\CODE]

3. August 2012
17:17
Avatar
Felix
Member
Members
Forum Posts: 5
Member Since:
3. August 2012
sp_UserOfflineSmall Offline

Kann ähnliches Berichten.

Folgendes Setup:

HQ laden -> dekodieren -> Nach MP4 wandeln -> schneiden (nicht avidemux, mit was wird sonst geschnitten? Quicktime?) -> Auf NAS verschieben (D-Link DNS-320)

Wenn ich das ganze auf dem Mac schaue (Quicktime, iTunes, VLC) läuft alles super, wenn ich es aber per DLNA auf dem TV schaue (LG LV5590) ist Bild & Ton durchgehend asynchron.
Wenn ich nun das geschnittene File über MKVToolNix in den MKV-Container packe, läuft es über den TV synchron, kann es dann jedoch nichtmehr auf dem iPad schauen (was schön wäre). MKVToolNix sagt mir bei den geschnittenen Files auch, dass ein negativer Timecode vorliegt, welcher korrigiert wird. Kann es damit zusammenhängen?

Ein weiteres Problem habe ich mit der Auflösung, kann aber auch gut sein, dass es am TV liegt. Bekomme die HQ-Files nicht in Vollbild auf dem TV angezeigt.

13. August 2012
22:40
Avatar
Timm
Member
Members
Forum Posts: 88
Member Since:
14. Mai 2012
sp_UserOfflineSmall Offline

BBsan said
[...]
Ich empfehle für die Archivierung deshalb immer nach dem Schneiden in einen MKV Container zu packen.
[...]

Ich bekomme bei den Files dann immer eine Warnung angezeigt:

Warning: ... This file contains at least one frame with a negative timecode. All timecodes will be adjusted by 00:00:00.040 so that none is negative anymore.

Scheinbar kommt daher die unbeliebte Asynchronität, dass da irgendwer einen bösen negativen Timecode einbaut ;)

15. August 2012
00:00
Avatar
Tom
Member
Members
Forum Posts: 174
Member Since:
14. Mai 2012
sp_UserOfflineSmall Offline

Zum Thema 'Asychronität mit Nicht-iTunes-Playern' hab ich etwas in den Kommentaren gepostet: http://wp.me/pb4GA-6Y

Bei Interesse bitte lesen.

Kurzzusammenfassung: Der Player meiner WesternDigital-Box spielt geschnittene Filme absolut synchron ab, wenn alle Schitte an Key-Frames gemacht wurden (mp4). Wenn Nicht-Key-Frame-Schnitte drin sind, kommt er durcheinander und wird asynchron.

Wäre gut, wenn verifiziert werden könnte, ob das auch für andere Player (plex oder wasauchimmer) genauso zutrifft. (Im Post hab ich beschrieben, wie man zu Testzwecken keyframegenau schneiden kann.) Wenn das bei anderen Playern genauso ist, dann hätten wir die Ursache des Problems gefunden, und bräuchten "nur" noch eine programmierte Lösung (>> Stephan;)

15. August 2012
16:10
Avatar
Felix
Member
Members
Forum Posts: 5
Member Since:
3. August 2012
sp_UserOfflineSmall Offline

Hm naja ich so ähnliche Erfahrungen gemacht mit dem LG LV5590 TV per DLNA.

Hast du das mit den AVI oder HQ Aufnahmen gemacht?

Mein Vorgehen momentan, damit ich synchrone Aufnahmen bekomme:

Bei HQ: In SuperOTR rein und einmal volles Programm (Dec, mp4, schneiden). Die .mov dann in MKVToolNix, die mkv dann mit Subler ein bisschen Meta-Auffrischen und als mp4 wieder abspeichern. Dann läuft das, geht natürlich nicht mehr Hand in Hand und dauert auch etwas.

Bei AVI: In SuperOTR rein, Dec. und MP4 Wandeln. Die dann mit MPEG-Streamclip schneiden.

16. August 2012
09:18
Avatar
Tom
Member
Members
Forum Posts: 174
Member Since:
14. Mai 2012
sp_UserOfflineSmall Offline

Felix said

Hast du das mit den AVI oder HQ Aufnahmen gemacht?

Aus HQ-avi (h264) konvertiertes mp4.

Die nicht-HQ(h264)-Filme ("divx-avis") von OTR sind von Haus aus eher problemlos; meistens konvertiere ich die gar nicht.

19. September 2012
10:13
Avatar
raphael
Member
Members
Forum Posts: 8
Member Since:
19. September 2012
sp_UserOfflineSmall Offline

Ich hatte hier schon geschrieben, dass ich das gleiche Problem habe, dieses aber mit dem qotrdecoder und meinem Skript nicht auftritt.

@Tom: Danke für den Hinweis wegen der Artefakte. Das klingt plausibel und es wäre schön, wenn das noch in den Griff zu bekommen wäre. Den AudioEncoder könnte ich sicherlich wechseln, ich habe aber auch mit ffmpeg bisher keine Probleme gehabt.

@Stephan: Bei qotrdecoder kommt folgende geschnittene (HQ)-Datei heraus (ffmpeg -i):

encoder: Lavf52.31.0
Duration: 00:20:26.04, start: 0.000000, bitrate: 1064 kb/s
Stream #0:0: Video: h264 (High) (H264 / 0x34363248), yuv420p, 720x576 [SAR 64:45 DAR 16:9], 25 fps, 25 tbr, 25 tbn, 50 tbc
Stream #0:1: Audio: mp3 (U[0][0][0] / 0x0055), 48000 Hz, stereo, s16, 192 kb/s

Edit: Wenn ich von qotrdecoder rede, meine ich das Teil hier: http://www.onlinetvrecorder.com/downloads/qotrdecoder-macosx-universal-0.0.247-r1132.tar.bz2

19. September 2012
11:52
Avatar
Tom
Member
Members
Forum Posts: 174
Member Since:
14. Mai 2012
sp_UserOfflineSmall Offline

[Fortsetzung des Threads aus den Kommentaren (http://apfel-a.macbay.de/2012/05/20/super-otr–0–9–6–0b73/comment-page–1/#comment–1237).]

@Stephan

Vielleicht ist soetwas der Weg zu framegenauen Schnitten.

Wir haben doch schon framegenaue Schnitte beim QT-Schnitt in SOTR. Die Kompressionsartefakte, die raphael beschrieben hat, resultieren aus dem Schnitt mit qotrdecoder, betreffen also das aktuelle SOTR nicht.

Zum letzten mal gab es bei SOTR vergleichbare Probleme nur bei den Schnitten auf dem Avidemux-Weg, da Avidemux(2) auf dem Mac definitiv nicht in der Lage ist frameganau (smart) zu schneiden. Aber das ist ja inzwischen Geschichte!

@all

Ein paar Gedanken zum jetzigen Stand von SOTR – aus meiner Sicht:

So wie ich die Sache sehe, arbeitet SOTR inzwischen sehr gut, was Schnitt und technische Integrität der finalen movs angeht.

QT-Player/iTunes ist ein dedizierter Player für Files nach mpeg–4 part 12/14, und wie wir wissen, zählt er nicht gerade zu den toleranten Playern. Die Tatsache, dass die MP4Box-SOTR-movs darauf einwandfrei und synchron laufen, beruhigt mich ungemein und bringt mich zu der Ansicht, dass sie technisch korrekt sind, was die oben erwähnten Standards betrifft.

Das einzige, kleine Restproblem ist, dass die movs momentan nicht auf allen “third-party”-Playern a/v-synchron laufen. Ich selber zähle leider zu den Besitzern einer WDTV-Live-Box, die auch dieses Problem hat. (Ich habe mir diese Box damals gekauft, als ich noch nicht wusste, wie man aus den OTR-h264-avis korrekte mp4s herstellt; heute würde/werde ich mir eine ATV kaufen …)

Den Umweg über die zusätzliche mkv-Konvertierung für die Filme, die ich auf der WDTV anschauen möchte, nehme ich momentan gern in Kauf. Da ich zu den „Archivierern“ gehöre, ist es mir weitaus wichtiger, dass die SOTR-movs technisch möglichst sauber und Standard-compliant sind, was man ja von den verhackten OTR-h264-mp3-avis nicht gerade behaupten kann.

(BTW, wenn ich das WDTV-Live-Forum überfliege, habe ich den Eindruck, dass der Player ziemlich viele Kompatibilitätsprobleme hat, nicht nur mit unseren movs.)

Nichtsdestotrotz ist natürlich die Tatsache, dass die SOTR-movs über eine simple mkv-Konvertierung auch WDTV-synchron gemacht werden können, schon ein Ansporn, in diese Richtung etwas nachzudenken ;)

@Stephan

Auch wenn sich gezeigt hat, dass bei Schnitten ausschließlich an Key-Frames die Sync-Probleme bei nicht-iTunes-Playern nicht auftauchen, habe ich meine Zweifel, dass der Weg über das Erzwingen von Key-Frames der eleganteste/einfachste ist.
Bei dem von dir zitierten Fall im Gleitz-Forum geht es ja darum, zu einem framegenauen Schnitt (smart reencoding) zu kommen, obwohl die verwendete Software dazu eigentlich von Haus aus nicht imstande ist. Das ist bei uns jedoch nicht der Fall, die QT-Schnitte von SOTR sind ja durchaus framegenau.

Hast du dir mal meine Vermutung zum Timecode Media Handler bzw. die Apple Doc dazu durchgelesen? Was denkst du darüber?

EDITED: Formatierung

19. September 2012
14:29
Avatar
Tom
Member
Members
Forum Posts: 174
Member Since:
14. Mai 2012
sp_UserOfflineSmall Offline

Mal in eine andere Richtung:

Hat eigentlich mal jemand versucht, h264-AAC-mp4s, die nicht über den Weg 'OTR-h264-avi -> mp4box-mp4' entstanden sind, mit SOTR (oder MPEG Streamclip) zu schneiden, um zu sehen, ob da auch die Sync-Probleme auf betroffenen Mediaplayern bestehen?
(Also zB mp4s, die in Handbrake codiert oder transcodiert wurden.)

Ich frage das deswegen, weil ich gerade gelernt habe, dass Probleme auch schon durch den h264 mp4 output handler entstehen können (http://doom10.org/index.php?topic=718.0).

Wenn es daran liegen sollte, würde uns das zwar nicht unmittelbar helfen, da wir auf GPAC/mp4box angewiesen sind, aber es hieße, dass es sich lohnen könnte, an den mp4box-Parametern herumzuspielen.

21. September 2012
10:07
Avatar
raphael
Member
Members
Forum Posts: 8
Member Since:
19. September 2012
sp_UserOfflineSmall Offline

Ich habe gestern Abend etwas experimentiert und nachdem ich erst dachte auf etwas gestoßen zu sein, hat sich im Laufe gezeigt, dass sich bei mir (heißt: FireCore MediaPlayer auf einem ATV2, der per SMB auf die Dateien zugreift) das Problem der Asynchronität nicht zuverlässig reproduzieren lässt. Ein- und dieselben Dateien, die zuvor asynchron wurden, waren später lippensynchron oder mit einem anderen, aber tolerierbaren Versatz. Das syslog des AppleTV hat mir auch keine Erkenntnisse geliefert. Ich kann so jedenfalls nicht ordentlich debuggen, da die Ergebnisse scheinbar willkürlich variieren. Ich habe jetzt erstmal einen Bugreport an FireCore abgesetzt.

Nachtrag: Nachdem ich jetzt nochmal mit ein paar Dateien gespielt habe, habe ich zwei (derzeit reproduzierbar) asynchrone HQ-Dateien ausgemacht, die von Super OTR in MP4 umgewandelt und dann geschnitten wurden. Beide Dateien habe ich testweise mit mkvmerge in einen MKV-Container gepackt. Bei Datei 1 kam der hier erwähnte Fehler mit dem negativen Timecode, Datei 2 wurde ohne Hinweis umgepackt. Beide Dateien laufen (derzeit...) synchron auf meinem oben genannten Setup. Allerdings hat Datei 1 Probleme beim Seeking, es ist sehr langsam und bis auf ein paar Artefakte ist alles grau. Die Option "--clusters-in-meta-seek" scheint das leicht verbessert zu haben.

@Tom: setzt du nicht mkvmerge ein und mit welchen Parametern?

22. September 2012
01:31
Avatar
Tom
Member
Members
Forum Posts: 174
Member Since:
14. Mai 2012
sp_UserOfflineSmall Offline

@Tom: setzt du nicht mkvmerge ein und mit welchen Parametern?

Im Terminal ohne Parameter, also ‘mkvmerge -o <outputmovie>.mkv <inputmovie>’, im GUI die Defaultparameter (kannst du im Muxing-Menu nachschauen).

Die Seekingprobleme mit mkvs habe ich auf der WDTV-Box auch. Allerdings, wenn ich mich recht erinnere, war das Seeking nach der Rückkonvertierung (mkv -> mp4/mov via ffmpeg) wieder OK.
‘–clusters-in-meta-seek’ habe ich noch nicht ausprobiert.

Die Meldung mit dem negativen Timecode ist m.E. irrelevant, was die Asynchronität betrifft. (Hat wahrscheinlich nur was mit dem Interleaving zu tun.)

das Problem der Asynchronität nicht zuverlässig reproduzieren lässt. Ein- und dieselben Dateien, die zuvor asynchron wurden, waren später lippensynchron oder mit einem anderen, aber tolerierbaren Versatz.

Das könnte für meine Vermutung sprechen, dass die betroffenen Mediaplayer den Quicktime-Timecode mehr oder weniger fehlerhaft lesen (zumindest nicht so, wie es vorgesehen ist).

Bugreport an FireCore abgesetzt

Gute Idee. Vielleicht kommt da ja ne verwertbare Antwort …

22. September 2012
15:54
Avatar
raphael
Member
Members
Forum Posts: 8
Member Since:
19. September 2012
sp_UserOfflineSmall Offline

Ich habe versucht eines der MKVs zurückzupacken, aber ffmpeg (0.11.2) kapituliert:

ffmpeg -i foo.mkv -f mp4 -vcodec copy -acodec copy ./foo.mp4

[h264 @ 0x7fc593813800] Missing reference picture
[h264 @ 0x7fc593813800] decode_slice_header error
[h264 @ 0x7fc593813800] concealing 1620 DC, 1620 AC, 1620 MV errors
[h264 @ 0x7fc593813800] Missing reference picture
[h264 @ 0x7fc593813800] decode_slice_header error
[h264 @ 0x7fc593813800] concealing 1620 DC, 1620 AC, 1620 MV errors
[h264 @ 0x7fc593813800] Missing reference picture

[...]

Application provided invalid, non monotonically increasing dts to muxer in stream 0: 1663280 >= 1663280
av_interleaved_write_frame(): Invalid argument

Ich nehme an, so machst du es auch?

22. September 2012
19:42
Avatar
Tom
Member
Members
Forum Posts: 174
Member Since:
14. Mai 2012
sp_UserOfflineSmall Offline

raphael said
Ich nehme an, so machst du es auch?

Ja, ich hab’s eben nochmal gecheckt (an einem HQ-Film): geht immer noch.

mkvmerge -o movie.mkv movie.mov ffmpeg -i movie.mkv -f mp4 -vcodec copy -acodec copy movie.mp4

mkvmerge v5.0.1
ffmpeg 0.11.1.git

22. September 2012
20:01
Avatar
raphael
Member
Members
Forum Posts: 8
Member Since:
19. September 2012
sp_UserOfflineSmall Offline

mkvmerge -o movie.mkv movie.mov ffmpeg -i movie.mkv -f mp4 -vcodec copy -acodec copy movie.mp4

mkvmerge v5.0.1
ffmpeg 0.11.1.git

Exakt so mache ich es auch. mkvmerge-Versin ist identisch und bei ffmpeg habe ich es sowohl mit 0.11.1, als auch mit der neuen 0.11.2 probiert. Schade, aber mit trägem Seeking kann ich immer noch besser leben, als mit asychronen Ton.

22. September 2012
20:54
Avatar
Tom
Member
Members
Forum Posts: 174
Member Since:
14. Mai 2012
sp_UserOfflineSmall Offline

Nur um sicher zu gehen: Du hast den Film schon durch mp4box laufen lassen vor dem Schnitt?

(Diese ganzen Missing reference errors erinnern mich irgendwie an die delay frames der h264-Tracks in den OTR-avis …)

EDITED:

Diese Meldung

[h264 @ 0x7fc0a3813800] Missing reference picture [h264 @ 0x7fc0a3813800] decode_slice_header error [h264 @ 0x7fc0a3813800] concealing 1620 DC, 1620 AC, 1620 MV errors in P frame

habe ich jetzt hier auch beobachtet. Allerdings nur in einfacher Ausführung und die Konvertierung wird erfolgreich durchgeführt. Den ‘monotonically increasing dts’ error kann ich nicht reproduzieren.

24. September 2012
01:08
Avatar
Tom
Member
Members
Forum Posts: 174
Member Since:
14. Mai 2012
sp_UserOfflineSmall Offline

Heute war wieder Experimentiertag und ich bin auf ein paar interessante Dinge gestoßen.

Als ich ein geschnittenes mov mit ffmpeg bearbeitet habe, fiel mir folgende Warnung auf:

[…] multiple edit list entries, a/v desync might occur, patch welcome

In einem Ffmpeg-Forum findet sich dazu diese Info:

It’s not an error so much as a warning. Mov files can contains EDL data that some quicktime based editing apps tend to create. (And it is a rather stupid feature to put in a distribution format) It means that timestamps in the streams can hop around and that the EDL may dictate that parts of streams should be skipped. Obviously this can cause problems. Results may vary depending on the content of the video. […]

Nachdem dies unser Problem ziemlich gut umschreibt, hab’ ich mal die Atoms (=Boxes) eines geschnittenen, asynchronen movs mit denen eines synchronen, aus mkv zurückkonvertierten movs verglichen.

Atom-Vergleich SOTR-mov vs. mkv-mov

Als erstes fällt auf, dass das XML-Dump[1] des mkv-mov ca. 50% (400000 Zeilen) größer ausfällt als das des SOTR-mov. Quicktime scheint also eine kompaktere Notierung zu verwenden, die dann bei der Konvertierung explizit ausgeschrieben wird.

Edit list entries

Wenn man sich die erwähnten Edit list entries anschaut, stellt sich das so dar:

Das SOTR-mov hat 1 Edit list, die in identischer Form jeweils in der Video- und der Audio-TrackBox steht. In dieser Liste sind die ‘Edit segments’ (in unserem Fall Informationen zu den Schnitten) vermerkt:

Edit list des SOTR-mov (Video und Audio):

<EditListBox EntryCount=“4”>
<BoxInfo Size=“64” Type=“elst”/>
<FullBoxInfo Version=“0” Flags=“0”/>
<EditListEntry Duration=“1274664” MediaTime=“154959” MediaRate=“1”/>
<EditListEntry Duration=“896184” MediaTime=“53404000” MediaRate=“1”/>
<EditListEntry Duration=“1069608” MediaTime=“90920000” MediaRate=“1”/>
<EditListEntry Duration=“751176” MediaTime=“135661000” MediaRate=“1”/>
</EditListBox>

Das mkv-mov hat zwar auch Edit lists für jeden Track, allerdings sind diese voneinander verschieden und enthalten nicht mehr die ursprünglich vorhandenen Edit segments:

Edit list des mkv-mov in der Video-TrackBox:

<EditListBox EntryCount=“2”>
<BoxInfo Size=“40” Type=“elst”/>
<FullBoxInfo Version=“0” Flags=“0”/>
<EditListEntry Duration=“80” MediaTime=“–1” MediaRate=“1”/>
<EditListEntry Duration=“6678200” MediaTime=“40” MediaRate=“1”/>
</EditListBox>

(–1 ist ein leeres Edit)

Edit list des mkv-mov in der Audio-TrackBox:

<EditListBox EntryCount=“1”>
<BoxInfo Size=“28” Type=“elst”/>
<FullBoxInfo Version=“0” Flags=“0”/>
<EditListEntry Duration=“6652791” MediaTime=“0” MediaRate=“1”/>
</EditListBox>

In den Edit lists des mkv-movs sind also nur noch die genauen Startzeiten der Tracks notiert.

SampleTableBoxes

In den Sample tables sitzt die große Menge der Daten. Jeder Track hat seine eigenen Sample tables, jeweils innerhalb des Media atoms:

SOTR-mov

SampleTableBox des Videotracks:

<SampleTableBox>
<BoxInfo Size=“1963178” Type=“stbl”/>

SampleTableBox des Audiotracks:

<SampleTableBox>
<BoxInfo Size=“1878287” Type=“stbl”/>

mkv-mov

SampleTableBox des Videotracks:

<SampleTableBox>
<BoxInfo Size=“2203026” Type=“stbl”/>

SampleTableBox des Audiotracks:

<SampleTableBox>
<BoxInfo Size=“3659891” Type=“stbl”/>

Die Sample tables des Audiotracks des mkv-movs enthalten also doppelt so viele Einträge wie die des ursprünglichen SOTR-movs(!) Wenn man genauer hinschaut, sieht man, dass der größte Unterschied in den Chunk offset tables, in einem Unter-Atom der SampleTableBox, liegt. (Laut Apple-Docs erlauben es die Chunk offset tables, Media data zu referenzieren, auch in Dateien, die keinerlei Atom-Struktur aufweisen.)

Wer sich für die Details interessiert kann sich hier die XML-Dumps herunterladen (mit einer Diff, in der man sehr schön sämtliche Unterschiede zwischen den Dateien sieht).

Verständliche Infos zu den Atoms (Boxes), mit übersichtlichem Strukturbaum, finden sich auch in den Apple-Docs.

Was passiert hier also?

Ganz einfach gesagt: Wenn SOTR (QT) schneidet, dann schneidet es bekanntlich framegenau, also wenn angesagt auch zwischen Key-Frames. Je nachdem, wie weit der Schnitt vom ursprünglichen Key-Frame entfernt ist, ist es mehr oder weniger nötig, das AV-Timing (Audiooffset) um den Schnitt herum neu zu “justieren”.[2]
QT erledigt das dadurch, dass es die modifizierten Sequenzen in die Edit lists des Track atoms schreibt.

Dummerweise scheint es Mediaplayer zu geben, die mit einem Demuxer arbeiten, der das Edit lists atom nicht oder nur teilweise liest. Damit entgehen dem Player natürlich die Sync-Korrekturen um die Schnitte und er spielt das Ganze asynchron ab.

Wenn wir nun das SOTR-mov nach mkv konvertieren liest mkvmerge das Edit lists atom korrekt aus und schreibt die Daten in expliziter Form in die Sample tables. Bei der Rückkonvertierung mit ffmpeg bleiben die Tables erhalten, die relevanten Daten landen (wahrscheinlich) in den Chunk offset tables. Da diese auch von Demuxern gelesen werden, die nur halb mp4/QT-kompatibel sind, spielen nun auch die Problem-Player das Video synchron ab.

Lösung?

Das Edits lists atom scheint im ISO-Standard verankert und die Benutzung desselben durch QT der saubere und übliche Weg zu sein (MP4reg, Multimediawiki, Mplayer-ML).

Von daher erscheint es mir unwahrscheinlich, dass es eine Möglichkeit gibt, QT dazu zu bringen, die Schnitt/Sync-Infos zusätzlich noch in Sample tables zu schreiben. Das wäre IMO auch nicht der wünschenswerte Weg, denn wenn ein Player mit einem korrekten File nicht zurechtkommt, sollte man den Player kompatibel machen und nicht das File “zurechtbiegen”. (Was verbogene files angeht, reichen mir die gehackten avi-h264s von OTR eigentlich ;)

Also, konkrete Lösunswege, so wie sich mir die Situation darstellt:

  • QT-kompatiblen Player/Box benutzen (VLC, iTunes, Apple-TV …).
  • Für nicht kompatible Media-Player file nach mkv konvertieren, abspielen, löschen (zum Archivieren würde ich das SOTR-mov nehmen).
  • Warten bis die Problemplayer einen geeigneten Demuxer verwenden; an den Support schreiben.

  1. mp4box -diso  ↩
  2. Schnitte genau an Key-Frames sind unproblematisch, da diese in den Sync table atoms definiert werden.  ↩
No permission to create posts
Forum Timezone: Europe/Berlin

Most Users Ever Online: 21

Currently Online:
1 Guest(s)

Currently Browsing this Page:
1 Guest(s)

Top Posters:

Tom: 174

Timm: 88

mepaso: 62

Baa: 38

ovicula: 24

matze: 11

raphael: 8

goetzibubu: 7

i-land: 5

Felix: 5

Member Stats:

Guest Posters: 10

Members: 57

Moderators: 0

Admins: 1

Forum Stats:

Groups: 1

Forums: 2

Topics: 73

Posts: 551

Newest Members:

Jerryseiny, AngelkbsrKt, Invawnvenue, AaronDuh, EdwardPAins, noyjfkEmbab

Administrators: Stephan: 56

Avatar

Please consider registering
guest

sp_LogInOut Log In sp_Registration Register

Register | Lost password?
Advanced Search

— Forum Scope —




— Match —





— Forum Options —





Minimum search word length is 3 characters - maximum search word length is 84 characters

No permission to create posts
sp_Feed Topic RSS sp_TopicIcon
Nach Schnitt sind Bild und Ton nicht mehr synchron
8. Juni 2012
18:24
Avatar
sir_dikay
Guest
Guests

Hi,

zunächst einmal ein großes Lob an den/die Verantwortlichen von Super OTR! Ich nutze das Programm schon eine halbe Ewigkeit und bin sehr zufrieden!

Leider habe ich seit einiger Zeit (ca. ab Q4/2011) das Problem, dass Aufnahmen nach dem Schnitt nicht mehr synchron sind, d.h. das Bild hängt häufig um einige Sekunden nach.

So wie ich das beobachten konnte, ist das Problem meist wie folgt:
Der "Eingangsschnitt" ab dem der eigentliche Film, z.B. zu Beginn oder nach einer Werbung, los geht, scheint nicht richtig synchron zu sein. Häufig - nicht immer - sieht man sogar noch einige Sekunden die Bilder der Werbung oder der Altersempfehlung des Senders obwohl der Ton des Films bereits korrekt weiterläuft. Ab dieser Stelle ist dann die Verzögerung vorhanden, da Bild und Ton jeweils mit normaler Geschwindigkeit weiterlaufen. Durch weitere Schnitte/Werbungen verstärkt sich diese Verzögerung dann jeweils.
Die Verzögerungen sowie das sporadisch auftretende Problem bei dem geschnittene Bilder sichtbar werden, sind sowohl mit heruntergeladenen Cutlisten als auch mit manuell in Super OTR geschnittenen Aufnahmen vorhanden - bei denen sehr genau auf den korrekten Frame geachtet wurde.

Bitte bei weiteren Fragen oder Empfehlungen bitte melden. Ich werde regelmäßig in das Forum schauen.

Thx and Bye
dikay

14. Juni 2012
23:28
Avatar
mepaso
Member
Members
Forum Posts: 62
Member Since:
20. Mai 2012
sp_UserOfflineSmall Offline

hi

in der letzten Zeit hat sich bei SuperOTR einiges getan, insbesondere in Bezug auf AppleTV/MP4/iTunes Kompatibilität und Tonsynchronität

Ich empfehle Versionen >= b74

Workflow (siehe auch andere Posts):

HQ-otrkey herunterladen, dekodieren und als MP4 konvertieren (kann SuperOTR automatisch :)
Schneiden
die entstandene .mov Datei (ist quasi MP4 mit richtigem Tonformat) sollte synchron und
auf AppleTV / iTunes benutzbar sein

Sollte es Probleme gebe, diese bitte hier detailiert (Versionen, Workflow) angeben

sl mepaso

sl mepaso

15. Juni 2012
02:22
Avatar
wobie
Guest
Guests

moin,

also ich hab auch, wie schon an anderer Stelle geschrieben, die Probleme mit asynchronem Ton zum Ende des Filmes. OTR mit Safari geladen, mit SOTR in .mov Datei umgewandelt und geschnitten. Dabei ist die .avi Datei noch synchron, aber die.mp4 Datei vor dem Schnitt ist am Ende schon asynchron. Mit b74 und unter 10.7.4. Hab extra noch mal die Unglaublichen vom 17.05.12 in HQ geladen und es probiert. Bei Inglourious Basterds wars auch so.

Gruß
Wolfgang

16. Juni 2012
12:53
Avatar
matze
Member
Members
Forum Posts: 11
Member Since:
28. Mai 2012
sp_UserOfflineSmall Offline

Ich habe auch ein Problem mit Bild Ton Asynchronität.
Aber bei mit ist es Playerabhängig d.h. bei MplayerX ist der Ton schneller als das Bild.
Wenn ich aber die gleiche Aufnahme mit Quicktime abspiele funktioniert alles super.
Komisch, komisch...

21. Juni 2012
10:00
Avatar
BBsan
Guest
Guests

Habe das Problem auch. Ich glaube das liegt an der MP4Box Version.
Habe das ganze bei mir mal mit MP4Box 0.4.6 DEV gemacht und bei mir ist es jetzt in beiden Playern synchron.

Die Asynchronität kann aber auch mit einem Bug in MplayerX bzgl mp4 Dateien zutun haben: in einem MKV Container ist das ganze wieder synchron.
Der Bug lässt sich auf einen Bug in ffmpeg zurückführen.
Entsprechend haben einige Programme Probleme mit dem Abspielen von MP4 Dateien (Plex,XBMC,VLC in älteren Versionen, MplayerX, WDLXTV in älteren Versionen, ...).

Ich empfehle für die Archivierung deshalb immer nach dem Schneiden in einen MKV Container zu packen.
BTW: @Stefan kannst du das evtl in SuperOTR implementieren? Man braucht dafür nur MKVToolNix. Der Command dafür ist
[CODE] mkvmerge -o neuerName.mkv -v alterName.mov/mp4 [\CODE]

3. August 2012
17:17
Avatar
Felix
Member
Members
Forum Posts: 5
Member Since:
3. August 2012
sp_UserOfflineSmall Offline

Kann ähnliches Berichten.

Folgendes Setup:

HQ laden -> dekodieren -> Nach MP4 wandeln -> schneiden (nicht avidemux, mit was wird sonst geschnitten? Quicktime?) -> Auf NAS verschieben (D-Link DNS-320)

Wenn ich das ganze auf dem Mac schaue (Quicktime, iTunes, VLC) läuft alles super, wenn ich es aber per DLNA auf dem TV schaue (LG LV5590) ist Bild & Ton durchgehend asynchron.
Wenn ich nun das geschnittene File über MKVToolNix in den MKV-Container packe, läuft es über den TV synchron, kann es dann jedoch nichtmehr auf dem iPad schauen (was schön wäre). MKVToolNix sagt mir bei den geschnittenen Files auch, dass ein negativer Timecode vorliegt, welcher korrigiert wird. Kann es damit zusammenhängen?

Ein weiteres Problem habe ich mit der Auflösung, kann aber auch gut sein, dass es am TV liegt. Bekomme die HQ-Files nicht in Vollbild auf dem TV angezeigt.

13. August 2012
22:40
Avatar
Timm
Member
Members
Forum Posts: 88
Member Since:
14. Mai 2012
sp_UserOfflineSmall Offline

BBsan said
[...]
Ich empfehle für die Archivierung deshalb immer nach dem Schneiden in einen MKV Container zu packen.
[...]

Ich bekomme bei den Files dann immer eine Warnung angezeigt:

Warning: ... This file contains at least one frame with a negative timecode. All timecodes will be adjusted by 00:00:00.040 so that none is negative anymore.

Scheinbar kommt daher die unbeliebte Asynchronität, dass da irgendwer einen bösen negativen Timecode einbaut ;)

15. August 2012
00:00
Avatar
Tom
Member
Members
Forum Posts: 174
Member Since:
14. Mai 2012
sp_UserOfflineSmall Offline

Zum Thema 'Asychronität mit Nicht-iTunes-Playern' hab ich etwas in den Kommentaren gepostet: http://wp.me/pb4GA-6Y

Bei Interesse bitte lesen.

Kurzzusammenfassung: Der Player meiner WesternDigital-Box spielt geschnittene Filme absolut synchron ab, wenn alle Schitte an Key-Frames gemacht wurden (mp4). Wenn Nicht-Key-Frame-Schnitte drin sind, kommt er durcheinander und wird asynchron.

Wäre gut, wenn verifiziert werden könnte, ob das auch für andere Player (plex oder wasauchimmer) genauso zutrifft. (Im Post hab ich beschrieben, wie man zu Testzwecken keyframegenau schneiden kann.) Wenn das bei anderen Playern genauso ist, dann hätten wir die Ursache des Problems gefunden, und bräuchten "nur" noch eine programmierte Lösung (>> Stephan;)

15. August 2012
16:10
Avatar
Felix
Member
Members
Forum Posts: 5
Member Since:
3. August 2012
sp_UserOfflineSmall Offline

Hm naja ich so ähnliche Erfahrungen gemacht mit dem LG LV5590 TV per DLNA.

Hast du das mit den AVI oder HQ Aufnahmen gemacht?

Mein Vorgehen momentan, damit ich synchrone Aufnahmen bekomme:

Bei HQ: In SuperOTR rein und einmal volles Programm (Dec, mp4, schneiden). Die .mov dann in MKVToolNix, die mkv dann mit Subler ein bisschen Meta-Auffrischen und als mp4 wieder abspeichern. Dann läuft das, geht natürlich nicht mehr Hand in Hand und dauert auch etwas.

Bei AVI: In SuperOTR rein, Dec. und MP4 Wandeln. Die dann mit MPEG-Streamclip schneiden.

16. August 2012
09:18
Avatar
Tom
Member
Members
Forum Posts: 174
Member Since:
14. Mai 2012
sp_UserOfflineSmall Offline

Felix said

Hast du das mit den AVI oder HQ Aufnahmen gemacht?

Aus HQ-avi (h264) konvertiertes mp4.

Die nicht-HQ(h264)-Filme ("divx-avis") von OTR sind von Haus aus eher problemlos; meistens konvertiere ich die gar nicht.

19. September 2012
10:13
Avatar
raphael
Member
Members
Forum Posts: 8
Member Since:
19. September 2012
sp_UserOfflineSmall Offline

Ich hatte hier schon geschrieben, dass ich das gleiche Problem habe, dieses aber mit dem qotrdecoder und meinem Skript nicht auftritt.

@Tom: Danke für den Hinweis wegen der Artefakte. Das klingt plausibel und es wäre schön, wenn das noch in den Griff zu bekommen wäre. Den AudioEncoder könnte ich sicherlich wechseln, ich habe aber auch mit ffmpeg bisher keine Probleme gehabt.

@Stephan: Bei qotrdecoder kommt folgende geschnittene (HQ)-Datei heraus (ffmpeg -i):

encoder: Lavf52.31.0
Duration: 00:20:26.04, start: 0.000000, bitrate: 1064 kb/s
Stream #0:0: Video: h264 (High) (H264 / 0x34363248), yuv420p, 720x576 [SAR 64:45 DAR 16:9], 25 fps, 25 tbr, 25 tbn, 50 tbc
Stream #0:1: Audio: mp3 (U[0][0][0] / 0x0055), 48000 Hz, stereo, s16, 192 kb/s

Edit: Wenn ich von qotrdecoder rede, meine ich das Teil hier: http://www.onlinetvrecorder.com/downloads/qotrdecoder-macosx-universal-0.0.247-r1132.tar.bz2

19. September 2012
11:52
Avatar
Tom
Member
Members
Forum Posts: 174
Member Since:
14. Mai 2012
sp_UserOfflineSmall Offline

[Fortsetzung des Threads aus den Kommentaren (http://apfel-a.macbay.de/2012/05/20/super-otr–0–9–6–0b73/comment-page–1/#comment–1237).]

@Stephan

Vielleicht ist soetwas der Weg zu framegenauen Schnitten.

Wir haben doch schon framegenaue Schnitte beim QT-Schnitt in SOTR. Die Kompressionsartefakte, die raphael beschrieben hat, resultieren aus dem Schnitt mit qotrdecoder, betreffen also das aktuelle SOTR nicht.

Zum letzten mal gab es bei SOTR vergleichbare Probleme nur bei den Schnitten auf dem Avidemux-Weg, da Avidemux(2) auf dem Mac definitiv nicht in der Lage ist frameganau (smart) zu schneiden. Aber das ist ja inzwischen Geschichte!

@all

Ein paar Gedanken zum jetzigen Stand von SOTR – aus meiner Sicht:

So wie ich die Sache sehe, arbeitet SOTR inzwischen sehr gut, was Schnitt und technische Integrität der finalen movs angeht.

QT-Player/iTunes ist ein dedizierter Player für Files nach mpeg–4 part 12/14, und wie wir wissen, zählt er nicht gerade zu den toleranten Playern. Die Tatsache, dass die MP4Box-SOTR-movs darauf einwandfrei und synchron laufen, beruhigt mich ungemein und bringt mich zu der Ansicht, dass sie technisch korrekt sind, was die oben erwähnten Standards betrifft.

Das einzige, kleine Restproblem ist, dass die movs momentan nicht auf allen “third-party”-Playern a/v-synchron laufen. Ich selber zähle leider zu den Besitzern einer WDTV-Live-Box, die auch dieses Problem hat. (Ich habe mir diese Box damals gekauft, als ich noch nicht wusste, wie man aus den OTR-h264-avis korrekte mp4s herstellt; heute würde/werde ich mir eine ATV kaufen …)

Den Umweg über die zusätzliche mkv-Konvertierung für die Filme, die ich auf der WDTV anschauen möchte, nehme ich momentan gern in Kauf. Da ich zu den „Archivierern“ gehöre, ist es mir weitaus wichtiger, dass die SOTR-movs technisch möglichst sauber und Standard-compliant sind, was man ja von den verhackten OTR-h264-mp3-avis nicht gerade behaupten kann.

(BTW, wenn ich das WDTV-Live-Forum überfliege, habe ich den Eindruck, dass der Player ziemlich viele Kompatibilitätsprobleme hat, nicht nur mit unseren movs.)

Nichtsdestotrotz ist natürlich die Tatsache, dass die SOTR-movs über eine simple mkv-Konvertierung auch WDTV-synchron gemacht werden können, schon ein Ansporn, in diese Richtung etwas nachzudenken ;)

@Stephan

Auch wenn sich gezeigt hat, dass bei Schnitten ausschließlich an Key-Frames die Sync-Probleme bei nicht-iTunes-Playern nicht auftauchen, habe ich meine Zweifel, dass der Weg über das Erzwingen von Key-Frames der eleganteste/einfachste ist.
Bei dem von dir zitierten Fall im Gleitz-Forum geht es ja darum, zu einem framegenauen Schnitt (smart reencoding) zu kommen, obwohl die verwendete Software dazu eigentlich von Haus aus nicht imstande ist. Das ist bei uns jedoch nicht der Fall, die QT-Schnitte von SOTR sind ja durchaus framegenau.

Hast du dir mal meine Vermutung zum Timecode Media Handler bzw. die Apple Doc dazu durchgelesen? Was denkst du darüber?

EDITED: Formatierung

19. September 2012
14:29
Avatar
Tom
Member
Members
Forum Posts: 174
Member Since:
14. Mai 2012
sp_UserOfflineSmall Offline

Mal in eine andere Richtung:

Hat eigentlich mal jemand versucht, h264-AAC-mp4s, die nicht über den Weg 'OTR-h264-avi -> mp4box-mp4' entstanden sind, mit SOTR (oder MPEG Streamclip) zu schneiden, um zu sehen, ob da auch die Sync-Probleme auf betroffenen Mediaplayern bestehen?
(Also zB mp4s, die in Handbrake codiert oder transcodiert wurden.)

Ich frage das deswegen, weil ich gerade gelernt habe, dass Probleme auch schon durch den h264 mp4 output handler entstehen können (http://doom10.org/index.php?topic=718.0).

Wenn es daran liegen sollte, würde uns das zwar nicht unmittelbar helfen, da wir auf GPAC/mp4box angewiesen sind, aber es hieße, dass es sich lohnen könnte, an den mp4box-Parametern herumzuspielen.

21. September 2012
10:07
Avatar
raphael
Member
Members
Forum Posts: 8
Member Since:
19. September 2012
sp_UserOfflineSmall Offline

Ich habe gestern Abend etwas experimentiert und nachdem ich erst dachte auf etwas gestoßen zu sein, hat sich im Laufe gezeigt, dass sich bei mir (heißt: FireCore MediaPlayer auf einem ATV2, der per SMB auf die Dateien zugreift) das Problem der Asynchronität nicht zuverlässig reproduzieren lässt. Ein- und dieselben Dateien, die zuvor asynchron wurden, waren später lippensynchron oder mit einem anderen, aber tolerierbaren Versatz. Das syslog des AppleTV hat mir auch keine Erkenntnisse geliefert. Ich kann so jedenfalls nicht ordentlich debuggen, da die Ergebnisse scheinbar willkürlich variieren. Ich habe jetzt erstmal einen Bugreport an FireCore abgesetzt.

Nachtrag: Nachdem ich jetzt nochmal mit ein paar Dateien gespielt habe, habe ich zwei (derzeit reproduzierbar) asynchrone HQ-Dateien ausgemacht, die von Super OTR in MP4 umgewandelt und dann geschnitten wurden. Beide Dateien habe ich testweise mit mkvmerge in einen MKV-Container gepackt. Bei Datei 1 kam der hier erwähnte Fehler mit dem negativen Timecode, Datei 2 wurde ohne Hinweis umgepackt. Beide Dateien laufen (derzeit...) synchron auf meinem oben genannten Setup. Allerdings hat Datei 1 Probleme beim Seeking, es ist sehr langsam und bis auf ein paar Artefakte ist alles grau. Die Option "--clusters-in-meta-seek" scheint das leicht verbessert zu haben.

@Tom: setzt du nicht mkvmerge ein und mit welchen Parametern?

22. September 2012
01:31
Avatar
Tom
Member
Members
Forum Posts: 174
Member Since:
14. Mai 2012
sp_UserOfflineSmall Offline

@Tom: setzt du nicht mkvmerge ein und mit welchen Parametern?

Im Terminal ohne Parameter, also ‘mkvmerge -o <outputmovie>.mkv <inputmovie>’, im GUI die Defaultparameter (kannst du im Muxing-Menu nachschauen).

Die Seekingprobleme mit mkvs habe ich auf der WDTV-Box auch. Allerdings, wenn ich mich recht erinnere, war das Seeking nach der Rückkonvertierung (mkv -> mp4/mov via ffmpeg) wieder OK.
‘–clusters-in-meta-seek’ habe ich noch nicht ausprobiert.

Die Meldung mit dem negativen Timecode ist m.E. irrelevant, was die Asynchronität betrifft. (Hat wahrscheinlich nur was mit dem Interleaving zu tun.)

das Problem der Asynchronität nicht zuverlässig reproduzieren lässt. Ein- und dieselben Dateien, die zuvor asynchron wurden, waren später lippensynchron oder mit einem anderen, aber tolerierbaren Versatz.

Das könnte für meine Vermutung sprechen, dass die betroffenen Mediaplayer den Quicktime-Timecode mehr oder weniger fehlerhaft lesen (zumindest nicht so, wie es vorgesehen ist).

Bugreport an FireCore abgesetzt

Gute Idee. Vielleicht kommt da ja ne verwertbare Antwort …

22. September 2012
15:54
Avatar
raphael
Member
Members
Forum Posts: 8
Member Since:
19. September 2012
sp_UserOfflineSmall Offline

Ich habe versucht eines der MKVs zurückzupacken, aber ffmpeg (0.11.2) kapituliert:

ffmpeg -i foo.mkv -f mp4 -vcodec copy -acodec copy ./foo.mp4

[h264 @ 0x7fc593813800] Missing reference picture
[h264 @ 0x7fc593813800] decode_slice_header error
[h264 @ 0x7fc593813800] concealing 1620 DC, 1620 AC, 1620 MV errors
[h264 @ 0x7fc593813800] Missing reference picture
[h264 @ 0x7fc593813800] decode_slice_header error
[h264 @ 0x7fc593813800] concealing 1620 DC, 1620 AC, 1620 MV errors
[h264 @ 0x7fc593813800] Missing reference picture

[...]

Application provided invalid, non monotonically increasing dts to muxer in stream 0: 1663280 >= 1663280
av_interleaved_write_frame(): Invalid argument

Ich nehme an, so machst du es auch?

22. September 2012
19:42
Avatar
Tom
Member
Members
Forum Posts: 174
Member Since:
14. Mai 2012
sp_UserOfflineSmall Offline

raphael said
Ich nehme an, so machst du es auch?

Ja, ich hab’s eben nochmal gecheckt (an einem HQ-Film): geht immer noch.

mkvmerge -o movie.mkv movie.mov ffmpeg -i movie.mkv -f mp4 -vcodec copy -acodec copy movie.mp4

mkvmerge v5.0.1
ffmpeg 0.11.1.git

22. September 2012
20:01
Avatar
raphael
Member
Members
Forum Posts: 8
Member Since:
19. September 2012
sp_UserOfflineSmall Offline

mkvmerge -o movie.mkv movie.mov ffmpeg -i movie.mkv -f mp4 -vcodec copy -acodec copy movie.mp4

mkvmerge v5.0.1
ffmpeg 0.11.1.git

Exakt so mache ich es auch. mkvmerge-Versin ist identisch und bei ffmpeg habe ich es sowohl mit 0.11.1, als auch mit der neuen 0.11.2 probiert. Schade, aber mit trägem Seeking kann ich immer noch besser leben, als mit asychronen Ton.

22. September 2012
20:54
Avatar
Tom
Member
Members
Forum Posts: 174
Member Since:
14. Mai 2012
sp_UserOfflineSmall Offline

Nur um sicher zu gehen: Du hast den Film schon durch mp4box laufen lassen vor dem Schnitt?

(Diese ganzen Missing reference errors erinnern mich irgendwie an die delay frames der h264-Tracks in den OTR-avis …)

EDITED:

Diese Meldung

[h264 @ 0x7fc0a3813800] Missing reference picture [h264 @ 0x7fc0a3813800] decode_slice_header error [h264 @ 0x7fc0a3813800] concealing 1620 DC, 1620 AC, 1620 MV errors in P frame

habe ich jetzt hier auch beobachtet. Allerdings nur in einfacher Ausführung und die Konvertierung wird erfolgreich durchgeführt. Den ‘monotonically increasing dts’ error kann ich nicht reproduzieren.

24. September 2012
01:08
Avatar
Tom
Member
Members
Forum Posts: 174
Member Since:
14. Mai 2012
sp_UserOfflineSmall Offline

Heute war wieder Experimentiertag und ich bin auf ein paar interessante Dinge gestoßen.

Als ich ein geschnittenes mov mit ffmpeg bearbeitet habe, fiel mir folgende Warnung auf:

[…] multiple edit list entries, a/v desync might occur, patch welcome

In einem Ffmpeg-Forum findet sich dazu diese Info:

It’s not an error so much as a warning. Mov files can contains EDL data that some quicktime based editing apps tend to create. (And it is a rather stupid feature to put in a distribution format) It means that timestamps in the streams can hop around and that the EDL may dictate that parts of streams should be skipped. Obviously this can cause problems. Results may vary depending on the content of the video. […]

Nachdem dies unser Problem ziemlich gut umschreibt, hab’ ich mal die Atoms (=Boxes) eines geschnittenen, asynchronen movs mit denen eines synchronen, aus mkv zurückkonvertierten movs verglichen.

Atom-Vergleich SOTR-mov vs. mkv-mov

Als erstes fällt auf, dass das XML-Dump[1] des mkv-mov ca. 50% (400000 Zeilen) größer ausfällt als das des SOTR-mov. Quicktime scheint also eine kompaktere Notierung zu verwenden, die dann bei der Konvertierung explizit ausgeschrieben wird.

Edit list entries

Wenn man sich die erwähnten Edit list entries anschaut, stellt sich das so dar:

Das SOTR-mov hat 1 Edit list, die in identischer Form jeweils in der Video- und der Audio-TrackBox steht. In dieser Liste sind die ‘Edit segments’ (in unserem Fall Informationen zu den Schnitten) vermerkt:

Edit list des SOTR-mov (Video und Audio):

<EditListBox EntryCount=“4”>
<BoxInfo Size=“64” Type=“elst”/>
<FullBoxInfo Version=“0” Flags=“0”/>
<EditListEntry Duration=“1274664” MediaTime=“154959” MediaRate=“1”/>
<EditListEntry Duration=“896184” MediaTime=“53404000” MediaRate=“1”/>
<EditListEntry Duration=“1069608” MediaTime=“90920000” MediaRate=“1”/>
<EditListEntry Duration=“751176” MediaTime=“135661000” MediaRate=“1”/>
</EditListBox>

Das mkv-mov hat zwar auch Edit lists für jeden Track, allerdings sind diese voneinander verschieden und enthalten nicht mehr die ursprünglich vorhandenen Edit segments:

Edit list des mkv-mov in der Video-TrackBox:

<EditListBox EntryCount=“2”>
<BoxInfo Size=“40” Type=“elst”/>
<FullBoxInfo Version=“0” Flags=“0”/>
<EditListEntry Duration=“80” MediaTime=“–1” MediaRate=“1”/>
<EditListEntry Duration=“6678200” MediaTime=“40” MediaRate=“1”/>
</EditListBox>

(–1 ist ein leeres Edit)

Edit list des mkv-mov in der Audio-TrackBox:

<EditListBox EntryCount=“1”>
<BoxInfo Size=“28” Type=“elst”/>
<FullBoxInfo Version=“0” Flags=“0”/>
<EditListEntry Duration=“6652791” MediaTime=“0” MediaRate=“1”/>
</EditListBox>

In den Edit lists des mkv-movs sind also nur noch die genauen Startzeiten der Tracks notiert.

SampleTableBoxes

In den Sample tables sitzt die große Menge der Daten. Jeder Track hat seine eigenen Sample tables, jeweils innerhalb des Media atoms:

SOTR-mov

SampleTableBox des Videotracks:

<SampleTableBox>
<BoxInfo Size=“1963178” Type=“stbl”/>

SampleTableBox des Audiotracks:

<SampleTableBox>
<BoxInfo Size=“1878287” Type=“stbl”/>

mkv-mov

SampleTableBox des Videotracks:

<SampleTableBox>
<BoxInfo Size=“2203026” Type=“stbl”/>

SampleTableBox des Audiotracks:

<SampleTableBox>
<BoxInfo Size=“3659891” Type=“stbl”/>

Die Sample tables des Audiotracks des mkv-movs enthalten also doppelt so viele Einträge wie die des ursprünglichen SOTR-movs(!) Wenn man genauer hinschaut, sieht man, dass der größte Unterschied in den Chunk offset tables, in einem Unter-Atom der SampleTableBox, liegt. (Laut Apple-Docs erlauben es die Chunk offset tables, Media data zu referenzieren, auch in Dateien, die keinerlei Atom-Struktur aufweisen.)

Wer sich für die Details interessiert kann sich hier die XML-Dumps herunterladen (mit einer Diff, in der man sehr schön sämtliche Unterschiede zwischen den Dateien sieht).

Verständliche Infos zu den Atoms (Boxes), mit übersichtlichem Strukturbaum, finden sich auch in den Apple-Docs.

Was passiert hier also?

Ganz einfach gesagt: Wenn SOTR (QT) schneidet, dann schneidet es bekanntlich framegenau, also wenn angesagt auch zwischen Key-Frames. Je nachdem, wie weit der Schnitt vom ursprünglichen Key-Frame entfernt ist, ist es mehr oder weniger nötig, das AV-Timing (Audiooffset) um den Schnitt herum neu zu “justieren”.[2]
QT erledigt das dadurch, dass es die modifizierten Sequenzen in die Edit lists des Track atoms schreibt.

Dummerweise scheint es Mediaplayer zu geben, die mit einem Demuxer arbeiten, der das Edit lists atom nicht oder nur teilweise liest. Damit entgehen dem Player natürlich die Sync-Korrekturen um die Schnitte und er spielt das Ganze asynchron ab.

Wenn wir nun das SOTR-mov nach mkv konvertieren liest mkvmerge das Edit lists atom korrekt aus und schreibt die Daten in expliziter Form in die Sample tables. Bei der Rückkonvertierung mit ffmpeg bleiben die Tables erhalten, die relevanten Daten landen (wahrscheinlich) in den Chunk offset tables. Da diese auch von Demuxern gelesen werden, die nur halb mp4/QT-kompatibel sind, spielen nun auch die Problem-Player das Video synchron ab.

Lösung?

Das Edits lists atom scheint im ISO-Standard verankert und die Benutzung desselben durch QT der saubere und übliche Weg zu sein (MP4reg, Multimediawiki, Mplayer-ML).

Von daher erscheint es mir unwahrscheinlich, dass es eine Möglichkeit gibt, QT dazu zu bringen, die Schnitt/Sync-Infos zusätzlich noch in Sample tables zu schreiben. Das wäre IMO auch nicht der wünschenswerte Weg, denn wenn ein Player mit einem korrekten File nicht zurechtkommt, sollte man den Player kompatibel machen und nicht das File “zurechtbiegen”. (Was verbogene files angeht, reichen mir die gehackten avi-h264s von OTR eigentlich ;)

Also, konkrete Lösunswege, so wie sich mir die Situation darstellt:

  • QT-kompatiblen Player/Box benutzen (VLC, iTunes, Apple-TV …).
  • Für nicht kompatible Media-Player file nach mkv konvertieren, abspielen, löschen (zum Archivieren würde ich das SOTR-mov nehmen).
  • Warten bis die Problemplayer einen geeigneten Demuxer verwenden; an den Support schreiben.

  1. mp4box -diso  ↩
  2. Schnitte genau an Key-Frames sind unproblematisch, da diese in den Sync table atoms definiert werden.  ↩
No permission to create posts
Forum Timezone: Europe/Berlin

Most Users Ever Online: 21

Currently Online:
1 Guest(s)

Currently Browsing this Page:
1 Guest(s)

Top Posters:

Tom: 174

Timm: 88

mepaso: 62

Baa: 38

ovicula: 24

matze: 11

raphael: 8

goetzibubu: 7

i-land: 5

Felix: 5

Member Stats:

Guest Posters: 10

Members: 57

Moderators: 0

Admins: 1

Forum Stats:

Groups: 1

Forums: 2

Topics: 73

Posts: 551

Newest Members:

Jerryseiny, AngelkbsrKt, Invawnvenue, AaronDuh, EdwardPAins, noyjfkEmbab

Administrators: Stephan: 56

Avatar

Please consider registering
guest

sp_LogInOut Log In sp_Registration Register

Register | Lost password?
Advanced Search

— Forum Scope —




— Match —





— Forum Options —





Minimum search word length is 3 characters - maximum search word length is 84 characters

No permission to create posts
sp_Feed Topic RSS sp_TopicIcon
Nach Schnitt sind Bild und Ton nicht mehr synchron
8. Juni 2012
18:24
Avatar
sir_dikay
Guest
Guests

Hi,

zunächst einmal ein großes Lob an den/die Verantwortlichen von Super OTR! Ich nutze das Programm schon eine halbe Ewigkeit und bin sehr zufrieden!

Leider habe ich seit einiger Zeit (ca. ab Q4/2011) das Problem, dass Aufnahmen nach dem Schnitt nicht mehr synchron sind, d.h. das Bild hängt häufig um einige Sekunden nach.

So wie ich das beobachten konnte, ist das Problem meist wie folgt:
Der "Eingangsschnitt" ab dem der eigentliche Film, z.B. zu Beginn oder nach einer Werbung, los geht, scheint nicht richtig synchron zu sein. Häufig - nicht immer - sieht man sogar noch einige Sekunden die Bilder der Werbung oder der Altersempfehlung des Senders obwohl der Ton des Films bereits korrekt weiterläuft. Ab dieser Stelle ist dann die Verzögerung vorhanden, da Bild und Ton jeweils mit normaler Geschwindigkeit weiterlaufen. Durch weitere Schnitte/Werbungen verstärkt sich diese Verzögerung dann jeweils.
Die Verzögerungen sowie das sporadisch auftretende Problem bei dem geschnittene Bilder sichtbar werden, sind sowohl mit heruntergeladenen Cutlisten als auch mit manuell in Super OTR geschnittenen Aufnahmen vorhanden - bei denen sehr genau auf den korrekten Frame geachtet wurde.

Bitte bei weiteren Fragen oder Empfehlungen bitte melden. Ich werde regelmäßig in das Forum schauen.

Thx and Bye
dikay

14. Juni 2012
23:28
Avatar
mepaso
Member
Members
Forum Posts: 62
Member Since:
20. Mai 2012
sp_UserOfflineSmall Offline

hi

in der letzten Zeit hat sich bei SuperOTR einiges getan, insbesondere in Bezug auf AppleTV/MP4/iTunes Kompatibilität und Tonsynchronität

Ich empfehle Versionen >= b74

Workflow (siehe auch andere Posts):

HQ-otrkey herunterladen, dekodieren und als MP4 konvertieren (kann SuperOTR automatisch :)
Schneiden
die entstandene .mov Datei (ist quasi MP4 mit richtigem Tonformat) sollte synchron und
auf AppleTV / iTunes benutzbar sein

Sollte es Probleme gebe, diese bitte hier detailiert (Versionen, Workflow) angeben

sl mepaso

sl mepaso

15. Juni 2012
02:22
Avatar
wobie
Guest
Guests

moin,

also ich hab auch, wie schon an anderer Stelle geschrieben, die Probleme mit asynchronem Ton zum Ende des Filmes. OTR mit Safari geladen, mit SOTR in .mov Datei umgewandelt und geschnitten. Dabei ist die .avi Datei noch synchron, aber die.mp4 Datei vor dem Schnitt ist am Ende schon asynchron. Mit b74 und unter 10.7.4. Hab extra noch mal die Unglaublichen vom 17.05.12 in HQ geladen und es probiert. Bei Inglourious Basterds wars auch so.

Gruß
Wolfgang

16. Juni 2012
12:53
Avatar
matze
Member
Members
Forum Posts: 11
Member Since:
28. Mai 2012
sp_UserOfflineSmall Offline

Ich habe auch ein Problem mit Bild Ton Asynchronität.
Aber bei mit ist es Playerabhängig d.h. bei MplayerX ist der Ton schneller als das Bild.
Wenn ich aber die gleiche Aufnahme mit Quicktime abspiele funktioniert alles super.
Komisch, komisch...

21. Juni 2012
10:00
Avatar
BBsan
Guest
Guests

Habe das Problem auch. Ich glaube das liegt an der MP4Box Version.
Habe das ganze bei mir mal mit MP4Box 0.4.6 DEV gemacht und bei mir ist es jetzt in beiden Playern synchron.

Die Asynchronität kann aber auch mit einem Bug in MplayerX bzgl mp4 Dateien zutun haben: in einem MKV Container ist das ganze wieder synchron.
Der Bug lässt sich auf einen Bug in ffmpeg zurückführen.
Entsprechend haben einige Programme Probleme mit dem Abspielen von MP4 Dateien (Plex,XBMC,VLC in älteren Versionen, MplayerX, WDLXTV in älteren Versionen, ...).

Ich empfehle für die Archivierung deshalb immer nach dem Schneiden in einen MKV Container zu packen.
BTW: @Stefan kannst du das evtl in SuperOTR implementieren? Man braucht dafür nur MKVToolNix. Der Command dafür ist
[CODE] mkvmerge -o neuerName.mkv -v alterName.mov/mp4 [\CODE]

3. August 2012
17:17
Avatar
Felix
Member
Members
Forum Posts: 5
Member Since:
3. August 2012
sp_UserOfflineSmall Offline

Kann ähnliches Berichten.

Folgendes Setup:

HQ laden -> dekodieren -> Nach MP4 wandeln -> schneiden (nicht avidemux, mit was wird sonst geschnitten? Quicktime?) -> Auf NAS verschieben (D-Link DNS-320)

Wenn ich das ganze auf dem Mac schaue (Quicktime, iTunes, VLC) läuft alles super, wenn ich es aber per DLNA auf dem TV schaue (LG LV5590) ist Bild & Ton durchgehend asynchron.
Wenn ich nun das geschnittene File über MKVToolNix in den MKV-Container packe, läuft es über den TV synchron, kann es dann jedoch nichtmehr auf dem iPad schauen (was schön wäre). MKVToolNix sagt mir bei den geschnittenen Files auch, dass ein negativer Timecode vorliegt, welcher korrigiert wird. Kann es damit zusammenhängen?

Ein weiteres Problem habe ich mit der Auflösung, kann aber auch gut sein, dass es am TV liegt. Bekomme die HQ-Files nicht in Vollbild auf dem TV angezeigt.

13. August 2012
22:40
Avatar
Timm
Member
Members
Forum Posts: 88
Member Since:
14. Mai 2012
sp_UserOfflineSmall Offline

BBsan said
[...]
Ich empfehle für die Archivierung deshalb immer nach dem Schneiden in einen MKV Container zu packen.
[...]

Ich bekomme bei den Files dann immer eine Warnung angezeigt:

Warning: ... This file contains at least one frame with a negative timecode. All timecodes will be adjusted by 00:00:00.040 so that none is negative anymore.

Scheinbar kommt daher die unbeliebte Asynchronität, dass da irgendwer einen bösen negativen Timecode einbaut ;)

15. August 2012
00:00
Avatar
Tom
Member
Members
Forum Posts: 174
Member Since:
14. Mai 2012
sp_UserOfflineSmall Offline

Zum Thema 'Asychronität mit Nicht-iTunes-Playern' hab ich etwas in den Kommentaren gepostet: http://wp.me/pb4GA-6Y

Bei Interesse bitte lesen.

Kurzzusammenfassung: Der Player meiner WesternDigital-Box spielt geschnittene Filme absolut synchron ab, wenn alle Schitte an Key-Frames gemacht wurden (mp4). Wenn Nicht-Key-Frame-Schnitte drin sind, kommt er durcheinander und wird asynchron.

Wäre gut, wenn verifiziert werden könnte, ob das auch für andere Player (plex oder wasauchimmer) genauso zutrifft. (Im Post hab ich beschrieben, wie man zu Testzwecken keyframegenau schneiden kann.) Wenn das bei anderen Playern genauso ist, dann hätten wir die Ursache des Problems gefunden, und bräuchten "nur" noch eine programmierte Lösung (>> Stephan;)

15. August 2012
16:10
Avatar
Felix
Member
Members
Forum Posts: 5
Member Since:
3. August 2012
sp_UserOfflineSmall Offline

Hm naja ich so ähnliche Erfahrungen gemacht mit dem LG LV5590 TV per DLNA.

Hast du das mit den AVI oder HQ Aufnahmen gemacht?

Mein Vorgehen momentan, damit ich synchrone Aufnahmen bekomme:

Bei HQ: In SuperOTR rein und einmal volles Programm (Dec, mp4, schneiden). Die .mov dann in MKVToolNix, die mkv dann mit Subler ein bisschen Meta-Auffrischen und als mp4 wieder abspeichern. Dann läuft das, geht natürlich nicht mehr Hand in Hand und dauert auch etwas.

Bei AVI: In SuperOTR rein, Dec. und MP4 Wandeln. Die dann mit MPEG-Streamclip schneiden.

16. August 2012
09:18
Avatar
Tom
Member
Members
Forum Posts: 174
Member Since:
14. Mai 2012
sp_UserOfflineSmall Offline

Felix said

Hast du das mit den AVI oder HQ Aufnahmen gemacht?

Aus HQ-avi (h264) konvertiertes mp4.

Die nicht-HQ(h264)-Filme ("divx-avis") von OTR sind von Haus aus eher problemlos; meistens konvertiere ich die gar nicht.

19. September 2012
10:13
Avatar
raphael
Member
Members
Forum Posts: 8
Member Since:
19. September 2012
sp_UserOfflineSmall Offline

Ich hatte hier schon geschrieben, dass ich das gleiche Problem habe, dieses aber mit dem qotrdecoder und meinem Skript nicht auftritt.

@Tom: Danke für den Hinweis wegen der Artefakte. Das klingt plausibel und es wäre schön, wenn das noch in den Griff zu bekommen wäre. Den AudioEncoder könnte ich sicherlich wechseln, ich habe aber auch mit ffmpeg bisher keine Probleme gehabt.

@Stephan: Bei qotrdecoder kommt folgende geschnittene (HQ)-Datei heraus (ffmpeg -i):

encoder: Lavf52.31.0
Duration: 00:20:26.04, start: 0.000000, bitrate: 1064 kb/s
Stream #0:0: Video: h264 (High) (H264 / 0x34363248), yuv420p, 720x576 [SAR 64:45 DAR 16:9], 25 fps, 25 tbr, 25 tbn, 50 tbc
Stream #0:1: Audio: mp3 (U[0][0][0] / 0x0055), 48000 Hz, stereo, s16, 192 kb/s

Edit: Wenn ich von qotrdecoder rede, meine ich das Teil hier: http://www.onlinetvrecorder.com/downloads/qotrdecoder-macosx-universal-0.0.247-r1132.tar.bz2

19. September 2012
11:52
Avatar
Tom
Member
Members
Forum Posts: 174
Member Since:
14. Mai 2012
sp_UserOfflineSmall Offline

[Fortsetzung des Threads aus den Kommentaren (http://apfel-a.macbay.de/2012/05/20/super-otr–0–9–6–0b73/comment-page–1/#comment–1237).]

@Stephan

Vielleicht ist soetwas der Weg zu framegenauen Schnitten.

Wir haben doch schon framegenaue Schnitte beim QT-Schnitt in SOTR. Die Kompressionsartefakte, die raphael beschrieben hat, resultieren aus dem Schnitt mit qotrdecoder, betreffen also das aktuelle SOTR nicht.

Zum letzten mal gab es bei SOTR vergleichbare Probleme nur bei den Schnitten auf dem Avidemux-Weg, da Avidemux(2) auf dem Mac definitiv nicht in der Lage ist frameganau (smart) zu schneiden. Aber das ist ja inzwischen Geschichte!

@all

Ein paar Gedanken zum jetzigen Stand von SOTR – aus meiner Sicht:

So wie ich die Sache sehe, arbeitet SOTR inzwischen sehr gut, was Schnitt und technische Integrität der finalen movs angeht.

QT-Player/iTunes ist ein dedizierter Player für Files nach mpeg–4 part 12/14, und wie wir wissen, zählt er nicht gerade zu den toleranten Playern. Die Tatsache, dass die MP4Box-SOTR-movs darauf einwandfrei und synchron laufen, beruhigt mich ungemein und bringt mich zu der Ansicht, dass sie technisch korrekt sind, was die oben erwähnten Standards betrifft.

Das einzige, kleine Restproblem ist, dass die movs momentan nicht auf allen “third-party”-Playern a/v-synchron laufen. Ich selber zähle leider zu den Besitzern einer WDTV-Live-Box, die auch dieses Problem hat. (Ich habe mir diese Box damals gekauft, als ich noch nicht wusste, wie man aus den OTR-h264-avis korrekte mp4s herstellt; heute würde/werde ich mir eine ATV kaufen …)

Den Umweg über die zusätzliche mkv-Konvertierung für die Filme, die ich auf der WDTV anschauen möchte, nehme ich momentan gern in Kauf. Da ich zu den „Archivierern“ gehöre, ist es mir weitaus wichtiger, dass die SOTR-movs technisch möglichst sauber und Standard-compliant sind, was man ja von den verhackten OTR-h264-mp3-avis nicht gerade behaupten kann.

(BTW, wenn ich das WDTV-Live-Forum überfliege, habe ich den Eindruck, dass der Player ziemlich viele Kompatibilitätsprobleme hat, nicht nur mit unseren movs.)

Nichtsdestotrotz ist natürlich die Tatsache, dass die SOTR-movs über eine simple mkv-Konvertierung auch WDTV-synchron gemacht werden können, schon ein Ansporn, in diese Richtung etwas nachzudenken ;)

@Stephan

Auch wenn sich gezeigt hat, dass bei Schnitten ausschließlich an Key-Frames die Sync-Probleme bei nicht-iTunes-Playern nicht auftauchen, habe ich meine Zweifel, dass der Weg über das Erzwingen von Key-Frames der eleganteste/einfachste ist.
Bei dem von dir zitierten Fall im Gleitz-Forum geht es ja darum, zu einem framegenauen Schnitt (smart reencoding) zu kommen, obwohl die verwendete Software dazu eigentlich von Haus aus nicht imstande ist. Das ist bei uns jedoch nicht der Fall, die QT-Schnitte von SOTR sind ja durchaus framegenau.

Hast du dir mal meine Vermutung zum Timecode Media Handler bzw. die Apple Doc dazu durchgelesen? Was denkst du darüber?

EDITED: Formatierung

19. September 2012
14:29
Avatar
Tom
Member
Members
Forum Posts: 174
Member Since:
14. Mai 2012
sp_UserOfflineSmall Offline

Mal in eine andere Richtung:

Hat eigentlich mal jemand versucht, h264-AAC-mp4s, die nicht über den Weg 'OTR-h264-avi -> mp4box-mp4' entstanden sind, mit SOTR (oder MPEG Streamclip) zu schneiden, um zu sehen, ob da auch die Sync-Probleme auf betroffenen Mediaplayern bestehen?
(Also zB mp4s, die in Handbrake codiert oder transcodiert wurden.)

Ich frage das deswegen, weil ich gerade gelernt habe, dass Probleme auch schon durch den h264 mp4 output handler entstehen können (http://doom10.org/index.php?topic=718.0).

Wenn es daran liegen sollte, würde uns das zwar nicht unmittelbar helfen, da wir auf GPAC/mp4box angewiesen sind, aber es hieße, dass es sich lohnen könnte, an den mp4box-Parametern herumzuspielen.

21. September 2012
10:07
Avatar
raphael
Member
Members
Forum Posts: 8
Member Since:
19. September 2012
sp_UserOfflineSmall Offline

Ich habe gestern Abend etwas experimentiert und nachdem ich erst dachte auf etwas gestoßen zu sein, hat sich im Laufe gezeigt, dass sich bei mir (heißt: FireCore MediaPlayer auf einem ATV2, der per SMB auf die Dateien zugreift) das Problem der Asynchronität nicht zuverlässig reproduzieren lässt. Ein- und dieselben Dateien, die zuvor asynchron wurden, waren später lippensynchron oder mit einem anderen, aber tolerierbaren Versatz. Das syslog des AppleTV hat mir auch keine Erkenntnisse geliefert. Ich kann so jedenfalls nicht ordentlich debuggen, da die Ergebnisse scheinbar willkürlich variieren. Ich habe jetzt erstmal einen Bugreport an FireCore abgesetzt.

Nachtrag: Nachdem ich jetzt nochmal mit ein paar Dateien gespielt habe, habe ich zwei (derzeit reproduzierbar) asynchrone HQ-Dateien ausgemacht, die von Super OTR in MP4 umgewandelt und dann geschnitten wurden. Beide Dateien habe ich testweise mit mkvmerge in einen MKV-Container gepackt. Bei Datei 1 kam der hier erwähnte Fehler mit dem negativen Timecode, Datei 2 wurde ohne Hinweis umgepackt. Beide Dateien laufen (derzeit...) synchron auf meinem oben genannten Setup. Allerdings hat Datei 1 Probleme beim Seeking, es ist sehr langsam und bis auf ein paar Artefakte ist alles grau. Die Option "--clusters-in-meta-seek" scheint das leicht verbessert zu haben.

@Tom: setzt du nicht mkvmerge ein und mit welchen Parametern?

22. September 2012
01:31
Avatar
Tom
Member
Members
Forum Posts: 174
Member Since:
14. Mai 2012
sp_UserOfflineSmall Offline

@Tom: setzt du nicht mkvmerge ein und mit welchen Parametern?

Im Terminal ohne Parameter, also ‘mkvmerge -o <outputmovie>.mkv <inputmovie>’, im GUI die Defaultparameter (kannst du im Muxing-Menu nachschauen).

Die Seekingprobleme mit mkvs habe ich auf der WDTV-Box auch. Allerdings, wenn ich mich recht erinnere, war das Seeking nach der Rückkonvertierung (mkv -> mp4/mov via ffmpeg) wieder OK.
‘–clusters-in-meta-seek’ habe ich noch nicht ausprobiert.

Die Meldung mit dem negativen Timecode ist m.E. irrelevant, was die Asynchronität betrifft. (Hat wahrscheinlich nur was mit dem Interleaving zu tun.)

das Problem der Asynchronität nicht zuverlässig reproduzieren lässt. Ein- und dieselben Dateien, die zuvor asynchron wurden, waren später lippensynchron oder mit einem anderen, aber tolerierbaren Versatz.

Das könnte für meine Vermutung sprechen, dass die betroffenen Mediaplayer den Quicktime-Timecode mehr oder weniger fehlerhaft lesen (zumindest nicht so, wie es vorgesehen ist).

Bugreport an FireCore abgesetzt

Gute Idee. Vielleicht kommt da ja ne verwertbare Antwort …

22. September 2012
15:54
Avatar
raphael
Member
Members
Forum Posts: 8
Member Since:
19. September 2012
sp_UserOfflineSmall Offline

Ich habe versucht eines der MKVs zurückzupacken, aber ffmpeg (0.11.2) kapituliert:

ffmpeg -i foo.mkv -f mp4 -vcodec copy -acodec copy ./foo.mp4

[h264 @ 0x7fc593813800] Missing reference picture
[h264 @ 0x7fc593813800] decode_slice_header error
[h264 @ 0x7fc593813800] concealing 1620 DC, 1620 AC, 1620 MV errors
[h264 @ 0x7fc593813800] Missing reference picture
[h264 @ 0x7fc593813800] decode_slice_header error
[h264 @ 0x7fc593813800] concealing 1620 DC, 1620 AC, 1620 MV errors
[h264 @ 0x7fc593813800] Missing reference picture

[...]

Application provided invalid, non monotonically increasing dts to muxer in stream 0: 1663280 >= 1663280
av_interleaved_write_frame(): Invalid argument

Ich nehme an, so machst du es auch?

22. September 2012
19:42
Avatar
Tom
Member
Members
Forum Posts: 174
Member Since:
14. Mai 2012
sp_UserOfflineSmall Offline

raphael said
Ich nehme an, so machst du es auch?

Ja, ich hab’s eben nochmal gecheckt (an einem HQ-Film): geht immer noch.

mkvmerge -o movie.mkv movie.mov ffmpeg -i movie.mkv -f mp4 -vcodec copy -acodec copy movie.mp4

mkvmerge v5.0.1
ffmpeg 0.11.1.git

22. September 2012
20:01
Avatar
raphael
Member
Members
Forum Posts: 8
Member Since:
19. September 2012
sp_UserOfflineSmall Offline

mkvmerge -o movie.mkv movie.mov ffmpeg -i movie.mkv -f mp4 -vcodec copy -acodec copy movie.mp4

mkvmerge v5.0.1
ffmpeg 0.11.1.git

Exakt so mache ich es auch. mkvmerge-Versin ist identisch und bei ffmpeg habe ich es sowohl mit 0.11.1, als auch mit der neuen 0.11.2 probiert. Schade, aber mit trägem Seeking kann ich immer noch besser leben, als mit asychronen Ton.

22. September 2012
20:54
Avatar
Tom
Member
Members
Forum Posts: 174
Member Since:
14. Mai 2012
sp_UserOfflineSmall Offline

Nur um sicher zu gehen: Du hast den Film schon durch mp4box laufen lassen vor dem Schnitt?

(Diese ganzen Missing reference errors erinnern mich irgendwie an die delay frames der h264-Tracks in den OTR-avis …)

EDITED:

Diese Meldung

[h264 @ 0x7fc0a3813800] Missing reference picture [h264 @ 0x7fc0a3813800] decode_slice_header error [h264 @ 0x7fc0a3813800] concealing 1620 DC, 1620 AC, 1620 MV errors in P frame

habe ich jetzt hier auch beobachtet. Allerdings nur in einfacher Ausführung und die Konvertierung wird erfolgreich durchgeführt. Den ‘monotonically increasing dts’ error kann ich nicht reproduzieren.

24. September 2012
01:08
Avatar
Tom
Member
Members
Forum Posts: 174
Member Since:
14. Mai 2012
sp_UserOfflineSmall Offline

Heute war wieder Experimentiertag und ich bin auf ein paar interessante Dinge gestoßen.

Als ich ein geschnittenes mov mit ffmpeg bearbeitet habe, fiel mir folgende Warnung auf:

[…] multiple edit list entries, a/v desync might occur, patch welcome

In einem Ffmpeg-Forum findet sich dazu diese Info:

It’s not an error so much as a warning. Mov files can contains EDL data that some quicktime based editing apps tend to create. (And it is a rather stupid feature to put in a distribution format) It means that timestamps in the streams can hop around and that the EDL may dictate that parts of streams should be skipped. Obviously this can cause problems. Results may vary depending on the content of the video. […]

Nachdem dies unser Problem ziemlich gut umschreibt, hab’ ich mal die Atoms (=Boxes) eines geschnittenen, asynchronen movs mit denen eines synchronen, aus mkv zurückkonvertierten movs verglichen.

Atom-Vergleich SOTR-mov vs. mkv-mov

Als erstes fällt auf, dass das XML-Dump[1] des mkv-mov ca. 50% (400000 Zeilen) größer ausfällt als das des SOTR-mov. Quicktime scheint also eine kompaktere Notierung zu verwenden, die dann bei der Konvertierung explizit ausgeschrieben wird.

Edit list entries

Wenn man sich die erwähnten Edit list entries anschaut, stellt sich das so dar:

Das SOTR-mov hat 1 Edit list, die in identischer Form jeweils in der Video- und der Audio-TrackBox steht. In dieser Liste sind die ‘Edit segments’ (in unserem Fall Informationen zu den Schnitten) vermerkt:

Edit list des SOTR-mov (Video und Audio):

<EditListBox EntryCount=“4”>
<BoxInfo Size=“64” Type=“elst”/>
<FullBoxInfo Version=“0” Flags=“0”/>
<EditListEntry Duration=“1274664” MediaTime=“154959” MediaRate=“1”/>
<EditListEntry Duration=“896184” MediaTime=“53404000” MediaRate=“1”/>
<EditListEntry Duration=“1069608” MediaTime=“90920000” MediaRate=“1”/>
<EditListEntry Duration=“751176” MediaTime=“135661000” MediaRate=“1”/>
</EditListBox>

Das mkv-mov hat zwar auch Edit lists für jeden Track, allerdings sind diese voneinander verschieden und enthalten nicht mehr die ursprünglich vorhandenen Edit segments:

Edit list des mkv-mov in der Video-TrackBox:

<EditListBox EntryCount=“2”>
<BoxInfo Size=“40” Type=“elst”/>
<FullBoxInfo Version=“0” Flags=“0”/>
<EditListEntry Duration=“80” MediaTime=“–1” MediaRate=“1”/>
<EditListEntry Duration=“6678200” MediaTime=“40” MediaRate=“1”/>
</EditListBox>

(–1 ist ein leeres Edit)

Edit list des mkv-mov in der Audio-TrackBox:

<EditListBox EntryCount=“1”>
<BoxInfo Size=“28” Type=“elst”/>
<FullBoxInfo Version=“0” Flags=“0”/>
<EditListEntry Duration=“6652791” MediaTime=“0” MediaRate=“1”/>
</EditListBox>

In den Edit lists des mkv-movs sind also nur noch die genauen Startzeiten der Tracks notiert.

SampleTableBoxes

In den Sample tables sitzt die große Menge der Daten. Jeder Track hat seine eigenen Sample tables, jeweils innerhalb des Media atoms:

SOTR-mov

SampleTableBox des Videotracks:

<SampleTableBox>
<BoxInfo Size=“1963178” Type=“stbl”/>

SampleTableBox des Audiotracks:

<SampleTableBox>
<BoxInfo Size=“1878287” Type=“stbl”/>

mkv-mov

SampleTableBox des Videotracks:

<SampleTableBox>
<BoxInfo Size=“2203026” Type=“stbl”/>

SampleTableBox des Audiotracks:

<SampleTableBox>
<BoxInfo Size=“3659891” Type=“stbl”/>

Die Sample tables des Audiotracks des mkv-movs enthalten also doppelt so viele Einträge wie die des ursprünglichen SOTR-movs(!) Wenn man genauer hinschaut, sieht man, dass der größte Unterschied in den Chunk offset tables, in einem Unter-Atom der SampleTableBox, liegt. (Laut Apple-Docs erlauben es die Chunk offset tables, Media data zu referenzieren, auch in Dateien, die keinerlei Atom-Struktur aufweisen.)

Wer sich für die Details interessiert kann sich hier die XML-Dumps herunterladen (mit einer Diff, in der man sehr schön sämtliche Unterschiede zwischen den Dateien sieht).

Verständliche Infos zu den Atoms (Boxes), mit übersichtlichem Strukturbaum, finden sich auch in den Apple-Docs.

Was passiert hier also?

Ganz einfach gesagt: Wenn SOTR (QT) schneidet, dann schneidet es bekanntlich framegenau, also wenn angesagt auch zwischen Key-Frames. Je nachdem, wie weit der Schnitt vom ursprünglichen Key-Frame entfernt ist, ist es mehr oder weniger nötig, das AV-Timing (Audiooffset) um den Schnitt herum neu zu “justieren”.[2]
QT erledigt das dadurch, dass es die modifizierten Sequenzen in die Edit lists des Track atoms schreibt.

Dummerweise scheint es Mediaplayer zu geben, die mit einem Demuxer arbeiten, der das Edit lists atom nicht oder nur teilweise liest. Damit entgehen dem Player natürlich die Sync-Korrekturen um die Schnitte und er spielt das Ganze asynchron ab.

Wenn wir nun das SOTR-mov nach mkv konvertieren liest mkvmerge das Edit lists atom korrekt aus und schreibt die Daten in expliziter Form in die Sample tables. Bei der Rückkonvertierung mit ffmpeg bleiben die Tables erhalten, die relevanten Daten landen (wahrscheinlich) in den Chunk offset tables. Da diese auch von Demuxern gelesen werden, die nur halb mp4/QT-kompatibel sind, spielen nun auch die Problem-Player das Video synchron ab.

Lösung?

Das Edits lists atom scheint im ISO-Standard verankert und die Benutzung desselben durch QT der saubere und übliche Weg zu sein (MP4reg, Multimediawiki, Mplayer-ML).

Von daher erscheint es mir unwahrscheinlich, dass es eine Möglichkeit gibt, QT dazu zu bringen, die Schnitt/Sync-Infos zusätzlich noch in Sample tables zu schreiben. Das wäre IMO auch nicht der wünschenswerte Weg, denn wenn ein Player mit einem korrekten File nicht zurechtkommt, sollte man den Player kompatibel machen und nicht das File “zurechtbiegen”. (Was verbogene files angeht, reichen mir die gehackten avi-h264s von OTR eigentlich ;)

Also, konkrete Lösunswege, so wie sich mir die Situation darstellt:

  • QT-kompatiblen Player/Box benutzen (VLC, iTunes, Apple-TV …).
  • Für nicht kompatible Media-Player file nach mkv konvertieren, abspielen, löschen (zum Archivieren würde ich das SOTR-mov nehmen).
  • Warten bis die Problemplayer einen geeigneten Demuxer verwenden; an den Support schreiben.

  1. mp4box -diso  ↩
  2. Schnitte genau an Key-Frames sind unproblematisch, da diese in den Sync table atoms definiert werden.  ↩
No permission to create posts
Forum Timezone: Europe/Berlin

Most Users Ever Online: 21

Currently Online:
1 Guest(s)

Currently Browsing this Page:
1 Guest(s)

Top Posters:

Tom: 174

Timm: 88

mepaso: 62

Baa: 38

ovicula: 24

matze: 11

raphael: 8

goetzibubu: 7

i-land: 5

Felix: 5

Member Stats:

Guest Posters: 10

Members: 57

Moderators: 0

Admins: 1

Forum Stats:

Groups: 1

Forums: 2

Topics: 73

Posts: 551

Newest Members:

Jerryseiny, AngelkbsrKt, Invawnvenue, AaronDuh, EdwardPAins, noyjfkEmbab

Administrators: Stephan: 56

Avatar

Please consider registering
guest

sp_LogInOut Log In sp_Registration Register

Register | Lost password?
Advanced Search

— Forum Scope —




— Match —





— Forum Options —





Minimum search word length is 3 characters - maximum search word length is 84 characters

No permission to create posts
sp_Feed Topic RSS sp_TopicIcon
Nach Schnitt sind Bild und Ton nicht mehr synchron
8. Juni 2012
18:24
Avatar
sir_dikay
Guest
Guests

Hi,

zunächst einmal ein großes Lob an den/die Verantwortlichen von Super OTR! Ich nutze das Programm schon eine halbe Ewigkeit und bin sehr zufrieden!

Leider habe ich seit einiger Zeit (ca. ab Q4/2011) das Problem, dass Aufnahmen nach dem Schnitt nicht mehr synchron sind, d.h. das Bild hängt häufig um einige Sekunden nach.

So wie ich das beobachten konnte, ist das Problem meist wie folgt:
Der "Eingangsschnitt" ab dem der eigentliche Film, z.B. zu Beginn oder nach einer Werbung, los geht, scheint nicht richtig synchron zu sein. Häufig - nicht immer - sieht man sogar noch einige Sekunden die Bilder der Werbung oder der Altersempfehlung des Senders obwohl der Ton des Films bereits korrekt weiterläuft. Ab dieser Stelle ist dann die Verzögerung vorhanden, da Bild und Ton jeweils mit normaler Geschwindigkeit weiterlaufen. Durch weitere Schnitte/Werbungen verstärkt sich diese Verzögerung dann jeweils.
Die Verzögerungen sowie das sporadisch auftretende Problem bei dem geschnittene Bilder sichtbar werden, sind sowohl mit heruntergeladenen Cutlisten als auch mit manuell in Super OTR geschnittenen Aufnahmen vorhanden - bei denen sehr genau auf den korrekten Frame geachtet wurde.

Bitte bei weiteren Fragen oder Empfehlungen bitte melden. Ich werde regelmäßig in das Forum schauen.

Thx and Bye
dikay

14. Juni 2012
23:28
Avatar
mepaso
Member
Members
Forum Posts: 62
Member Since:
20. Mai 2012
sp_UserOfflineSmall Offline

hi

in der letzten Zeit hat sich bei SuperOTR einiges getan, insbesondere in Bezug auf AppleTV/MP4/iTunes Kompatibilität und Tonsynchronität

Ich empfehle Versionen >= b74

Workflow (siehe auch andere Posts):

HQ-otrkey herunterladen, dekodieren und als MP4 konvertieren (kann SuperOTR automatisch :)
Schneiden
die entstandene .mov Datei (ist quasi MP4 mit richtigem Tonformat) sollte synchron und
auf AppleTV / iTunes benutzbar sein

Sollte es Probleme gebe, diese bitte hier detailiert (Versionen, Workflow) angeben

sl mepaso

sl mepaso

15. Juni 2012
02:22
Avatar
wobie
Guest
Guests

moin,

also ich hab auch, wie schon an anderer Stelle geschrieben, die Probleme mit asynchronem Ton zum Ende des Filmes. OTR mit Safari geladen, mit SOTR in .mov Datei umgewandelt und geschnitten. Dabei ist die .avi Datei noch synchron, aber die.mp4 Datei vor dem Schnitt ist am Ende schon asynchron. Mit b74 und unter 10.7.4. Hab extra noch mal die Unglaublichen vom 17.05.12 in HQ geladen und es probiert. Bei Inglourious Basterds wars auch so.

Gruß
Wolfgang

16. Juni 2012
12:53
Avatar
matze
Member
Members
Forum Posts: 11
Member Since:
28. Mai 2012
sp_UserOfflineSmall Offline

Ich habe auch ein Problem mit Bild Ton Asynchronität.
Aber bei mit ist es Playerabhängig d.h. bei MplayerX ist der Ton schneller als das Bild.
Wenn ich aber die gleiche Aufnahme mit Quicktime abspiele funktioniert alles super.
Komisch, komisch...

21. Juni 2012
10:00
Avatar
BBsan
Guest
Guests

Habe das Problem auch. Ich glaube das liegt an der MP4Box Version.
Habe das ganze bei mir mal mit MP4Box 0.4.6 DEV gemacht und bei mir ist es jetzt in beiden Playern synchron.

Die Asynchronität kann aber auch mit einem Bug in MplayerX bzgl mp4 Dateien zutun haben: in einem MKV Container ist das ganze wieder synchron.
Der Bug lässt sich auf einen Bug in ffmpeg zurückführen.
Entsprechend haben einige Programme Probleme mit dem Abspielen von MP4 Dateien (Plex,XBMC,VLC in älteren Versionen, MplayerX, WDLXTV in älteren Versionen, ...).

Ich empfehle für die Archivierung deshalb immer nach dem Schneiden in einen MKV Container zu packen.
BTW: @Stefan kannst du das evtl in SuperOTR implementieren? Man braucht dafür nur MKVToolNix. Der Command dafür ist
[CODE] mkvmerge -o neuerName.mkv -v alterName.mov/mp4 [\CODE]

3. August 2012
17:17
Avatar
Felix
Member
Members
Forum Posts: 5
Member Since:
3. August 2012
sp_UserOfflineSmall Offline

Kann ähnliches Berichten.

Folgendes Setup:

HQ laden -> dekodieren -> Nach MP4 wandeln -> schneiden (nicht avidemux, mit was wird sonst geschnitten? Quicktime?) -> Auf NAS verschieben (D-Link DNS-320)

Wenn ich das ganze auf dem Mac schaue (Quicktime, iTunes, VLC) läuft alles super, wenn ich es aber per DLNA auf dem TV schaue (LG LV5590) ist Bild & Ton durchgehend asynchron.
Wenn ich nun das geschnittene File über MKVToolNix in den MKV-Container packe, läuft es über den TV synchron, kann es dann jedoch nichtmehr auf dem iPad schauen (was schön wäre). MKVToolNix sagt mir bei den geschnittenen Files auch, dass ein negativer Timecode vorliegt, welcher korrigiert wird. Kann es damit zusammenhängen?

Ein weiteres Problem habe ich mit der Auflösung, kann aber auch gut sein, dass es am TV liegt. Bekomme die HQ-Files nicht in Vollbild auf dem TV angezeigt.

13. August 2012
22:40
Avatar
Timm
Member
Members
Forum Posts: 88
Member Since:
14. Mai 2012
sp_UserOfflineSmall Offline

BBsan said
[...]
Ich empfehle für die Archivierung deshalb immer nach dem Schneiden in einen MKV Container zu packen.
[...]

Ich bekomme bei den Files dann immer eine Warnung angezeigt:

Warning: ... This file contains at least one frame with a negative timecode. All timecodes will be adjusted by 00:00:00.040 so that none is negative anymore.

Scheinbar kommt daher die unbeliebte Asynchronität, dass da irgendwer einen bösen negativen Timecode einbaut ;)

15. August 2012
00:00
Avatar
Tom
Member
Members
Forum Posts: 174
Member Since:
14. Mai 2012
sp_UserOfflineSmall Offline

Zum Thema 'Asychronität mit Nicht-iTunes-Playern' hab ich etwas in den Kommentaren gepostet: http://wp.me/pb4GA-6Y

Bei Interesse bitte lesen.

Kurzzusammenfassung: Der Player meiner WesternDigital-Box spielt geschnittene Filme absolut synchron ab, wenn alle Schitte an Key-Frames gemacht wurden (mp4). Wenn Nicht-Key-Frame-Schnitte drin sind, kommt er durcheinander und wird asynchron.

Wäre gut, wenn verifiziert werden könnte, ob das auch für andere Player (plex oder wasauchimmer) genauso zutrifft. (Im Post hab ich beschrieben, wie man zu Testzwecken keyframegenau schneiden kann.) Wenn das bei anderen Playern genauso ist, dann hätten wir die Ursache des Problems gefunden, und bräuchten "nur" noch eine programmierte Lösung (>> Stephan;)

15. August 2012
16:10
Avatar
Felix
Member
Members
Forum Posts: 5
Member Since:
3. August 2012
sp_UserOfflineSmall Offline

Hm naja ich so ähnliche Erfahrungen gemacht mit dem LG LV5590 TV per DLNA.

Hast du das mit den AVI oder HQ Aufnahmen gemacht?

Mein Vorgehen momentan, damit ich synchrone Aufnahmen bekomme:

Bei HQ: In SuperOTR rein und einmal volles Programm (Dec, mp4, schneiden). Die .mov dann in MKVToolNix, die mkv dann mit Subler ein bisschen Meta-Auffrischen und als mp4 wieder abspeichern. Dann läuft das, geht natürlich nicht mehr Hand in Hand und dauert auch etwas.

Bei AVI: In SuperOTR rein, Dec. und MP4 Wandeln. Die dann mit MPEG-Streamclip schneiden.

16. August 2012
09:18
Avatar
Tom
Member
Members
Forum Posts: 174
Member Since:
14. Mai 2012
sp_UserOfflineSmall Offline

Felix said

Hast du das mit den AVI oder HQ Aufnahmen gemacht?

Aus HQ-avi (h264) konvertiertes mp4.

Die nicht-HQ(h264)-Filme ("divx-avis") von OTR sind von Haus aus eher problemlos; meistens konvertiere ich die gar nicht.

19. September 2012
10:13
Avatar
raphael
Member
Members
Forum Posts: 8
Member Since:
19. September 2012
sp_UserOfflineSmall Offline

Ich hatte hier schon geschrieben, dass ich das gleiche Problem habe, dieses aber mit dem qotrdecoder und meinem Skript nicht auftritt.

@Tom: Danke für den Hinweis wegen der Artefakte. Das klingt plausibel und es wäre schön, wenn das noch in den Griff zu bekommen wäre. Den AudioEncoder könnte ich sicherlich wechseln, ich habe aber auch mit ffmpeg bisher keine Probleme gehabt.

@Stephan: Bei qotrdecoder kommt folgende geschnittene (HQ)-Datei heraus (ffmpeg -i):

encoder: Lavf52.31.0
Duration: 00:20:26.04, start: 0.000000, bitrate: 1064 kb/s
Stream #0:0: Video: h264 (High) (H264 / 0x34363248), yuv420p, 720x576 [SAR 64:45 DAR 16:9], 25 fps, 25 tbr, 25 tbn, 50 tbc
Stream #0:1: Audio: mp3 (U[0][0][0] / 0x0055), 48000 Hz, stereo, s16, 192 kb/s

Edit: Wenn ich von qotrdecoder rede, meine ich das Teil hier: http://www.onlinetvrecorder.com/downloads/qotrdecoder-macosx-universal-0.0.247-r1132.tar.bz2

19. September 2012
11:52
Avatar
Tom
Member
Members
Forum Posts: 174
Member Since:
14. Mai 2012
sp_UserOfflineSmall Offline

[Fortsetzung des Threads aus den Kommentaren (http://apfel-a.macbay.de/2012/05/20/super-otr–0–9–6–0b73/comment-page–1/#comment–1237).]

@Stephan

Vielleicht ist soetwas der Weg zu framegenauen Schnitten.

Wir haben doch schon framegenaue Schnitte beim QT-Schnitt in SOTR. Die Kompressionsartefakte, die raphael beschrieben hat, resultieren aus dem Schnitt mit qotrdecoder, betreffen also das aktuelle SOTR nicht.

Zum letzten mal gab es bei SOTR vergleichbare Probleme nur bei den Schnitten auf dem Avidemux-Weg, da Avidemux(2) auf dem Mac definitiv nicht in der Lage ist frameganau (smart) zu schneiden. Aber das ist ja inzwischen Geschichte!

@all

Ein paar Gedanken zum jetzigen Stand von SOTR – aus meiner Sicht:

So wie ich die Sache sehe, arbeitet SOTR inzwischen sehr gut, was Schnitt und technische Integrität der finalen movs angeht.

QT-Player/iTunes ist ein dedizierter Player für Files nach mpeg–4 part 12/14, und wie wir wissen, zählt er nicht gerade zu den toleranten Playern. Die Tatsache, dass die MP4Box-SOTR-movs darauf einwandfrei und synchron laufen, beruhigt mich ungemein und bringt mich zu der Ansicht, dass sie technisch korrekt sind, was die oben erwähnten Standards betrifft.

Das einzige, kleine Restproblem ist, dass die movs momentan nicht auf allen “third-party”-Playern a/v-synchron laufen. Ich selber zähle leider zu den Besitzern einer WDTV-Live-Box, die auch dieses Problem hat. (Ich habe mir diese Box damals gekauft, als ich noch nicht wusste, wie man aus den OTR-h264-avis korrekte mp4s herstellt; heute würde/werde ich mir eine ATV kaufen …)

Den Umweg über die zusätzliche mkv-Konvertierung für die Filme, die ich auf der WDTV anschauen möchte, nehme ich momentan gern in Kauf. Da ich zu den „Archivierern“ gehöre, ist es mir weitaus wichtiger, dass die SOTR-movs technisch möglichst sauber und Standard-compliant sind, was man ja von den verhackten OTR-h264-mp3-avis nicht gerade behaupten kann.

(BTW, wenn ich das WDTV-Live-Forum überfliege, habe ich den Eindruck, dass der Player ziemlich viele Kompatibilitätsprobleme hat, nicht nur mit unseren movs.)

Nichtsdestotrotz ist natürlich die Tatsache, dass die SOTR-movs über eine simple mkv-Konvertierung auch WDTV-synchron gemacht werden können, schon ein Ansporn, in diese Richtung etwas nachzudenken ;)

@Stephan

Auch wenn sich gezeigt hat, dass bei Schnitten ausschließlich an Key-Frames die Sync-Probleme bei nicht-iTunes-Playern nicht auftauchen, habe ich meine Zweifel, dass der Weg über das Erzwingen von Key-Frames der eleganteste/einfachste ist.
Bei dem von dir zitierten Fall im Gleitz-Forum geht es ja darum, zu einem framegenauen Schnitt (smart reencoding) zu kommen, obwohl die verwendete Software dazu eigentlich von Haus aus nicht imstande ist. Das ist bei uns jedoch nicht der Fall, die QT-Schnitte von SOTR sind ja durchaus framegenau.

Hast du dir mal meine Vermutung zum Timecode Media Handler bzw. die Apple Doc dazu durchgelesen? Was denkst du darüber?

EDITED: Formatierung

19. September 2012
14:29
Avatar
Tom
Member
Members
Forum Posts: 174
Member Since:
14. Mai 2012
sp_UserOfflineSmall Offline

Mal in eine andere Richtung:

Hat eigentlich mal jemand versucht, h264-AAC-mp4s, die nicht über den Weg 'OTR-h264-avi -> mp4box-mp4' entstanden sind, mit SOTR (oder MPEG Streamclip) zu schneiden, um zu sehen, ob da auch die Sync-Probleme auf betroffenen Mediaplayern bestehen?
(Also zB mp4s, die in Handbrake codiert oder transcodiert wurden.)

Ich frage das deswegen, weil ich gerade gelernt habe, dass Probleme auch schon durch den h264 mp4 output handler entstehen können (http://doom10.org/index.php?topic=718.0).

Wenn es daran liegen sollte, würde uns das zwar nicht unmittelbar helfen, da wir auf GPAC/mp4box angewiesen sind, aber es hieße, dass es sich lohnen könnte, an den mp4box-Parametern herumzuspielen.

21. September 2012
10:07
Avatar
raphael
Member
Members
Forum Posts: 8
Member Since:
19. September 2012
sp_UserOfflineSmall Offline

Ich habe gestern Abend etwas experimentiert und nachdem ich erst dachte auf etwas gestoßen zu sein, hat sich im Laufe gezeigt, dass sich bei mir (heißt: FireCore MediaPlayer auf einem ATV2, der per SMB auf die Dateien zugreift) das Problem der Asynchronität nicht zuverlässig reproduzieren lässt. Ein- und dieselben Dateien, die zuvor asynchron wurden, waren später lippensynchron oder mit einem anderen, aber tolerierbaren Versatz. Das syslog des AppleTV hat mir auch keine Erkenntnisse geliefert. Ich kann so jedenfalls nicht ordentlich debuggen, da die Ergebnisse scheinbar willkürlich variieren. Ich habe jetzt erstmal einen Bugreport an FireCore abgesetzt.

Nachtrag: Nachdem ich jetzt nochmal mit ein paar Dateien gespielt habe, habe ich zwei (derzeit reproduzierbar) asynchrone HQ-Dateien ausgemacht, die von Super OTR in MP4 umgewandelt und dann geschnitten wurden. Beide Dateien habe ich testweise mit mkvmerge in einen MKV-Container gepackt. Bei Datei 1 kam der hier erwähnte Fehler mit dem negativen Timecode, Datei 2 wurde ohne Hinweis umgepackt. Beide Dateien laufen (derzeit...) synchron auf meinem oben genannten Setup. Allerdings hat Datei 1 Probleme beim Seeking, es ist sehr langsam und bis auf ein paar Artefakte ist alles grau. Die Option "--clusters-in-meta-seek" scheint das leicht verbessert zu haben.

@Tom: setzt du nicht mkvmerge ein und mit welchen Parametern?

22. September 2012
01:31
Avatar
Tom
Member
Members
Forum Posts: 174
Member Since:
14. Mai 2012
sp_UserOfflineSmall Offline

@Tom: setzt du nicht mkvmerge ein und mit welchen Parametern?

Im Terminal ohne Parameter, also ‘mkvmerge -o <outputmovie>.mkv <inputmovie>’, im GUI die Defaultparameter (kannst du im Muxing-Menu nachschauen).

Die Seekingprobleme mit mkvs habe ich auf der WDTV-Box auch. Allerdings, wenn ich mich recht erinnere, war das Seeking nach der Rückkonvertierung (mkv -> mp4/mov via ffmpeg) wieder OK.
‘–clusters-in-meta-seek’ habe ich noch nicht ausprobiert.

Die Meldung mit dem negativen Timecode ist m.E. irrelevant, was die Asynchronität betrifft. (Hat wahrscheinlich nur was mit dem Interleaving zu tun.)

das Problem der Asynchronität nicht zuverlässig reproduzieren lässt. Ein- und dieselben Dateien, die zuvor asynchron wurden, waren später lippensynchron oder mit einem anderen, aber tolerierbaren Versatz.

Das könnte für meine Vermutung sprechen, dass die betroffenen Mediaplayer den Quicktime-Timecode mehr oder weniger fehlerhaft lesen (zumindest nicht so, wie es vorgesehen ist).

Bugreport an FireCore abgesetzt

Gute Idee. Vielleicht kommt da ja ne verwertbare Antwort …

22. September 2012
15:54
Avatar
raphael
Member
Members
Forum Posts: 8
Member Since:
19. September 2012
sp_UserOfflineSmall Offline

Ich habe versucht eines der MKVs zurückzupacken, aber ffmpeg (0.11.2) kapituliert:

ffmpeg -i foo.mkv -f mp4 -vcodec copy -acodec copy ./foo.mp4

[h264 @ 0x7fc593813800] Missing reference picture
[h264 @ 0x7fc593813800] decode_slice_header error
[h264 @ 0x7fc593813800] concealing 1620 DC, 1620 AC, 1620 MV errors
[h264 @ 0x7fc593813800] Missing reference picture
[h264 @ 0x7fc593813800] decode_slice_header error
[h264 @ 0x7fc593813800] concealing 1620 DC, 1620 AC, 1620 MV errors
[h264 @ 0x7fc593813800] Missing reference picture

[...]

Application provided invalid, non monotonically increasing dts to muxer in stream 0: 1663280 >= 1663280
av_interleaved_write_frame(): Invalid argument

Ich nehme an, so machst du es auch?

22. September 2012
19:42
Avatar
Tom
Member
Members
Forum Posts: 174
Member Since:
14. Mai 2012
sp_UserOfflineSmall Offline

raphael said
Ich nehme an, so machst du es auch?

Ja, ich hab’s eben nochmal gecheckt (an einem HQ-Film): geht immer noch.

mkvmerge -o movie.mkv movie.mov ffmpeg -i movie.mkv -f mp4 -vcodec copy -acodec copy movie.mp4

mkvmerge v5.0.1
ffmpeg 0.11.1.git

22. September 2012
20:01
Avatar
raphael
Member
Members
Forum Posts: 8
Member Since:
19. September 2012
sp_UserOfflineSmall Offline

mkvmerge -o movie.mkv movie.mov ffmpeg -i movie.mkv -f mp4 -vcodec copy -acodec copy movie.mp4

mkvmerge v5.0.1
ffmpeg 0.11.1.git

Exakt so mache ich es auch. mkvmerge-Versin ist identisch und bei ffmpeg habe ich es sowohl mit 0.11.1, als auch mit der neuen 0.11.2 probiert. Schade, aber mit trägem Seeking kann ich immer noch besser leben, als mit asychronen Ton.

22. September 2012
20:54
Avatar
Tom
Member
Members
Forum Posts: 174
Member Since:
14. Mai 2012
sp_UserOfflineSmall Offline

Nur um sicher zu gehen: Du hast den Film schon durch mp4box laufen lassen vor dem Schnitt?

(Diese ganzen Missing reference errors erinnern mich irgendwie an die delay frames der h264-Tracks in den OTR-avis …)

EDITED:

Diese Meldung

[h264 @ 0x7fc0a3813800] Missing reference picture [h264 @ 0x7fc0a3813800] decode_slice_header error [h264 @ 0x7fc0a3813800] concealing 1620 DC, 1620 AC, 1620 MV errors in P frame

habe ich jetzt hier auch beobachtet. Allerdings nur in einfacher Ausführung und die Konvertierung wird erfolgreich durchgeführt. Den ‘monotonically increasing dts’ error kann ich nicht reproduzieren.

24. September 2012
01:08
Avatar
Tom
Member
Members
Forum Posts: 174
Member Since:
14. Mai 2012
sp_UserOfflineSmall Offline

Heute war wieder Experimentiertag und ich bin auf ein paar interessante Dinge gestoßen.

Als ich ein geschnittenes mov mit ffmpeg bearbeitet habe, fiel mir folgende Warnung auf:

[…] multiple edit list entries, a/v desync might occur, patch welcome

In einem Ffmpeg-Forum findet sich dazu diese Info:

It’s not an error so much as a warning. Mov files can contains EDL data that some quicktime based editing apps tend to create. (And it is a rather stupid feature to put in a distribution format) It means that timestamps in the streams can hop around and that the EDL may dictate that parts of streams should be skipped. Obviously this can cause problems. Results may vary depending on the content of the video. […]

Nachdem dies unser Problem ziemlich gut umschreibt, hab’ ich mal die Atoms (=Boxes) eines geschnittenen, asynchronen movs mit denen eines synchronen, aus mkv zurückkonvertierten movs verglichen.

Atom-Vergleich SOTR-mov vs. mkv-mov

Als erstes fällt auf, dass das XML-Dump[1] des mkv-mov ca. 50% (400000 Zeilen) größer ausfällt als das des SOTR-mov. Quicktime scheint also eine kompaktere Notierung zu verwenden, die dann bei der Konvertierung explizit ausgeschrieben wird.

Edit list entries

Wenn man sich die erwähnten Edit list entries anschaut, stellt sich das so dar:

Das SOTR-mov hat 1 Edit list, die in identischer Form jeweils in der Video- und der Audio-TrackBox steht. In dieser Liste sind die ‘Edit segments’ (in unserem Fall Informationen zu den Schnitten) vermerkt:

Edit list des SOTR-mov (Video und Audio):

<EditListBox EntryCount=“4”>
<BoxInfo Size=“64” Type=“elst”/>
<FullBoxInfo Version=“0” Flags=“0”/>
<EditListEntry Duration=“1274664” MediaTime=“154959” MediaRate=“1”/>
<EditListEntry Duration=“896184” MediaTime=“53404000” MediaRate=“1”/>
<EditListEntry Duration=“1069608” MediaTime=“90920000” MediaRate=“1”/>
<EditListEntry Duration=“751176” MediaTime=“135661000” MediaRate=“1”/>
</EditListBox>

Das mkv-mov hat zwar auch Edit lists für jeden Track, allerdings sind diese voneinander verschieden und enthalten nicht mehr die ursprünglich vorhandenen Edit segments:

Edit list des mkv-mov in der Video-TrackBox:

<EditListBox EntryCount=“2”>
<BoxInfo Size=“40” Type=“elst”/>
<FullBoxInfo Version=“0” Flags=“0”/>
<EditListEntry Duration=“80” MediaTime=“–1” MediaRate=“1”/>
<EditListEntry Duration=“6678200” MediaTime=“40” MediaRate=“1”/>
</EditListBox>

(–1 ist ein leeres Edit)

Edit list des mkv-mov in der Audio-TrackBox:

<EditListBox EntryCount=“1”>
<BoxInfo Size=“28” Type=“elst”/>
<FullBoxInfo Version=“0” Flags=“0”/>
<EditListEntry Duration=“6652791” MediaTime=“0” MediaRate=“1”/>
</EditListBox>

In den Edit lists des mkv-movs sind also nur noch die genauen Startzeiten der Tracks notiert.

SampleTableBoxes

In den Sample tables sitzt die große Menge der Daten. Jeder Track hat seine eigenen Sample tables, jeweils innerhalb des Media atoms:

SOTR-mov

SampleTableBox des Videotracks:

<SampleTableBox>
<BoxInfo Size=“1963178” Type=“stbl”/>

SampleTableBox des Audiotracks:

<SampleTableBox>
<BoxInfo Size=“1878287” Type=“stbl”/>

mkv-mov

SampleTableBox des Videotracks:

<SampleTableBox>
<BoxInfo Size=“2203026” Type=“stbl”/>

SampleTableBox des Audiotracks:

<SampleTableBox>
<BoxInfo Size=“3659891” Type=“stbl”/>

Die Sample tables des Audiotracks des mkv-movs enthalten also doppelt so viele Einträge wie die des ursprünglichen SOTR-movs(!) Wenn man genauer hinschaut, sieht man, dass der größte Unterschied in den Chunk offset tables, in einem Unter-Atom der SampleTableBox, liegt. (Laut Apple-Docs erlauben es die Chunk offset tables, Media data zu referenzieren, auch in Dateien, die keinerlei Atom-Struktur aufweisen.)

Wer sich für die Details interessiert kann sich hier die XML-Dumps herunterladen (mit einer Diff, in der man sehr schön sämtliche Unterschiede zwischen den Dateien sieht).

Verständliche Infos zu den Atoms (Boxes), mit übersichtlichem Strukturbaum, finden sich auch in den Apple-Docs.

Was passiert hier also?

Ganz einfach gesagt: Wenn SOTR (QT) schneidet, dann schneidet es bekanntlich framegenau, also wenn angesagt auch zwischen Key-Frames. Je nachdem, wie weit der Schnitt vom ursprünglichen Key-Frame entfernt ist, ist es mehr oder weniger nötig, das AV-Timing (Audiooffset) um den Schnitt herum neu zu “justieren”.[2]
QT erledigt das dadurch, dass es die modifizierten Sequenzen in die Edit lists des Track atoms schreibt.

Dummerweise scheint es Mediaplayer zu geben, die mit einem Demuxer arbeiten, der das Edit lists atom nicht oder nur teilweise liest. Damit entgehen dem Player natürlich die Sync-Korrekturen um die Schnitte und er spielt das Ganze asynchron ab.

Wenn wir nun das SOTR-mov nach mkv konvertieren liest mkvmerge das Edit lists atom korrekt aus und schreibt die Daten in expliziter Form in die Sample tables. Bei der Rückkonvertierung mit ffmpeg bleiben die Tables erhalten, die relevanten Daten landen (wahrscheinlich) in den Chunk offset tables. Da diese auch von Demuxern gelesen werden, die nur halb mp4/QT-kompatibel sind, spielen nun auch die Problem-Player das Video synchron ab.

Lösung?

Das Edits lists atom scheint im ISO-Standard verankert und die Benutzung desselben durch QT der saubere und übliche Weg zu sein (MP4reg, Multimediawiki, Mplayer-ML).

Von daher erscheint es mir unwahrscheinlich, dass es eine Möglichkeit gibt, QT dazu zu bringen, die Schnitt/Sync-Infos zusätzlich noch in Sample tables zu schreiben. Das wäre IMO auch nicht der wünschenswerte Weg, denn wenn ein Player mit einem korrekten File nicht zurechtkommt, sollte man den Player kompatibel machen und nicht das File “zurechtbiegen”. (Was verbogene files angeht, reichen mir die gehackten avi-h264s von OTR eigentlich ;)

Also, konkrete Lösunswege, so wie sich mir die Situation darstellt:

  • QT-kompatiblen Player/Box benutzen (VLC, iTunes, Apple-TV …).
  • Für nicht kompatible Media-Player file nach mkv konvertieren, abspielen, löschen (zum Archivieren würde ich das SOTR-mov nehmen).
  • Warten bis die Problemplayer einen geeigneten Demuxer verwenden; an den Support schreiben.

  1. mp4box -diso  ↩
  2. Schnitte genau an Key-Frames sind unproblematisch, da diese in den Sync table atoms definiert werden.  ↩
No permission to create posts
Forum Timezone: Europe/Berlin

Most Users Ever Online: 21

Currently Online:
1 Guest(s)

Currently Browsing this Page:
1 Guest(s)

Top Posters:

Tom: 174

Timm: 88

mepaso: 62

Baa: 38

ovicula: 24

matze: 11

raphael: 8

goetzibubu: 7

i-land: 5

Felix: 5

Member Stats:

Guest Posters: 10

Members: 57

Moderators: 0

Admins: 1

Forum Stats:

Groups: 1

Forums: 2

Topics: 73

Posts: 551

Newest Members:

Jerryseiny, AngelkbsrKt, Invawnvenue, AaronDuh, EdwardPAins, noyjfkEmbab

Administrators: Stephan: 56

Nach Schnitt sind Bild und Ton nicht mehr synchron | Bugs + Features Requests | Forum

16. Juni 2012
Avatar

Please consider registering
guest

sp_LogInOut Log In sp_Registration Register

Register | Lost password?
Advanced Search

— Forum Scope —




— Match —





— Forum Options —





Minimum search word length is 3 characters - maximum search word length is 84 characters

No permission to create posts
sp_Feed Topic RSS sp_TopicIcon
Nach Schnitt sind Bild und Ton nicht mehr synchron
8. Juni 2012
18:24
Avatar
sir_dikay
Guest
Guests

Hi,

zunächst einmal ein großes Lob an den/die Verantwortlichen von Super OTR! Ich nutze das Programm schon eine halbe Ewigkeit und bin sehr zufrieden!

Leider habe ich seit einiger Zeit (ca. ab Q4/2011) das Problem, dass Aufnahmen nach dem Schnitt nicht mehr synchron sind, d.h. das Bild hängt häufig um einige Sekunden nach.

So wie ich das beobachten konnte, ist das Problem meist wie folgt:
Der "Eingangsschnitt" ab dem der eigentliche Film, z.B. zu Beginn oder nach einer Werbung, los geht, scheint nicht richtig synchron zu sein. Häufig - nicht immer - sieht man sogar noch einige Sekunden die Bilder der Werbung oder der Altersempfehlung des Senders obwohl der Ton des Films bereits korrekt weiterläuft. Ab dieser Stelle ist dann die Verzögerung vorhanden, da Bild und Ton jeweils mit normaler Geschwindigkeit weiterlaufen. Durch weitere Schnitte/Werbungen verstärkt sich diese Verzögerung dann jeweils.
Die Verzögerungen sowie das sporadisch auftretende Problem bei dem geschnittene Bilder sichtbar werden, sind sowohl mit heruntergeladenen Cutlisten als auch mit manuell in Super OTR geschnittenen Aufnahmen vorhanden - bei denen sehr genau auf den korrekten Frame geachtet wurde.

Bitte bei weiteren Fragen oder Empfehlungen bitte melden. Ich werde regelmäßig in das Forum schauen.

Thx and Bye
dikay

14. Juni 2012
23:28
Avatar
mepaso
Member
Members
Forum Posts: 62
Member Since:
20. Mai 2012
sp_UserOfflineSmall Offline

hi

in der letzten Zeit hat sich bei SuperOTR einiges getan, insbesondere in Bezug auf AppleTV/MP4/iTunes Kompatibilität und Tonsynchronität

Ich empfehle Versionen >= b74

Workflow (siehe auch andere Posts):

HQ-otrkey herunterladen, dekodieren und als MP4 konvertieren (kann SuperOTR automatisch :)
Schneiden
die entstandene .mov Datei (ist quasi MP4 mit richtigem Tonformat) sollte synchron und
auf AppleTV / iTunes benutzbar sein

Sollte es Probleme gebe, diese bitte hier detailiert (Versionen, Workflow) angeben

sl mepaso

sl mepaso

15. Juni 2012
02:22
Avatar
wobie
Guest
Guests

moin,

also ich hab auch, wie schon an anderer Stelle geschrieben, die Probleme mit asynchronem Ton zum Ende des Filmes. OTR mit Safari geladen, mit SOTR in .mov Datei umgewandelt und geschnitten. Dabei ist die .avi Datei noch synchron, aber die.mp4 Datei vor dem Schnitt ist am Ende schon asynchron. Mit b74 und unter 10.7.4. Hab extra noch mal die Unglaublichen vom 17.05.12 in HQ geladen und es probiert. Bei Inglourious Basterds wars auch so.

Gruß
Wolfgang

16. Juni 2012
12:53
Avatar
matze
Member
Members
Forum Posts: 11
Member Since:
28. Mai 2012
sp_UserOfflineSmall Offline

Ich habe auch ein Problem mit Bild Ton Asynchronität.
Aber bei mit ist es Playerabhängig d.h. bei MplayerX ist der Ton schneller als das Bild.
Wenn ich aber die gleiche Aufnahme mit Quicktime abspiele funktioniert alles super.
Komisch, komisch...

21. Juni 2012
10:00
Avatar
BBsan
Guest
Guests

Habe das Problem auch. Ich glaube das liegt an der MP4Box Version.
Habe das ganze bei mir mal mit MP4Box 0.4.6 DEV gemacht und bei mir ist es jetzt in beiden Playern synchron.

Die Asynchronität kann aber auch mit einem Bug in MplayerX bzgl mp4 Dateien zutun haben: in einem MKV Container ist das ganze wieder synchron.
Der Bug lässt sich auf einen Bug in ffmpeg zurückführen.
Entsprechend haben einige Programme Probleme mit dem Abspielen von MP4 Dateien (Plex,XBMC,VLC in älteren Versionen, MplayerX, WDLXTV in älteren Versionen, ...).

Ich empfehle für die Archivierung deshalb immer nach dem Schneiden in einen MKV Container zu packen.
BTW: @Stefan kannst du das evtl in SuperOTR implementieren? Man braucht dafür nur MKVToolNix. Der Command dafür ist
[CODE] mkvmerge -o neuerName.mkv -v alterName.mov/mp4 [\CODE]

3. August 2012
17:17
Avatar
Felix
Member
Members
Forum Posts: 5
Member Since:
3. August 2012
sp_UserOfflineSmall Offline

Kann ähnliches Berichten.

Folgendes Setup:

HQ laden -> dekodieren -> Nach MP4 wandeln -> schneiden (nicht avidemux, mit was wird sonst geschnitten? Quicktime?) -> Auf NAS verschieben (D-Link DNS-320)

Wenn ich das ganze auf dem Mac schaue (Quicktime, iTunes, VLC) läuft alles super, wenn ich es aber per DLNA auf dem TV schaue (LG LV5590) ist Bild & Ton durchgehend asynchron.
Wenn ich nun das geschnittene File über MKVToolNix in den MKV-Container packe, läuft es über den TV synchron, kann es dann jedoch nichtmehr auf dem iPad schauen (was schön wäre). MKVToolNix sagt mir bei den geschnittenen Files auch, dass ein negativer Timecode vorliegt, welcher korrigiert wird. Kann es damit zusammenhängen?

Ein weiteres Problem habe ich mit der Auflösung, kann aber auch gut sein, dass es am TV liegt. Bekomme die HQ-Files nicht in Vollbild auf dem TV angezeigt.

13. August 2012
22:40
Avatar
Timm
Member
Members
Forum Posts: 88
Member Since:
14. Mai 2012
sp_UserOfflineSmall Offline

BBsan said
[...]
Ich empfehle für die Archivierung deshalb immer nach dem Schneiden in einen MKV Container zu packen.
[...]

Ich bekomme bei den Files dann immer eine Warnung angezeigt:

Warning: ... This file contains at least one frame with a negative timecode. All timecodes will be adjusted by 00:00:00.040 so that none is negative anymore.

Scheinbar kommt daher die unbeliebte Asynchronität, dass da irgendwer einen bösen negativen Timecode einbaut ;)

15. August 2012
00:00
Avatar
Tom
Member
Members
Forum Posts: 174
Member Since:
14. Mai 2012
sp_UserOfflineSmall Offline

Zum Thema 'Asychronität mit Nicht-iTunes-Playern' hab ich etwas in den Kommentaren gepostet: http://wp.me/pb4GA-6Y

Bei Interesse bitte lesen.

Kurzzusammenfassung: Der Player meiner WesternDigital-Box spielt geschnittene Filme absolut synchron ab, wenn alle Schitte an Key-Frames gemacht wurden (mp4). Wenn Nicht-Key-Frame-Schnitte drin sind, kommt er durcheinander und wird asynchron.

Wäre gut, wenn verifiziert werden könnte, ob das auch für andere Player (plex oder wasauchimmer) genauso zutrifft. (Im Post hab ich beschrieben, wie man zu Testzwecken keyframegenau schneiden kann.) Wenn das bei anderen Playern genauso ist, dann hätten wir die Ursache des Problems gefunden, und bräuchten "nur" noch eine programmierte Lösung (>> Stephan;)

15. August 2012
16:10
Avatar
Felix
Member
Members
Forum Posts: 5
Member Since:
3. August 2012
sp_UserOfflineSmall Offline

Hm naja ich so ähnliche Erfahrungen gemacht mit dem LG LV5590 TV per DLNA.

Hast du das mit den AVI oder HQ Aufnahmen gemacht?

Mein Vorgehen momentan, damit ich synchrone Aufnahmen bekomme:

Bei HQ: In SuperOTR rein und einmal volles Programm (Dec, mp4, schneiden). Die .mov dann in MKVToolNix, die mkv dann mit Subler ein bisschen Meta-Auffrischen und als mp4 wieder abspeichern. Dann läuft das, geht natürlich nicht mehr Hand in Hand und dauert auch etwas.

Bei AVI: In SuperOTR rein, Dec. und MP4 Wandeln. Die dann mit MPEG-Streamclip schneiden.

16. August 2012
09:18
Avatar
Tom
Member
Members
Forum Posts: 174
Member Since:
14. Mai 2012
sp_UserOfflineSmall Offline

Felix said

Hast du das mit den AVI oder HQ Aufnahmen gemacht?

Aus HQ-avi (h264) konvertiertes mp4.

Die nicht-HQ(h264)-Filme ("divx-avis") von OTR sind von Haus aus eher problemlos; meistens konvertiere ich die gar nicht.

19. September 2012
10:13
Avatar
raphael
Member
Members
Forum Posts: 8
Member Since:
19. September 2012
sp_UserOfflineSmall Offline

Ich hatte hier schon geschrieben, dass ich das gleiche Problem habe, dieses aber mit dem qotrdecoder und meinem Skript nicht auftritt.

@Tom: Danke für den Hinweis wegen der Artefakte. Das klingt plausibel und es wäre schön, wenn das noch in den Griff zu bekommen wäre. Den AudioEncoder könnte ich sicherlich wechseln, ich habe aber auch mit ffmpeg bisher keine Probleme gehabt.

@Stephan: Bei qotrdecoder kommt folgende geschnittene (HQ)-Datei heraus (ffmpeg -i):

encoder: Lavf52.31.0
Duration: 00:20:26.04, start: 0.000000, bitrate: 1064 kb/s
Stream #0:0: Video: h264 (High) (H264 / 0x34363248), yuv420p, 720x576 [SAR 64:45 DAR 16:9], 25 fps, 25 tbr, 25 tbn, 50 tbc
Stream #0:1: Audio: mp3 (U[0][0][0] / 0x0055), 48000 Hz, stereo, s16, 192 kb/s

Edit: Wenn ich von qotrdecoder rede, meine ich das Teil hier: http://www.onlinetvrecorder.com/downloads/qotrdecoder-macosx-universal-0.0.247-r1132.tar.bz2

19. September 2012
11:52
Avatar
Tom
Member
Members
Forum Posts: 174
Member Since:
14. Mai 2012
sp_UserOfflineSmall Offline

[Fortsetzung des Threads aus den Kommentaren (http://apfel-a.macbay.de/2012/05/20/super-otr–0–9–6–0b73/comment-page–1/#comment–1237).]

@Stephan

Vielleicht ist soetwas der Weg zu framegenauen Schnitten.

Wir haben doch schon framegenaue Schnitte beim QT-Schnitt in SOTR. Die Kompressionsartefakte, die raphael beschrieben hat, resultieren aus dem Schnitt mit qotrdecoder, betreffen also das aktuelle SOTR nicht.

Zum letzten mal gab es bei SOTR vergleichbare Probleme nur bei den Schnitten auf dem Avidemux-Weg, da Avidemux(2) auf dem Mac definitiv nicht in der Lage ist frameganau (smart) zu schneiden. Aber das ist ja inzwischen Geschichte!

@all

Ein paar Gedanken zum jetzigen Stand von SOTR – aus meiner Sicht:

So wie ich die Sache sehe, arbeitet SOTR inzwischen sehr gut, was Schnitt und technische Integrität der finalen movs angeht.

QT-Player/iTunes ist ein dedizierter Player für Files nach mpeg–4 part 12/14, und wie wir wissen, zählt er nicht gerade zu den toleranten Playern. Die Tatsache, dass die MP4Box-SOTR-movs darauf einwandfrei und synchron laufen, beruhigt mich ungemein und bringt mich zu der Ansicht, dass sie technisch korrekt sind, was die oben erwähnten Standards betrifft.

Das einzige, kleine Restproblem ist, dass die movs momentan nicht auf allen “third-party”-Playern a/v-synchron laufen. Ich selber zähle leider zu den Besitzern einer WDTV-Live-Box, die auch dieses Problem hat. (Ich habe mir diese Box damals gekauft, als ich noch nicht wusste, wie man aus den OTR-h264-avis korrekte mp4s herstellt; heute würde/werde ich mir eine ATV kaufen …)

Den Umweg über die zusätzliche mkv-Konvertierung für die Filme, die ich auf der WDTV anschauen möchte, nehme ich momentan gern in Kauf. Da ich zu den „Archivierern“ gehöre, ist es mir weitaus wichtiger, dass die SOTR-movs technisch möglichst sauber und Standard-compliant sind, was man ja von den verhackten OTR-h264-mp3-avis nicht gerade behaupten kann.

(BTW, wenn ich das WDTV-Live-Forum überfliege, habe ich den Eindruck, dass der Player ziemlich viele Kompatibilitätsprobleme hat, nicht nur mit unseren movs.)

Nichtsdestotrotz ist natürlich die Tatsache, dass die SOTR-movs über eine simple mkv-Konvertierung auch WDTV-synchron gemacht werden können, schon ein Ansporn, in diese Richtung etwas nachzudenken ;)

@Stephan

Auch wenn sich gezeigt hat, dass bei Schnitten ausschließlich an Key-Frames die Sync-Probleme bei nicht-iTunes-Playern nicht auftauchen, habe ich meine Zweifel, dass der Weg über das Erzwingen von Key-Frames der eleganteste/einfachste ist.
Bei dem von dir zitierten Fall im Gleitz-Forum geht es ja darum, zu einem framegenauen Schnitt (smart reencoding) zu kommen, obwohl die verwendete Software dazu eigentlich von Haus aus nicht imstande ist. Das ist bei uns jedoch nicht der Fall, die QT-Schnitte von SOTR sind ja durchaus framegenau.

Hast du dir mal meine Vermutung zum Timecode Media Handler bzw. die Apple Doc dazu durchgelesen? Was denkst du darüber?

EDITED: Formatierung

19. September 2012
14:29
Avatar
Tom
Member
Members
Forum Posts: 174
Member Since:
14. Mai 2012
sp_UserOfflineSmall Offline

Mal in eine andere Richtung:

Hat eigentlich mal jemand versucht, h264-AAC-mp4s, die nicht über den Weg 'OTR-h264-avi -> mp4box-mp4' entstanden sind, mit SOTR (oder MPEG Streamclip) zu schneiden, um zu sehen, ob da auch die Sync-Probleme auf betroffenen Mediaplayern bestehen?
(Also zB mp4s, die in Handbrake codiert oder transcodiert wurden.)

Ich frage das deswegen, weil ich gerade gelernt habe, dass Probleme auch schon durch den h264 mp4 output handler entstehen können (http://doom10.org/index.php?topic=718.0).

Wenn es daran liegen sollte, würde uns das zwar nicht unmittelbar helfen, da wir auf GPAC/mp4box angewiesen sind, aber es hieße, dass es sich lohnen könnte, an den mp4box-Parametern herumzuspielen.

21. September 2012
10:07
Avatar
raphael
Member
Members
Forum Posts: 8
Member Since:
19. September 2012
sp_UserOfflineSmall Offline

Ich habe gestern Abend etwas experimentiert und nachdem ich erst dachte auf etwas gestoßen zu sein, hat sich im Laufe gezeigt, dass sich bei mir (heißt: FireCore MediaPlayer auf einem ATV2, der per SMB auf die Dateien zugreift) das Problem der Asynchronität nicht zuverlässig reproduzieren lässt. Ein- und dieselben Dateien, die zuvor asynchron wurden, waren später lippensynchron oder mit einem anderen, aber tolerierbaren Versatz. Das syslog des AppleTV hat mir auch keine Erkenntnisse geliefert. Ich kann so jedenfalls nicht ordentlich debuggen, da die Ergebnisse scheinbar willkürlich variieren. Ich habe jetzt erstmal einen Bugreport an FireCore abgesetzt.

Nachtrag: Nachdem ich jetzt nochmal mit ein paar Dateien gespielt habe, habe ich zwei (derzeit reproduzierbar) asynchrone HQ-Dateien ausgemacht, die von Super OTR in MP4 umgewandelt und dann geschnitten wurden. Beide Dateien habe ich testweise mit mkvmerge in einen MKV-Container gepackt. Bei Datei 1 kam der hier erwähnte Fehler mit dem negativen Timecode, Datei 2 wurde ohne Hinweis umgepackt. Beide Dateien laufen (derzeit...) synchron auf meinem oben genannten Setup. Allerdings hat Datei 1 Probleme beim Seeking, es ist sehr langsam und bis auf ein paar Artefakte ist alles grau. Die Option "--clusters-in-meta-seek" scheint das leicht verbessert zu haben.

@Tom: setzt du nicht mkvmerge ein und mit welchen Parametern?

22. September 2012
01:31
Avatar
Tom
Member
Members
Forum Posts: 174
Member Since:
14. Mai 2012
sp_UserOfflineSmall Offline

@Tom: setzt du nicht mkvmerge ein und mit welchen Parametern?

Im Terminal ohne Parameter, also ‘mkvmerge -o <outputmovie>.mkv <inputmovie>’, im GUI die Defaultparameter (kannst du im Muxing-Menu nachschauen).

Die Seekingprobleme mit mkvs habe ich auf der WDTV-Box auch. Allerdings, wenn ich mich recht erinnere, war das Seeking nach der Rückkonvertierung (mkv -> mp4/mov via ffmpeg) wieder OK.
‘–clusters-in-meta-seek’ habe ich noch nicht ausprobiert.

Die Meldung mit dem negativen Timecode ist m.E. irrelevant, was die Asynchronität betrifft. (Hat wahrscheinlich nur was mit dem Interleaving zu tun.)

das Problem der Asynchronität nicht zuverlässig reproduzieren lässt. Ein- und dieselben Dateien, die zuvor asynchron wurden, waren später lippensynchron oder mit einem anderen, aber tolerierbaren Versatz.

Das könnte für meine Vermutung sprechen, dass die betroffenen Mediaplayer den Quicktime-Timecode mehr oder weniger fehlerhaft lesen (zumindest nicht so, wie es vorgesehen ist).

Bugreport an FireCore abgesetzt

Gute Idee. Vielleicht kommt da ja ne verwertbare Antwort …

22. September 2012
15:54
Avatar
raphael
Member
Members
Forum Posts: 8
Member Since:
19. September 2012
sp_UserOfflineSmall Offline

Ich habe versucht eines der MKVs zurückzupacken, aber ffmpeg (0.11.2) kapituliert:

ffmpeg -i foo.mkv -f mp4 -vcodec copy -acodec copy ./foo.mp4

[h264 @ 0x7fc593813800] Missing reference picture
[h264 @ 0x7fc593813800] decode_slice_header error
[h264 @ 0x7fc593813800] concealing 1620 DC, 1620 AC, 1620 MV errors
[h264 @ 0x7fc593813800] Missing reference picture
[h264 @ 0x7fc593813800] decode_slice_header error
[h264 @ 0x7fc593813800] concealing 1620 DC, 1620 AC, 1620 MV errors
[h264 @ 0x7fc593813800] Missing reference picture

[...]

Application provided invalid, non monotonically increasing dts to muxer in stream 0: 1663280 >= 1663280
av_interleaved_write_frame(): Invalid argument

Ich nehme an, so machst du es auch?

22. September 2012
19:42
Avatar
Tom
Member
Members
Forum Posts: 174
Member Since:
14. Mai 2012
sp_UserOfflineSmall Offline

raphael said
Ich nehme an, so machst du es auch?

Ja, ich hab’s eben nochmal gecheckt (an einem HQ-Film): geht immer noch.

mkvmerge -o movie.mkv movie.mov ffmpeg -i movie.mkv -f mp4 -vcodec copy -acodec copy movie.mp4

mkvmerge v5.0.1
ffmpeg 0.11.1.git

22. September 2012
20:01
Avatar
raphael
Member
Members
Forum Posts: 8
Member Since:
19. September 2012
sp_UserOfflineSmall Offline

mkvmerge -o movie.mkv movie.mov ffmpeg -i movie.mkv -f mp4 -vcodec copy -acodec copy movie.mp4

mkvmerge v5.0.1
ffmpeg 0.11.1.git

Exakt so mache ich es auch. mkvmerge-Versin ist identisch und bei ffmpeg habe ich es sowohl mit 0.11.1, als auch mit der neuen 0.11.2 probiert. Schade, aber mit trägem Seeking kann ich immer noch besser leben, als mit asychronen Ton.

22. September 2012
20:54
Avatar
Tom
Member
Members
Forum Posts: 174
Member Since:
14. Mai 2012
sp_UserOfflineSmall Offline

Nur um sicher zu gehen: Du hast den Film schon durch mp4box laufen lassen vor dem Schnitt?

(Diese ganzen Missing reference errors erinnern mich irgendwie an die delay frames der h264-Tracks in den OTR-avis …)

EDITED:

Diese Meldung

[h264 @ 0x7fc0a3813800] Missing reference picture [h264 @ 0x7fc0a3813800] decode_slice_header error [h264 @ 0x7fc0a3813800] concealing 1620 DC, 1620 AC, 1620 MV errors in P frame

habe ich jetzt hier auch beobachtet. Allerdings nur in einfacher Ausführung und die Konvertierung wird erfolgreich durchgeführt. Den ‘monotonically increasing dts’ error kann ich nicht reproduzieren.

24. September 2012
01:08
Avatar
Tom
Member
Members
Forum Posts: 174
Member Since:
14. Mai 2012
sp_UserOfflineSmall Offline

Heute war wieder Experimentiertag und ich bin auf ein paar interessante Dinge gestoßen.

Als ich ein geschnittenes mov mit ffmpeg bearbeitet habe, fiel mir folgende Warnung auf:

[…] multiple edit list entries, a/v desync might occur, patch welcome

In einem Ffmpeg-Forum findet sich dazu diese Info:

It’s not an error so much as a warning. Mov files can contains EDL data that some quicktime based editing apps tend to create. (And it is a rather stupid feature to put in a distribution format) It means that timestamps in the streams can hop around and that the EDL may dictate that parts of streams should be skipped. Obviously this can cause problems. Results may vary depending on the content of the video. […]

Nachdem dies unser Problem ziemlich gut umschreibt, hab’ ich mal die Atoms (=Boxes) eines geschnittenen, asynchronen movs mit denen eines synchronen, aus mkv zurückkonvertierten movs verglichen.

Atom-Vergleich SOTR-mov vs. mkv-mov

Als erstes fällt auf, dass das XML-Dump[1] des mkv-mov ca. 50% (400000 Zeilen) größer ausfällt als das des SOTR-mov. Quicktime scheint also eine kompaktere Notierung zu verwenden, die dann bei der Konvertierung explizit ausgeschrieben wird.

Edit list entries

Wenn man sich die erwähnten Edit list entries anschaut, stellt sich das so dar:

Das SOTR-mov hat 1 Edit list, die in identischer Form jeweils in der Video- und der Audio-TrackBox steht. In dieser Liste sind die ‘Edit segments’ (in unserem Fall Informationen zu den Schnitten) vermerkt:

Edit list des SOTR-mov (Video und Audio):

<EditListBox EntryCount=“4”>
<BoxInfo Size=“64” Type=“elst”/>
<FullBoxInfo Version=“0” Flags=“0”/>
<EditListEntry Duration=“1274664” MediaTime=“154959” MediaRate=“1”/>
<EditListEntry Duration=“896184” MediaTime=“53404000” MediaRate=“1”/>
<EditListEntry Duration=“1069608” MediaTime=“90920000” MediaRate=“1”/>
<EditListEntry Duration=“751176” MediaTime=“135661000” MediaRate=“1”/>
</EditListBox>

Das mkv-mov hat zwar auch Edit lists für jeden Track, allerdings sind diese voneinander verschieden und enthalten nicht mehr die ursprünglich vorhandenen Edit segments:

Edit list des mkv-mov in der Video-TrackBox:

<EditListBox EntryCount=“2”>
<BoxInfo Size=“40” Type=“elst”/>
<FullBoxInfo Version=“0” Flags=“0”/>
<EditListEntry Duration=“80” MediaTime=“–1” MediaRate=“1”/>
<EditListEntry Duration=“6678200” MediaTime=“40” MediaRate=“1”/>
</EditListBox>

(–1 ist ein leeres Edit)

Edit list des mkv-mov in der Audio-TrackBox:

<EditListBox EntryCount=“1”>
<BoxInfo Size=“28” Type=“elst”/>
<FullBoxInfo Version=“0” Flags=“0”/>
<EditListEntry Duration=“6652791” MediaTime=“0” MediaRate=“1”/>
</EditListBox>

In den Edit lists des mkv-movs sind also nur noch die genauen Startzeiten der Tracks notiert.

SampleTableBoxes

In den Sample tables sitzt die große Menge der Daten. Jeder Track hat seine eigenen Sample tables, jeweils innerhalb des Media atoms:

SOTR-mov

SampleTableBox des Videotracks:

<SampleTableBox>
<BoxInfo Size=“1963178” Type=“stbl”/>

SampleTableBox des Audiotracks:

<SampleTableBox>
<BoxInfo Size=“1878287” Type=“stbl”/>

mkv-mov

SampleTableBox des Videotracks:

<SampleTableBox>
<BoxInfo Size=“2203026” Type=“stbl”/>

SampleTableBox des Audiotracks:

<SampleTableBox>
<BoxInfo Size=“3659891” Type=“stbl”/>

Die Sample tables des Audiotracks des mkv-movs enthalten also doppelt so viele Einträge wie die des ursprünglichen SOTR-movs(!) Wenn man genauer hinschaut, sieht man, dass der größte Unterschied in den Chunk offset tables, in einem Unter-Atom der SampleTableBox, liegt. (Laut Apple-Docs erlauben es die Chunk offset tables, Media data zu referenzieren, auch in Dateien, die keinerlei Atom-Struktur aufweisen.)

Wer sich für die Details interessiert kann sich hier die XML-Dumps herunterladen (mit einer Diff, in der man sehr schön sämtliche Unterschiede zwischen den Dateien sieht).

Verständliche Infos zu den Atoms (Boxes), mit übersichtlichem Strukturbaum, finden sich auch in den Apple-Docs.

Was passiert hier also?

Ganz einfach gesagt: Wenn SOTR (QT) schneidet, dann schneidet es bekanntlich framegenau, also wenn angesagt auch zwischen Key-Frames. Je nachdem, wie weit der Schnitt vom ursprünglichen Key-Frame entfernt ist, ist es mehr oder weniger nötig, das AV-Timing (Audiooffset) um den Schnitt herum neu zu “justieren”.[2]
QT erledigt das dadurch, dass es die modifizierten Sequenzen in die Edit lists des Track atoms schreibt.

Dummerweise scheint es Mediaplayer zu geben, die mit einem Demuxer arbeiten, der das Edit lists atom nicht oder nur teilweise liest. Damit entgehen dem Player natürlich die Sync-Korrekturen um die Schnitte und er spielt das Ganze asynchron ab.

Wenn wir nun das SOTR-mov nach mkv konvertieren liest mkvmerge das Edit lists atom korrekt aus und schreibt die Daten in expliziter Form in die Sample tables. Bei der Rückkonvertierung mit ffmpeg bleiben die Tables erhalten, die relevanten Daten landen (wahrscheinlich) in den Chunk offset tables. Da diese auch von Demuxern gelesen werden, die nur halb mp4/QT-kompatibel sind, spielen nun auch die Problem-Player das Video synchron ab.

Lösung?

Das Edits lists atom scheint im ISO-Standard verankert und die Benutzung desselben durch QT der saubere und übliche Weg zu sein (MP4reg, Multimediawiki, Mplayer-ML).

Von daher erscheint es mir unwahrscheinlich, dass es eine Möglichkeit gibt, QT dazu zu bringen, die Schnitt/Sync-Infos zusätzlich noch in Sample tables zu schreiben. Das wäre IMO auch nicht der wünschenswerte Weg, denn wenn ein Player mit einem korrekten File nicht zurechtkommt, sollte man den Player kompatibel machen und nicht das File “zurechtbiegen”. (Was verbogene files angeht, reichen mir die gehackten avi-h264s von OTR eigentlich ;)

Also, konkrete Lösunswege, so wie sich mir die Situation darstellt:

  • QT-kompatiblen Player/Box benutzen (VLC, iTunes, Apple-TV …).
  • Für nicht kompatible Media-Player file nach mkv konvertieren, abspielen, löschen (zum Archivieren würde ich das SOTR-mov nehmen).
  • Warten bis die Problemplayer einen geeigneten Demuxer verwenden; an den Support schreiben.

  1. mp4box -diso  ↩
  2. Schnitte genau an Key-Frames sind unproblematisch, da diese in den Sync table atoms definiert werden.  ↩
No permission to create posts
Forum Timezone: Europe/Berlin

Most Users Ever Online: 21

Currently Online:
1 Guest(s)

Currently Browsing this Page:
1 Guest(s)

Top Posters:

Tom: 174

Timm: 88

mepaso: 62

Baa: 38

ovicula: 24

matze: 11

raphael: 8

goetzibubu: 7

i-land: 5

Felix: 5

Member Stats:

Guest Posters: 10

Members: 57

Moderators: 0

Admins: 1

Forum Stats:

Groups: 1

Forums: 2

Topics: 73

Posts: 551

Newest Members:

Jerryseiny, AngelkbsrKt, Invawnvenue, AaronDuh, EdwardPAins, noyjfkEmbab

Administrators: Stephan: 56

Kommentare sind geschlossen