Welcher Delay ist eurer Ansicht nach richtig?

Heute ist die Frage aufgetaucht wie man den Delay einer Quelle mit MediaInfo richtig ausliest.

MediaInfo liefert zu einem Audiostream i.d.R. mehrere Werte:
1. Delay
2. Delay, origin
3. Delay relative to video
4. Video0 delay

StaxRip verwendet soweit ich es sehe als Delay für den Audiostream dann: Delay+Delay relative to video.
Hybrid verwendet nur 'Delay relative to video'.

Da ich leider kein brauchbares Sample zur Verfügung habe um sicher zu klären was richtig ist wollte ich mal Fragen was ihr so meint.

Cu Selur

Goldwingfahrer: Die Frage zielt ja eher in die Richtung, dass davon ausgegangen wird, dass das File aktuell synchron ist und um Probleme bei der Weiterverarbeitung zu vermeiden interessant ist welcher der MediaInfo-Werte denn der richtige ist.
Es ist ja nicht die Frage wie man bei beliebiger Quelle allgemein den Delay ermitteln kann, sondern wie man MediaInfo richtig nutzt.
@fryk: Ist mir ehrlich gesagt egal wie mkvmerge vorgeht, da ich nicht selber einen Analyser schreiben will, sondern nur MediaInfo richtig interpretieren will. Vermute aber es liest einfach die entsprechenden Header im Avi Format aus (ist dStart verschoben und oder stehen vor dem Stream lauter 0er). Eine verlässliche Info wirst Du aber nur von Mosu bekommen können bzw. soweit es Dein Programmierkenntnisse erlauben, in dem Du Dir den entsprechenden Source Code von mkvmerge anguckst.
Ansonsten auch interessant: http://www.virtualdub.org/blog/pivot/entry.php?id=27

Cu Selur

Zitat

Intuitiv klingt der Wert "relative to video" wie die Differenz zwischen Video-Delay und Audio-Delay (wozu eigentlich, was ist der Absolut-Bezug?), und damit wäre das mein Favorit. Aber ich garantiere für nichts...

So sehe ich das bis dato auch.
Bin einfach davon ausgegangen, das eigentlich nur der Delay zwischen Audio&Video interessant ist, da ich wenn ich das Material umpacke der Video und Audio Delay erst ein mal 0 sein sollte und man dann entsprechend des Delays entweder der Audio oder der Video Stream 'verschoben' werden.

Zitat

Entsprechend wird vielleicht auch eine Analyse der MediaInfo-Quellen nötig sein, um mit Sicherheit zu verstehen, was die jeweiligen Angaben bedeuten.

Bin eigentlich davon ausgegangen, dass dies nicht nötig sein sollte.
Wenn ich eine Quelle habe die einen wahrnehmbaren Delay hat, sollte man doch eigentlich durch einfaches ausprobieren der Kombinationen:
1. nur Delay
2. Delay + 'Delay relative to video'
3. nur 'Delay relative to video'
entscheiden können was Sinn macht.
Problem: hab keine Quelle hier bei der ich einen sicher wahrnehmbaren Delay (sprich ein paar Frames) hat.

Cu Selur

Zitat

Allerdings gibt Mediainfo bei Backward Prediction B-Frames (egal ob AVC oder MPEG2) am Anfang des Streams immer noch falsche Werte aus und viele Hardwareencoder erzeugen ebensolche Streams.

Weiß zathor (MediaInfo Autor) eigentlich von dem Problem? Hab bei http://sourceforge.net/tracker/?group_id=86862&atid=581181 nichts diesbezüglich gesehen. (oder hab ich was übersehen?)

Wäre vielleicht sinnig, dass Du einen Bugreport erstellst, damit das Problem angegangen werden kann.

Zitat

Backward Prediction B-Frames

-> Wo ist den der Unterschied zu normalen B-Frames? Sollten B-Frames nicht immer forward und backward references verwenden?
Hab mal versucht das Problem hier nach zu stellen, indem ich ein AvisynthSkript:

function p(float len, float freq){return audiodub(BlankClip(length=int(len*24), width=400,height=400, pixel_type="rgb32",fps=24, color=int((freq-271.0)/1.72)).addborders(20,20,20,20,$ffffff),tone(len,freq,channels=1,level=1.0).FadeIO0(1,0,24))}
function q(float len, float freq){return tone(len,freq,channels=1,level=0.5).FadeIO0(1,0,24)}
c=261.6255653006
D=293.6647679174
E=329.6275569129
F=349.2282314330
Gb=369.9944227116
G=391.9954359817
A=440.00000000001
B=493.8833012561
c2=c*2.0
d2=d*2.0
e2=e*2.0
f2=f*2.0
N4=0.5
N8=0.25
mixaudio(p(N4,G)+p(N4,c2)+p(N8,c2)+p(N8,d2)+p(N8,c2)+p(N8,B)+p(N4,a)+p(N4,a)+p(N4,a)+p(N4,d2)+p(N8,d2)+p(N8,e2)+p(N8,d2)+p(N8,c2)+p(N4,b)+p(N4,g)+p(N4,g)+p(N4,e2)+p(N8,e2)+p(N8,f2)+p(N8,e2)+p(N8,d2)+p(N4,c2)+p(N4,a)+p(N8,g)+p(N8,g)+p(N4,a)+p(N4,d2)+p(N4,b)+p(1,c2)+p(N4,g)+p(N4,c2)+p(N4,c2)+p(N4,c2)+p(1,b)+p(N4,b)+p(N4,c2)+p(N4,b)+p(N4,a)+p(1,g)+p(N4,d2)+p(N4,e2)+p(N8,d2)+p(N8,d2)+p(N8,c2)+p(N8,c2)+p(N4,2*g)+p(N4,g)+p(N8,g)+p(N8,g)+p(N4,a)+p(N4,d)+p(N4,b)+p(1,c2),q(N4,G)+q(1,e)+q(N4,c)+q(1,F)+q(N4,G)+q(N4,F)+q(N4,d)+q(N4,Gb)+q(N4,g)+q(N4,d)+q(N4,f)+q(N4,g)+q(N4,d)+q(N4,f)+q(N4,a)+q(N4,f)+q(N4,g)+q(N4,f)+q(N4,Gb)+q(N4,f)+q(1,e)+q(N4,e)+q(N4,c2)+q(N4,b)+q(N4,a)+q(1,g)+q(N4,g)+q(N4,a)+q(N4,g)+q(N4,f)+q(N4,e)+q(N4,f)+q(N4,g)+q(N4,c2)+q(N4,g)+q(N4,a)+q(1,g)+q(N4,e)+q(N4,f)+q(N4,Gb)+q(N4,f)+q(1,e)).subtitle("I wish all avisynth developers and users\n a merry christmas and a happy new year!\n\n(hanfrunz 2011)", align=5, lsp=10, text_color=$ffff00, halo_color=$ff0000)
#
convertToYv12()

reencoded habe nach m2ts(x264,ac3) (x264 --crf 18 --profile high --level 4.1 --bframes 16 --direct auto --partitions i4x4,p8x8,b8x8 --no-fast-pskip --subme 5 --trellis 0 --weightp 1 --aq-mode 0 --vbv-maxrate 62500 --vbv-bufsize 78125 --colormatrix bt470bg --fps 24 --input-res 440x440 --output "H:\Temp\test.264" -) und ac3 umgewandelt habe. -> Beim Ergebnis erkennt MediaInfo korrekt einen Delay von 0.

Cu Selur

Ah, okay. Danke für die Klärung.

DOH,... stimmt wohl,...

Zitat

Und was soll überhaupt der Unterschied zwischen "Delay" und "Delay, origin" sein?

Delay, origin gibt anscheinend an worauf der Delay sich bezieht.
mögliche Werte die mir bis dato untergekommen sind:
Delay, origin : Stream
Delay, origin : Raw stream
Delay, origin : Container
hatte ich nur angegeben um alle Ausgaben bzgl. des Delays genannt zu haben,...

Zitat

Für "Delay+Delay relative to video" von StaxRip fällt mir spontan allerdings kein wirklicher Anwendungsfall ein.

Geht mir genau so, da es mich aber so verwundert hat, hab ich diesen Thread gestartet, weil ich mir nicht sicher bin ob ich was übersehen habe.

Cu Selur