title: Decoding live WMA/MMS stream with gstreamer
body: <p>I have an application that receives streamed audio from Windows Media Servers with a content type of <code>application/x-mms-framed</code>. The application removes the framing from the data before passing the stream to a gstreamer pipeline like:</p>
  
  <pre><code> gst-launch fdsrc ! asfdemux ! fakesink
  </code></pre>
  
  <p>(of course, usually the pipeline would usually include a WMA decoder and other stuff - this is just the minimum required to illustrate the problem).</p>
  
  <p>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.</p>
  
  <p>Some data from the debug output:</p>
  
  <ul>
  <li>The initial header packet ($H from the framed stream) is 5027 bytes and seems to be parsed correctly. The minimum packet size is 1567.</li>
  <li>Each of the following data packets ($D from the framed stream) contains 1564 bytes.</li>
  </ul>
  
  <p>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.</p>
  
  <p>This is probably because my code which simply strips the framing somehow also needs to pass on the actual frame size. 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 <code>application/x-mms-framed</code> -> <code>video/x-ms-asf</code>. I was hoping to find an existing plugin that would do that but no success so far.</p>
  
  <p>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)?</p>