[AVT] MWPP and the marker bit ...
John Lazzaro <lazzaro@CS.Berkeley.EDU> Thu, 03 April 2003 18:30 UTC
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05763 for <avt-archive@odin.ietf.org>; Thu, 3 Apr 2003 13:30:36 -0500 (EST)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h33IWvB12495 for avt-archive@odin.ietf.org; Thu, 3 Apr 2003 13:32:57 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33IWNK12460; Thu, 3 Apr 2003 13:32:24 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33IUpK12292 for <avt@optimus.ietf.org>; Thu, 3 Apr 2003 13:30:51 -0500
Received: from snap.CS.Berkeley.EDU (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05678 for <avt@ietf.org>; Thu, 3 Apr 2003 13:27:58 -0500 (EST)
Received: (from lazzaro@localhost) by snap.CS.Berkeley.EDU (8.11.6/8.9.3-ZUUL) id h33ITKG21170 for avt@ietf.org; Thu, 3 Apr 2003 10:29:20 -0800
Date: Thu, 03 Apr 2003 10:29:20 -0800
From: John Lazzaro <lazzaro@CS.Berkeley.EDU>
Message-Id: <200304031829.h33ITKG21170@snap.CS.Berkeley.EDU>
To: avt@ietf.org
Subject: [AVT] MWPP and the marker bit ...
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
Hi everyone, Looking for input on the following MWPP issue ... From the draft-ietf-avt-mpeg4-simple-07.txt: Marker (M) bit: The M bit is set to 1 to indicate that the RTP packet payload contains either the final fragment of a fragmented Access Unit or one or more complete Access Units. MWPP needs 1-packet-per-access-unit semantics to work properly, and so MWPP defines the M bit to always 1 for mpeg4-generic use. Up until now, I've also defined the M bit to always be 1 for "native MWPP streams" (mwpp MIME type), on the theory the confusion that would come from having two different M bit uses for the different MIME types outweighs the advantage of using the M bit for something useful. However, the recent discussion on the list over voice-codec M bit use has made me wonder if I should instead define the M bit for the mwpp MIME type to have a meaning akin to the voice-spurt M bit meaning. For mwpp, this semantic would be "any packet that codes at least one new MIDI command", and the purpose would be to let receivers quickly distinguish empty "guard packets" from packets with new data. Any input one way or the other is appreciated -- I'm undecided at this point ... ------------------------------------------------------------------------- John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro ------------------------------------------------------------------------- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt
- [AVT] MWPP and the marker bit ... John Lazzaro