John wrote:
>Yes, SA_access_unit's are in sfront's future, although handling
>these without the context of knowing how SA_access_unit's are
>supposed to be integrated into the MPEG 4 file format as a whole
>is going to be tricky, since class midi_event (to my knowledge)
>won't be carring the timestamps a la' MIDI files, but instead will
>need to infer timestamps from the rest of the file format, if in
>fact the midi_event's are meant to be interpeted as score_line's
>that have has_time=1 are interpeted (from my understanding, both
>types of midi_event's will be supported, has_time=0, in which
>case you process it when you receive it, and has_time=1, in
>which you apply an inferred timestamp, but the midi_event itself
>doesn't state its has_time value, that needs to be inferred from
>the bitstream also).
This is correct in spirit. But there's no has_time for
midi_event -- in the streaming format, midi_event appears
all by itself and always acts like a score_event with
has_time set.
To clarify, "without the context of knowing how SA_access_unit's
are supposed to be integrated into the MPEG-4 file format as a
whole" refers to the fact that there is no publically
available final draft of the Systems standard. The Systems
standard does tell you how to package and send SA_specific_info
and SA_access_unit over some transport.
For Marek and others interested in actual real streaming of
MPEG-4 SA, you should follow the IETF standardization for
MPEG-4 over RTP. I believe there's a RFC on this topic now,
but I'm not tracking it closely. Once that gets finished
and the Systems spec is published (any month now), all the
pieces are in place to implement streaming SA over the
Web.
Best,
-- Eric
+-----------------+
| Eric Scheirer |A-7b5 D7b9|G-7 C7|Cb C-7b5 F7#9|Bb |B-7 E7|
|eds@media.mit.edu| < http://sound.media.mit.edu/~eds >
| 617 253 1750 |A A/G# F#-7 F#-/E|Eb-7b5 D7b5|Db|C7b5 B7b5|Bb|
+-----------------+
This archive was generated by hypermail 2b29 : Wed May 10 2000 - 12:15:48 EDT