[MPlayer-dev-eng] Writing A New File Demuxer

Mike Melanson melanson at pcisys.net
Sat Feb 2 22:44:54 CET 2002


On Thu, 31 Jan 2002, Arpi wrote:

> > 	First, the demuxer opens the file. In doing so, it creates new
> > sh_video_t and sh_audio_t structures. It parses information from the file
> > and loads up a bunch of fields in those structures, e.g., width, height,
> > framerate, codec for video and samplerate, samplesize, channels, codec for
> > audio. Question: Is it necessary to load up the bitmapinfo and waveheader
> > structure fields in these stream headers? I didn't bother in the FLI
> > decoder and it didn't seem to matter. Was that because I didn't bother to
> 
> it depends on the codec. if you want to use win32 codecs, then yes.
> if you implement the codec, you know what fields are used by the codec,
> and it's enough to fill them.

	I figured out a better answer to my original question, A'rpi. How
about, "Your demuxer will want to use the WAVEHEADER portion of the
sh_audio_t struct to allow necessary data to pass unmolested through the
start of the init_audio() function since init_audio() sees fit to mess
with several very important fields, such as channels, samplesize,
samplerate, and audio_out_minsize that sometimes only a file demuxer
knows how to properly initialize." Seriously, why does init_audio() mess
with these fields? I initialized them in my RoQ demuxer only to have them
trashed.

	Thanks...
-- 
	-Mike Melanson




More information about the MPlayer-dev-eng mailing list