FreeLists / openbeos / [openbeos] Re: Implementing MP4

["David McPaul" <dmcpaul@xxxxxxxxxxxxxx>]

On Mon, 04 Jul 2005 19:16:52 -0400 EDT "Alexander G. M. Smith" <
agmsmith@xxxxxxxxxx> said
> David McPaul wrote on Mon, 04 Jul 2005 19:16:28 +1000 EST:
> >     Basically the MP4 format is based on the Quicktime format so my 
> > current quicktime parser seems to read them ok, but there are some 
> > differences and I am concerned that there might be differences that 
> > would make it difficult to have 1 parser handling both formats.
> 
> Since you may know and I don't know what BeOS supports, are any of
> those streaming formats, where you have a data stream (like a TV
> broadcast) that doesn't have a particular end time?

I am not an expert in this by any means so others are welcome to 
correct me here.

Quicktime files can be made streamable through a process called 
'flattening'.
To flattening a quicktime file you just move all the meta data atoms 
that are needed by the decoders to the front of the file so they can be 
read in first before the data atom is streamed out.  So the reader will 
be able to read the moov atoms etc then know the mdat atoms are coming.  
The audio and video data must be interleaved also.

The Quicktime reader/parser I put into the repository has 2 problems 
that would prevent it reading a flattened quicktime file over a network 
channel.
1.  Currently the reader does a seek to the end of the file so it can 
sanity check later reads.  This is there to handle incomplete files.  
It is fairly simple to remove this check though.
2.  The parser attempts to parse the entire file before returning to 
the reader so it finds all atoms it knows about.  This would need to be 
changed to have it stop reading the file once it has found and parsed 
the meta data it needs.  The reading of the mdat atom can be avoided 
until it is needed for actual playback.  This may or may not be 
difficult.

There are some file formats that are specifically designed to be 
streamable.  MPEG2 Transport streams I believe is what you are thinking 
about when you mentioned TV broadcasts.  I believe one of the 
properties of transport streams is that you can cut them anywhere and 
still play the bit you have.

I don't believe we have a MPEG2 Transport stream reader in Haiku but 
Marcus is working with a Digital Video Broadcast (DVB) card to create a 
driver for it.  DVB cards simply recieve MPEG2 transport streams so I 
assume something will come out of that.  Marcus can talk more about it 
perhaps.

> Also how about the support for frames arriving out of sequence?  Like
> in MPEG-2 where you have inbetween frames, possibly based on a future
> frame.  Apple was saying something about having to rework Quicktime
> to support that recently.  Is BeOS/Haiku in the same boat?

This may or may not be an issue.  Generally the handling of the various 
types of frames that encoders use to represent the media being decoded 
are the domain of the decoder only.  So if the decoder needs a frame 
that is some time in the future then it just needs to keep decoding 
until it has all the required data to present the frame requested.

There are 2 flags in the media_encoded_video_format structure that can 
be set for handling this sort of thing (I think).

forward_history indicates the maximum number of future frames the 
encoding algorithm requires in order to decode the current frame. 
backward_history indicates the maximum number of past frames the 
encoding algorithm requires in order to decode the current frame. 

Most decoders buffer previous frames themselves if they need them but 
forward_history could be usefull for what you are thinking about.  I 
don't know if it actually affects things though

Cheers
David

--
At no time is freedom of speech more precious than when a man hits his
thumb with a hammer.
                -- Marshall Lumsden