[openbeos] Re: Implementing MP4
- From: "David McPaul" <dmcpaul@xxxxxxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Tue, 05 Jul 2005 19:40:07 +1000 EST
On Tue, 05 Jul 2005 10:46:35 +0200 Philippe Houdoin <
philippe.houdoin@xxxxxxx> said
> David McPaul asked:
> > I am trying to decide on the best way to implement an MP4
> > reader.
> >
> > 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.
> >
> > But the real question is. Should I be creating a new FAMILY
> > type
> > and associated functions to support it.
> >
> > Currently we have:
> >
> > typedef enum {
> > B_ANY_FORMAT_FAMILY = 0,
> > B_BEOS_FORMAT_FAMILY = 1,
> > B_QUICKTIME_FORMAT_FAMILY = 2, /* QuickTime is a registered
> > trademark of Apple Computer */
> > B_AVI_FORMAT_FAMILY = 3,
> > B_ASF_FORMAT_FAMILY = 4,
> > B_MPEG_FORMAT_FAMILY = 5,
> > B_WAV_FORMAT_FAMILY = 6,
> > B_AIFF_FORMAT_FAMILY = 7,
> > B_AVR_FORMAT_FAMILY = 8,
> > B_MISC_FORMAT_FAMILY = 99999,
> > } media_format_family;
> >
> > So I was thinking of creating a B_MPEG4_FORMAT_FAMILY = 9,
> > the associated structs and add them to the unions and
> > GetMP4FormatFor etc?
>
> Can't B_MPEG_FORMAT_FAMILY be reused there?
> I dunno how much MPEG4 differ from MPEG2 & MPEG1, but at least they
> all share
> the same MPEG format family links, right?
Possibly but the media_mpeg_description is defined as a single id with
an enumeration
enum mpeg_id {
B_MPEG_ANY = 0,
B_MPEG_1_AUDIO_LAYER_1 = 0x101,
B_MPEG_1_AUDIO_LAYER_2 = 0x102,
B_MPEG_1_AUDIO_LAYER_3 = 0x103, // "MP3"
B_MPEG_1_VIDEO = 0x111
};
typedef struct {
uint32 id;
} media_mpeg_description;
but MPEG-4 needs something more like the quicktime one
typedef struct {
uint32 codec;
uint32 vendor;
} media_quicktime_description;
where codec is the quicktime fourcc type and vendor is the vendor code
from the file.
> If it's necessary, maybe the current Haiku's mpeg format relative
> struct(s)
> could be adjusted to support MPEG1, MPEG2, MPEG3 *and* MPEG4 *without
> * breaking
> ABI?
Possibly, I am not sure how usefull vendor is but the enum for mpeg_id
would concern me if we started placing codec values in the id.
> > How do I make sure we don't lose R5 compatability with this?
>
> With a new B_MPEG4_FORMAT_FAMILY, that would be hard. But, as R5
> never had a
> MPEG4 reader thru MediaKit anyway, it would only break those apps
> that expect a
> format family type in the known range at their compilation time.
> Which is wrong
> and prevent them from supporting any new media family(ies) in the
> future...
>
> Anyway, I would rather like, if you can't reused one of the known
> format family
> types, that you follow the same path than the several media readers
> already
> using B_MISC_FORMAT_FAMILY instead:
>
> OGG
> Matroska
> AU/SND
> MusePack
> AIFF
B_MISC_FORMAT_FAMILY is probably the right track if we cannot add
another without losing R5 ABI.
It has a file format and a codec so thats ok.
> > Or should I just use the quicktime family?
>
> Even if it sounds weird (semantically) that a MPEG4 reader report
> being of
> QuickTime formats family instead of MPEG's one, if it's really easier
> because,
> well, (technically) MPEG4 comes from Qt, go for it.
I am worried though that there will be some aspects of MPEG-4 format
that are just wildly different from quicktime. There are some MPEG-4
atoms that have the same atom name as the quicktime ones but different
structures inside them, if the version number is not different then
there is not any nice way to determine how to read them if we share the
code with the quicktime parser.
> Maybe this media format family enumeration should go dynamic in a
> future > R1
> media kit?
Maybe.
Does adding something to an enum cause an issue? I think the
GetMP4FormatFor function would just be a usefull to have but not
essential since there is a generic MakeFormatFor function. It looks
like there is room in the union for more structs.
Cheers
David
--
"If a camel flies, no one laughs if it doesn't get very far."
-- Paul White
Other related posts:
