Hi folks,
I am not a lawyer, don't base your business plans on anything
I'm about to write here.
There are two separate issues here -- patent issues on MPEG 4
Systems, and patent issues on Structured Audio itself. In general,
patents licensing rights for MPEG 4 get negotiated in the M4IF --
the MPEG 4 Industry Forum. Like white smoke puffing out of the
Vatican, you can follow press releases on this website:
to see when consensus has been reached on a portion of the
patent pool. Since Structured Audio flies underneath the radar of
the M4IF folks currently, most of the high-profile action revolves
around MPEG 4 Systems, and this email will focus on that issue.
MPEG 4 Systems is about organizing the atomic bitstream
elements codecs define into bigger units. For example, for
Structured Audio, Section 5.5 of ISO/IEC FDIS 14496-3 sec5
defines StructuredAudioSpecificConfig and SA_access_units. The
MPEG 4 Systems patent issues come into play for Structured Audio
software that decides that organizing these two atomic elements
into an MPEG 4 Systems framework is a good thing.
The last publically accessible complete document about
MPEG 4 Systems (to my knowledge) are these doc files:
/scratch/sfman/user/network/w2201.zip
As Niels noted, saolc and sfront at the present time
don't create files based on MPEG 4 Systems. Instead, those ".mp4"
files you make with saenc or sfront -bitout are a simple
concatenation of a StructuredAudioSpecificConfig, optionally
followed by a list of SA_access_units with trivial timestamps.
Basically, there are two things to do with bitstreams:
-- store them in a file
-- send them over media
The latter is really the researchy thing that we're
focusing on lately, and we'll be doing it in a way that uses
no MPEG 4 Systems related technology; instead, we're defining
IETF RTP packetizations for SA_access_units, see:
http://www.cs.berkeley.edu/~lazzaro/sa/pubs/nossdav01.pdf
for details. We're going this route because we're
interested in low-latency network musical performance, and
MPEG 4 Systems doesn't help us do the things we need to do
to make a usable system happen -- namely, tight coupling
to the transport media for forward-error-correction. See
the paper above for details, and expect to see the technology
in action in upcoming sfront releases.
As far as (stored) file formats go, what we'll probably
do is to wait for someone else to lead the way, and either
-- support the restricted class of MPEG 4 Systems based
files they adopt, or
-- make a simple sfront mode that dumps out raw atomic
StructuredAudioSpecificConfig and SA_access_units, and
let someone else write file-making tools if they wish.
Notice, in this whole discussion, I've sidestepped the actual patents
surrounding MPEG 4 Systems. The interested reader should look at this
mailing list thread:
http://lists.w3.org/Archives/Public/ietf-discuss/2001Mar/thread.html
continued as:
http://lists.w3.org/Archives/Public/ietf-discuss/2001Apr/thread.html
at the bottom, and draw your own conclusions.
-------------------------------------------------------------------------
John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley
lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro
-------------------------------------------------------------------------
This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 11:46:43 EST