Massives Offset AviSource

Hi,

habe folgendes Problem:
Ich lasser via OTR mir eine Sendung aufzeichnen die ich dann von der Werbung befreie. Das Cutten ist soweit kein problem, aber nach dem muxen habe ich ein riesiges Offset zwischen Bild und Ton das größer 1 Sekunde ist (ca. 1250 ms)
Ich versteh nicht warum ?
Spielt man das originalvideo ab, ist alles lippensyncron. Sowohl Avinaptic als auch Mediainfo bestätigen ein Delay von 0 ms.
Avinaptic ist zwar der Meinung das es sich um VBR mp3 handelt, aber Mediainfo spricht von CBR. Nach dem demuxen und genauerer Analyse hat sich das auch bestätigt.
Das re-encoden mache ich über MeGUI + Nero AAC ... könnte es sein das da der Wurm drinn ist ? Gab's nicht vor kurzem 'n Update ?

Hier ist mein Avisynth Script:

vid=AviSource("The_Ellen_DeGeneres_Show_10.01.26_16-00_uswnbc_60_TVOON_DE.mpg.avi").EnsureVBRMP3Sync()v1=vid.Trim(9915,31300).FadeIO(15)v2=vid.Trim(35571,47611).FadeIO(15)v3=vid.Trim(52780,66776).FadeIO(15)v4=vid.Trim(71353,76586).FadeIO(15)v5=vid.Trim(81542,89997).FadeIO(15)v6=vid.Trim(94875,104613).FadeIO(15)v7=vid.Trim(111505,115160).FadeIO(15)v1++v2++v3++v4++v5++v6++v7

EDIT: ... ich habe gerade festgestellt das wenn man das .avs sich direkt anschaut noch alles syncron ist. D.h. es ist wohl ein MeGUI Problem ...

EDIT2: Und noch ein Update hinterher. Es liegt nicht an Nero, sondern an Avisynth selbst. Ich habe die Tonspur als wav extrahiert und dan per .avs wieder dazugemischt. gab ein sagenhaftes Offset von 1750 ms zum Bild.

v1=DirectShowSource("ellen-20.mp4")
v2=WavSource("one.wav").DelayAudio(-1.750)


AudioDub(v1,v2)

... oder hat gar x264 'n Knacks ? Denn wie schon gesagt, lade ich per avs das Originalvideo, gibt's keine Verschiebung zwischen Ton und Bild ...

hallo zusammen, es gibt Neuigkeiten:

Es hat sich folgender Effekt gezeigt:
Encode ich mit x264 Build 1400 habe ich den besagten "Offset" Effeckt. Encode ich exact das Selbe .avs mit Build 1376 habe ich KEIN Offset mehr !

Liegt es am x264 ? Ich bin mir da nicht sicher. Ich habe beide .h264 Streams mal ein wenig analysiert: Sie sind zwar unterschiedlich groß - logisch der 1400'er Build komprimiert besser - aber die Anzahl der Frames ist exackt gleich.
An den fps liegt's (glaube ich) auch nicht. Avinaptic reported immer 29.9700
Außerdem, wenn es an der Abspielgeschwindigkeit läge dann währe das Offset ja nicht konstant.
Der Audio File war natürlich immer der Selbe.

Zwei Möglichkeiten.
1. Avisynth gibt falsche Informationen an x264.exe die zum besagten Offset führen.
2. x264 (Build 1400) verwirft infos von avisynth oder behandelt diese anderst als Build 1376 ...

Könnte das an r1379 eingefürtem:

Zitat

Overhaul the muxers to pass through timestamps instead of assuming CFR.
Also overhaul muxers to correctly use b_annexb and b_repeat_headers to simplify the code.
Remove VFW input support, since it's now pretty much redundant with native AVS support and LAVF support.
Finally, overhaul a large part of the x264cli internals.

Zitat von LigH

- Du muxt in welchen Kontainer? MP4 oder MKV oder sonstwas?

in .mp4 - das ist nötig da nur dieser auf der PS3 angenommen wird (abgesehen von .avi). Das Problem gibt's aber auch mit .mkv ist also keine Containersache.

Zitat

- In welchen Playern bemerkst du eine Verschiebung?

In allen: MPC, VLC, mplayer (auf win) und Windows Media Player 11

Zitat

- Warum sollte irgend jemand MP4-Dateien mit DirectShowSource öffnen? (Es sei denn, alle anderen Methoden funktionieren nicht.)

... das war eigentlich nur zum testen ... Das DirectShow nich Framegenau abreitet ist mir schon bewusst. Das es aber Offsets von knapp 2 Sekunden produziert währe selbst für DS extrem ungewöhnlich !! Als DS Decoder benutze ich CoreAVC ...

Zitat

- *.mpg.avi ... ja, was denn nun?!

Es ist ein .avi Container - deshalb ja auch AviSource (...
Es ist wohl so das OTR in mpeg-2 wohl erst mal aufzeichnet und dann nach DivX 5 wandelt.

Zitat

Also meine Vermutung wäre, dass hier der Splitterfilter für den verwendeten Kontainer nicht ganz mit der hohen Komplexität aktueller x264-Versionen zurechtkommt.

... eher unwahrscheinlich. Beim Sprung von 1376 nach 1400 wurden soweit ich gesehen habe nicht wirklich neue Features eingebracht. Daher nehmen ich mal an das die Komplexität doch sehr ähnlich ist ...

Zitat

Dass x264 seit r1379 Timestamps durchleitet, kann auch damit zusammenhängen.

... Hm, währe 'ne Möglichkeit. Werde es mal mit "--force-cfr" probieren:

Zitat

-force-cfr, a new x264cli option, allows the user to force the old method of timestamp handling.May be useful in case of a source with broken timestamps.
Avisynth, YUV, and Y4M input are all still CFR.LAVF or FFMS2 must be used for VFR support.

Hm ... leider hatte "--force-cfr" nicht den gewünschten Effekt !

Hat irgendjemand vielleicht 'ne r1378 und r1379 zum testen für mich ? Leider gibt's keine der beiden Versionen auf dem Mirror ...

Also wer sich's mal anschauen möchte ...

So, nachdem die rechtlichen Fragen ja ausgibig diskutiert wurde, möchte ich doch nochmals auf Das Probelm zurückkommen.

Dazu habe ich paralel auf Doom10 einen Thread geöffnet:

http://doom10.org/index.php?topic=191.0

Zitat

VFR Maniac wrote:
Hi, may24 and Assassinator.
I and kierank rewrote mp4 muxer at rev1379, and I added edts writer to mp4 muxer.
If you installed Haali Media Splitter and use it, look at this my post
And please upload a sample of a file that won't work correctly.

...

Assassinator wrote:
But if it's the Haali splitter's fault for the desync, why does it break only on r1400+ produced files and not on the others?

VFR maniac wrote:
I guess newer FFMS2 gets CTS + edts offset. (edts is optional)
Edts writer implemented from rev1379 writes initial delay as media_time which is for eliminating it by splitters. (Sign of edts offset is minus.)

Delay import option of MP4Box and Haali's splitter use MOVIE header (i.e. mvhd) timescale for media_time, however that is wrong.
media_time should be given by MEDIA header (i.e. mdhd) timescale.

For instance.
GPAC use 600 mvhd timescale normally, and if you mux the video with fps=23.976024..., the video in mp4 has 24000 mdhd timescale.
With B-frames and without b-pyramid, the CTS (Composition Timestamp) of the video start from 1001 by one frame initial delay, and then edts writer writes 1001 as media_time.
Therefore if the mp4 splitter supports edts correctly, the first timecode is 1001/24000 - 1001/24000 = 0[ms].
If the splitter doesn't support edts (ex. MPC-HC mp4 splitter), the first timecode is 1001/24000 - 0 = 41.708333...[ms]
(Nero mp4 splitter shifts all timecodes without edts so that the first timecode can be 0[ms].)
If you use Haali's splitter that misunderstands timescale of media_time, the first timecode is 1001/24000 - 1001/600 = -1.626625...[ms]
That means the first 40 frames (CTS < 1001/600*24000 = 40040) has negative PTS (Presentation Timestamp), and that causes fatal A/V async.

Alles anzeigen

Die Frage ist nun: was soll man damit anstellen ? Gibt's denn eine Möglichkeit den PTS (Presentation Timestamp) so hinzubiegen das es auch mit r1416 klappt ?
Ein weiters Problem (im nachhinein an diesen Post eher verständlich) ist das wenn ich das Video mit FFMS2 decodieren schon von vornherein besagtes Offset habe wenn ich es via Avisynth öffne. Das Passiert bei "AviSource" nicht ...

Upadate: Der Effekt tritt auch mit DG's DGAVDIndex auf ... also letztenendes auch mit ffmpeg