Decoding live WMA/MMS stream with gstreamer

I have an application that receives streamed audio from Windows Media Servers with a content type of application/x-mms-framed. The application removes the framing from the data before passing the stream to a gstreamer pipeline like:

 gst-launch fdsrc ! asfdemux ! fakesink

(of course, usually the pipeline would usually include a WMA decoder and other stuff - this is just the minimum required to illustrate the problem).

I can see from the debug output that the ASF parsing is going wrong with the second data packet: it is trying to read it with an offset of +3 bytes beyond where it actually starts.

Some data from the debug output:

• The initial header packet ($H from the framed stream) is 5027 bytes and seems to be parsed correctly. The minimum packet size is 1567.
• Each of the following data packets ($D from the framed stream) contains 1564 bytes.

I think the problem is that the ASF demuxer is using the fixed min-packet-size value of 1567 for each packet even though it recognizes that the actual packet contains less data. It treats the extra 3 bytes as implicit padding and (effectively) skips them rather than reducing the packet size to consume.

This is probably because my code which simply strips the framing somehow also needs to pass on the actual frame si开发者_JS百科ze. Maybe there is a way of doing this with gstreamer's buffer-passing mechanism, in which case I would need to write a gstreamer plugin to do the unframing. Such a plugin would convert application/x-mms-framed -> video/x-ms-asf. I was hoping to find an existing plugin that would do that but no success so far.

Am I on the right track or is this simply a bug in the ASF demuxer (I suspect not as I have actually tried 3 different ASF demuxer plugins)?

---

I'd definitely suggest to write a plugin. Its a bit of boiler plater, but a much more solid approach. The buffer object have a GST_BUFFER_SIZE field to tell the size.