[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