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

[Arpi]

Hi,

> Hi team,
> 	I want to implement a new file demuxer (and still have to finish
> the FILM one). Both of these have both video and audio, unlike the
> video-only FLI files for which I've written a decoder before. I just want
> to see if I have some general concepts straight. Correct me if I have
> anything wrong.
> 
> 	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.

> use it in the FLI video decoder? Then, build a private chunk index for the
> sequence of compressed data chunks in the file, marking whether they're
> audio or video chunks, and store the index in demuxer->priv.
> 
> 	Next, when the demuxer's fill_buffer() routine is called, load the
> next chunk in the file, as privately tracked by the demuxer, determine
> whether it's an audio or video chunk and read it into the appropriate
> stream using ds_read_packet(), passing either demuxer->audio or
> demuxer->video depending on the chunk type.
if you have interleaved file, read teh next chunk. demuxer will queue them
up. if you have random-access file or noninterlaved stuff, you can use the
avi -ni demuxer's way, so pass the requested stream type to
demux_fill_buffer

> 	As for seeking, it doesn't look like this new format has any
> support for key frames. The FILM format may, but I haven't figure out
> exactly which bit in the index may refer to a key frame.
if no keyframes at all, and file is not seekable, then it won't be seekable.
if each frame is key frame (they don't depends on eachother) then set
keyframe bit for all.

> 	Do I have that right? Any key points missing? Thanks...
> --
> 	-Mike Melanson
> 
> _______________________________________________
> MPlayer-dev-eng mailing list
> MPlayer-dev-eng at mplayerhq.hu
> http://mplayerhq.hu/mailman/listinfo/mplayer-dev-eng
> 
> 


A'rpi / Astral & ESP-team

--
mailto:arpi at thot.banki.hu
http://esp-team.scene.hu