[Matroska-users] Re: Matroska format and DShow

Mike Matsnev mike at po.cs.msu.su
Wed Nov 7 20:53:45 CET 2007


TheBox wrote:
> I was working with the Haali DShow reader and mux for input and output.
> 
> If I alter any of the data in the sample with another filter then
> reverse it, it works perfect.
>
> [Haali input (video)] à [My Filter scramble] à [My filter unscramble]
> à[FFDShow or Core AVC] à[Haali Mux/File or renderer] (video plays fine)
> 
> [Haali input (video)] à [My Filter scramble] à [My filter unscramble]
> à[Haali Mux/File or renderer] (playback result works)
>  
> However if I output to a file and split this up, it causes issues.
> 
> [Haali input (video)] à [My Filter scramble] à[Haali Mux File]
> 
> [Haali input(scrambled) (video)] à  [My filter unscramble] à[FFDShow or
> Core AVC] à[Haali Mux/File or renderer]
> 
> It seems that the output mux is looking the data itself versus the
> surrounding container and altering the size of the frame itself from the
> Block within the segment. So when its written out, the reader then reads
> the data size as much shorter, and resulting in a failed payload.
> 
> From what I can see the input stream is sending the frame itself forth
> which is fine. If I look in the original file, everything makes sense.
> However if I change any of the data payload itself and remux it, the
> headers change for the output side with bad info (short frame sizes).
> 
> Any thoughts?
For some media types both the splitter and the muxer parse and sometimes
transform the elementary stream, because storage in matroska may be different
from DirectShow. This is especially true for mpeg-1/2 video and audio formats because
for these media types DShow doesn't guarantee complete frames, and the filter has
to parse the data and reconstruct full frames. If you encrypt the ES headers,
startcodes, etc, the filters will be confused.




More information about the Matroska-users mailing list