Hi Thomas, I don't quite understand what your concern is all about, but here are my comments anyway (please see inline). On Mon, May 24, 2010 at 2:34 PM, Thomas Falk <thfalk at gmail.com> wrote: > Hello, > > there is a problem with the definition of the frame type > pjmedia_frame_ext which hinders its use. > > If in the standard type pjmeda_frame the type field set to > PJMEDIA_TYPE_EXTENDED, the frame can be casted to pjmedia_frame_ext. > This type allows the use of frames consising of subframes and is used > for encoded audio. > Yes. > A problem arises, if a processing block supplies a frame with type > PJMEDIA_TYPE_NONE and the receiver has to cast this to EXTENDED. The > extend frames must have its payload directly after the > pjmedia_frame_ext structure. From pjmedia/types.h: > Well, isn't the rule clear about this? You can only cast a frame to pjmedia_frame_ext *if and only if* the frame type is PJMEDIA_FRAME_TYPE_EXTENDED. If not, then you simply don't cast it. > ?* This structure may contain more than one audio frames, which subsequently > ?* will be called subframes in this structure. The subframes section > ?* immediately follows the end of this structure, and each subframe is > ?* represented by pjmedia_frame_ext_subframe structure. Every next > ?* subframe immediately follows the previous subframe, and all subframes > ?* are byte-aligned although its payload may not be byte-aligned. > > In the normal pjmedia_frame there is a pointer pointing to the > corresponding data buffer. Both frames are quite similar, but very > different in the approch to storing the data. Thus if I cast a > pjmedia_frame to pjmedia_frame_ext, I have to take for granted, that > there is the space for data buffer in the memory directly after the > frame structure. > Same answer as above. > This can be observed if using the switch_board module. It supplies a > pjmedia_frame with type equal to PJMEDIA_TYPE_NONE, but expects a > frame with type PJMEDIA_TYPE_EXTENED back. In this case, there is no > problem, because the memory for the frame has been allocated > accordingly, but not all block support this now. > Sorry but I don't understand what you mean above. But FYI, pjmedia_port_info has a "format" field, which tells you what type of frames it expects/returns. If the format is not PCM, it expects/will return extended frame. > My suggestion would be to change the requirement that the data is > directly behind the pjmedia_frame_ext structure to using the buffer > pointer in the base structure of the pjmedia_frame_ext structure. It > would then point to the sub frames in the same the way it is handeled > by the simple frames. ?This would require slight changes in the > functions in pjmedia/types.h, e.g. pjmedia_frame_ext_append_subframe. > Even if the buffer requirement is changed according to above, you still can't freely typecast any frames to pjmedia_frame_ext, because pjmedia_frame_ext also has additional fields besides the buffer, such as samples_cnt and subframe_cnt. So I don't think this would solve it. Cheers Benny > Let me know what you think. If my proposal may be useful, I can offer > the corresponding patches. > > Regards, > > Thomas Falk > > _______________________________________________ > Visit our blog: http://blog.pjsip.org > > pjsip mailing list > pjsip at lists.pjsip.org > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org > -- Best regards, Benny
