[matroska-devel] [Fwd: Re: kaxdemux.dll]
Christian HJ Wiesner
chris at matroska.org
Wed Apr 9 16:37:37 CEST 2003
FYI ( 2nd sending ) :
Ingo Ralf Blum's advice on how to adress the problem with laced blocks
from the DirectShow parser
-------- Original Message --------
Subject: Re: kaxdemux.dll
Date: Sat, 5 Apr 2003 12:35:57 +0200
From: Ingo Ralf Blum <ingo.ralf.blum at pluto.uni-freiburg.de>
To: Christian HJ Wiesner <chris at matroska.org>, Steve Lhomme
<steve.lhomme at free.fr>
CC: <myfun at matroska.org>, "Ludovic 'BlackSun' Vialle"
<blacksun at corecodec.com>
References: <3E7E372B.2080700 at corecodec.com>
<3E8B4675.5000002 at matroska.org> <1049295348.3e8af9f43f6c6 at imp.free.fr>
> Apparently that doesn't solve the lacing problem (that has no timecode).
> least it may solve an existing problem in the filter :)
> Ingo, I remember we talked about that a long time ago and the conclusion
> that there wouldn't be any problems with lacing in DirectShow, right ?
> explain us (at least myFUN who will understand better) again ?
> Also for my understanding of the DSF... Does the filter push the frames in
> DS pulls them ?
the DirectShow demultiplexer usually pushes the samples. If it isn't able to
determine the timestamps it simply can omit them until the next stamp is
read from the file. The decompressor then can cache the data until a valid
time stamp is received and then decompresss all data at once. If the
decompressor isn't able to handle such caching it probably throws out the
uncompressed audio data without any stamps. This might confuse the audio
renderer. If so - and this has to be tested - one could write a filter which
does the caching and stamping for unstamped data. A good way to do this is
to give this filter a higher merit value than the audio renderers, so that
it is inserted automatically before the renderer while automatically
building a graph.
More information about the Matroska-devel