Mark Harris wrote:
Actually my proposed text in Section 6 permits rejecting or partial processing of any packet larger than 61,440 octets (including a comment packet), although I'm certainly open to other suggestions. It
Yes, I don't think that's a good idea. Or rather, I certainly don't think rejecting a comment packet of that size is a good idea. Since they can contain multiple album art pictures, etc., it is not too hard to make one larger than this limit, and such files are commonly found in the wild.
I know Rockbox, for example, has code to skip over very large comment headers (which I suppose would fall under your definition of 'partially process'), which I think is fine for embedded devices that have a limited ability to display album art anyway, but given that the normal behavior of failing to decode a valid comment header is to reject the entire file, I think telling people they can reject comment headers over 60 kB will lead to interoperability problems. I don't have good advice for a limit to specify here for rejection, but that doesn't mean we should give bad advice.
a stream that is already CBR. How about: "Encoders SHOULD limit the use of padding in audio data packets to no more than is necessary to make a variable bitrate (VBR) stream constant bitrate (CBR)"?
No objection from me.
Does the 7,680 octets per stream apply to the comment packet?
I don't think it should, for the above reasons.
It is my impression that no decoders are currently required to process any packets at all from a stream with channel mapping 255. If that is not the intention, then perhaps this is what should be clarified. Is
Certainly we do not obligate people to implement support for channel mapping 255, and certainly do not obligate support for 255 channels. But I think it is a mistake to look at this from the decoder's perspective. The point of this limit is to tell an _encoder_ what it can do an expect to have it work. Telling an encoder, "Well, there may be a packet size limit in the decoder, but we don't know what it is, and something may decide to play your stream with too small of a buffer, and fail in the middle, or not," is not exactly helpful. If we're going to do that, we might as well not specify any limits at all.
_______________________________________________ codec mailing list [email protected] https://www.ietf.org/mailman/listinfo/codec
