[Matroska-devel] Connecting XviD DirectShow Encoder filter to matroskamuxer to create native files on DirectShow

Christian HJ Wiesner chris at matroska.org
Sun Aug 24 04:44:07 CEST 2003


I thought i copy you on this conversation i had with Gabest on IRC :

<ChristianHJW> Gabest : you read the logs from my converastion with Tim 
Jansen ?
<ChristianHJW> conversation
<Gabest> no
<ChristianHJW> he has made a XviD DShow encoder filter
<ChristianHJW> http://home.kabelfoon.nl/~jansent/dshow_enc.rar
<ChristianHJW> its currently using the VfW module of XviD sources, means 
its inserting dummy frames for b-frames, etc.
<ChristianHJW> and of course will use the same MEDIATYPE as AVI, and the 
XviD FourCC
<ChristianHJW> he was thinking of adding the possibility to output clean 
MPEG4ES streams
<Gabest> then probably it will be saved as any other xvid coming from 
avi/ogm/mkv
<Gabest> isn't xvid already not packed?
<ChristianHJW> so, if you add reference priority hadnling to 
matroskamuxer, it could be used to make the first valid MPEG4 MKV files :)
<ChristianHJW> but, there were several problems :
<Gabest> I can't calculate the references
<ChristianHJW> - how to tell your muxer what frame is a b-frame ?
<ChristianHJW> oh, you cant ?
<Gabest> even if I knew there is no general rule to find the references
<ChristianHJW> then we have a serious design flaw ?
<Gabest> no
<Gabest> it is just matroska needing to know the references :)
<ChristianHJW> but even native files should be producable in a live 
streaming process ?
<Gabest> ?
<ChristianHJW> I mean, if our frame referencing system can not be used 
in an app that doesnt have the complete file, its not good ?
<Gabest> I still don't understand it
* Belgabor has joined #matroska
* alley_cat has joined #matroska
<Gabest> but I could add some hacks in the muxer
<ChristianHJW> or did i misunderstand the reason why you cant calculate 
the references ?
* BetaBoy has joined #matroska
<Gabest> in the muxer I can only tell if a sample is keyframe or not
<ChristianHJW> because DShow doesnt give you more information, right ?
<Gabest> but I could treat every sample as a b-frame when the timestamp 
goes back
<Gabest> yea
<Gabest> it doesn't need anymore info
<Gabest> it is the responibility of the codec to decode and reorder the 
frames
<Gabest> I always said the container should not know about it...
<ChristianHJW> Gabest : when people want to create MP4 files with 
b-frames on DirectShow, dont they have the very same problems ? Or is it 
no problem for them, as b-frames are only 'makred' as such in the 
MPEG4ES stream, while MP4 container doesnt need to know at all ?
<Gabest> in dshow there are "sync point" flags, they flag a frame from 
which the decoding can be done without messing up the picture
<ChristianHJW> = key frame
<Gabest> yea
<Gabest> but if a frame is a b or p frame is not needed to be known
<Gabest> it is internal to the codec
<ChristianHJW> = inside the MPEG4ES
<ChristianHJW> cant we use other means of DirectShow to indicate frame 
types ? like using a synced txt stream from the encoder to the matroska 
muxer ..... LOL
<Gabest> well, even matroska doesn't need to know which frame is a 
b-frame, it just wants reference times
<ChristianHJW> true
<Gabest> frame type is not important as there can be any type not just b 
or p
<ChristianHJW> and where to get those times from
<Gabest> so, the problem is references
<Gabest> this is lost when passing frames between filters
<Gabest> but I could find it out by looking at the frame timestamps
<ChristianHJW> thats one way
<ChristianHJW> or we really connect the encoder and the muxer with a 2nd 
line, passing pseudo-data
<ChristianHJW> we should think into the future
<ChristianHJW> maybe one day the trick with timestamps is no satisfactory
<Gabest> well, there is a secondary time on samples
<Gabest> we could use that
<ChristianHJW> ?
<Gabest> there is sample "time" and "media time"
<ChristianHJW> a reserved field ?
<Gabest> media time is used to send info like frame number, avi uses 
that I think
<ChristianHJW> is it like display time and file time ?
<Gabest> or sample number for audio
<ChristianHJW> yes, a number would be perfect
<Gabest> the normal "time" is the presentation time
<Gabest> the other is not used by anything I know
<Gabest> it is just there for us :)
<ChristianHJW> :)
<ChristianHJW> lets use it
<ChristianHJW> this is almost perfect
<Gabest> so, we could put refs there
<Gabest> would be a hack
<Gabest> but noone would notice
<ChristianHJW> but it requires defining a new MEDIATYPE again for MKV 
native input, right ?
<Gabest> no
<ChristianHJW> oh ?
<Gabest> could be a regular fourcc media type
<ChristianHJW> but, if we make our own little 'hack' wouldnt it be good 
to differentiate ?
<Gabest> it would be just the "extension" of something
<ChristianHJW> to avoid problems ? that way, everybody using our 
MEDIATYPE knows how to use this 2nd time field
<Gabest> nothing changes for the decoders
<ChristianHJW> ok
<Gabest> well, something could tell that the media time is valid...
<ChristianHJW> 'something' `
<ChristianHJW> ??
<ChristianHJW> a flag ?
<Gabest> yea
<ChristianHJW> where to put ?
<Gabest> there is space
<Gabest> and if this flag is set, that could mean the media time holds 
the back and forward references as the start and end times
<ChristianHJW> sounds like a very good and future proof solution
<ChristianHJW> only multiple references couldnt be handled that way, but 
until we get a codec doing that, DirectShow wont be used anymore :P
<Gabest> ah, more than two refs? :P
<ChristianHJW> yes
<Gabest> well, we could still extend sample info with fields for that 
someway
<Gabest> but that would really need a new media type
<ChristianHJW> again, there are no codecs for that ;)
<ChristianHJW> on the other hand, i dont feel like any matroskamuxer 
tool should be able to write native files without knowing EXACTLY whats 
going on, and so i still feel a new MEDIATYPE would be a good idea, that 
way we make sure only those filters that connect to matroskamuxer using 
this MEDIATYPE know what stuff they had to pass to us ....
<ChristianHJW> in any other case, Vfw files are produced
<jcsston> w00t my first asm code,     __asm {
<jcsston>         MOV EAX, version
<jcsston>         MOV EBX, 5h
<jcsston>         ADD EAX, EBX
<jcsston>         MOV version, EAX
<jcsston>     }
<jcsston> (it adds 5 to version)


......





More information about the Matroska-devel mailing list